From gurudev.devanla at gmail.com Sun Oct 1 01:30:23 2017 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sat, 30 Sep 2017 18:30:23 -0700 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record Message-ID: Hello All, I am in the process of replicating some code in Python in Haskell. In Python, I load a couple of csv files, each file having more than 100 columns into a Pandas' data frame. Panda's data-frame, in short is a tabular structure which lets me performs on bunch of joins, and filter out data. I generated different shapes of reports using these operations. Of course, I would love some type checking to help me with these merge, join operations as I create different reports. I am not looking to replicate the Pandas data-frame functionality in Haskell. First thing I want to do is reach out to the 'record' data structure. Here are some ideas I have: 1. I need to declare all these 100+ columns into multiple record structures. 2. Some of the columns can have NULL/NaN values. Therefore, some of the attributes of the record structure would be 'MayBe' values. Now, I could drop some columns during load and cut down the number of attributes i created per record structure. 3. Create a dictionary of each record structure which will help me index into into them.' I would like some feedback on the first 2 points. Seems like there is a lot of boiler plate code I have to generate for creating 100s of record attributes. Is this the only sane way to do this? What other patterns should I consider while solving such a problem. Also, I do not want to add too many dependencies into the project, but open to suggestions. Any input/advice on this would be very helpful. Thank you for the time! Guru -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Sun Oct 1 02:36:44 2017 From: simon at joyful.com (Simon Michael) Date: Sat, 30 Sep 2017 16:36:44 -1000 Subject: [Haskell-cafe] ANN: hledger 1.4 Message-ID: <22501960-62EA-4312-A5FC-CB966A38BCE6@joyful.com> Aloha! I'm pleased to announce hledger 1.4. Thank you release contributors: Nicholas Niro, Hans-Peter Deifel, Jakub Zárybnický, Felix Yan, Mark Hansen, Christian G. Warden, Nissar Chababy and Peter Simons. Also, if I haven't already mentioned it: this year hledger turns 10! Here's the first commit, from January 27 2007: https://github.com/simonmichael/hledger/commit/85864b41 We have come a way, but there is much yet to look forward to. Onward and upward! The next major release is scheduled for 2017/12/31. What is hledger ? ----------------- hledger (http://hledger.org) is an evolving, dependable, robust, cross-platform program for tracking money, time, or any other commodity, using double-entry accounting and a simple plain text file format. It is a haskell reimplementation of Ledger and the plain text accounting concept, providing command-line, curses and web interfaces. hledger aims to be a pleasant and practical tool for personal, business or institutional finance and time tracking. What's new ? ------------ The full release notes are at http://hledger.org/release-notes#hledger-1.4 . Some highlights: - Easy install script: we have a new installation method for the hledger tools, intended to dodge common pitfalls and just-work more often. Building on the stack team's install script, this bash script is cross platform, uses cabal or stack, installs stack and GHC if needed, and installs the latest release of all major hledger packages. See http://hledger.org/download for details. - More batteries included: most experimental addon commands formerly shipped in bin/ are now built in and work out of the box. - New commands: balancesheetequity (a balance sheet including equity), tags (list tags in use), import (detects new transactions in multiple input files and adds them to the main journal, particularly useful with CSV downloads). - Balance reports can be sorted by amount - makes those high expenses easy to spot. - CLI conveniences: @ARGSFILE is expanded to the set of args/flags in ARGSFILE. depth:2 or --depth=2 can be written as -2. - Help improvements: reorganized docs page, a more useful commands list, a smarter help command, --help and -h are the same again (by popular demand), Getting started --------------- See http://hledger.org/download for all install methods. To get the latest hledger release, you may need to build it yourself using stack or cabal. But don't worry, this is.. getting quite painless. The new hledger installer requires only bash and will install everything you need in one step: the hledger tools in $HOME/.local/bin/, and (if required) stack and GHC in $HOME/.stack/. Run it like so: $ curl -sSLO http://hledger.org/hledger-install.sh $ less hledger-install.sh # review script, for the security conscious $ bash hledger-install.sh # install the latest hledger tools Ensure $HOME/.local/bin is in your $PATH. Now try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Now perhaps work through the tutorial at http://hledger.org/step-by-step.html Or review the fine documents, presentations etc. at http://hledger.org and http://plaintextaccounting.org Or say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org If you have been finding hledger useful, I invite you to become a sponsor or contributor to make it stronger. Donate using one of the funding links on the home page, give feedback, report bugs, send pull requests, write about it, or help in some other way. Thanks for your support! I hope to meet you online. -Simon From leandro at ostera.io Sun Oct 1 11:08:04 2017 From: leandro at ostera.io (Leandro Ostera) Date: Sun, 01 Oct 2017 11:08:04 +0000 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: Two things come to mind. The first one is *Crazy idea, bad pitch*: generate the record code from the data. The second is to make the records dynamically typed: Would it be simpler to define a Column type you can parameterize with a string for its name (GADTs?) so you automatically get a type of that specific column? That way as you read the CSV files you could define the type of the columns based on the actual column name. Rows would then become sets of pairings of defined columns and values, perhaps having a Maybe would encode that any given value for a particular column is missing. You could encode these pairings a list too. At least there you can have type guarantees that you’re joining fields that are of the same column type. I think. Either way, my 2 cents and keep it up! sön 1 okt. 2017 kl. 03:34 skrev Guru Devanla : > Hello All, > > I am in the process of replicating some code in Python in Haskell. > > In Python, I load a couple of csv files, each file having more than 100 > columns into a Pandas' data frame. Panda's data-frame, in short is a > tabular structure which lets me performs on bunch of joins, and filter out > data. I generated different shapes of reports using these operations. Of > course, I would love some type checking to help me with these merge, join > operations as I create different reports. > > I am not looking to replicate the Pandas data-frame functionality in > Haskell. First thing I want to do is reach out to the 'record' data > structure. Here are some ideas I have: > > 1. I need to declare all these 100+ columns into multiple record > structures. > 2. Some of the columns can have NULL/NaN values. Therefore, some of the > attributes of the record structure would be 'MayBe' values. Now, I could > drop some columns during load and cut down the number of attributes i > created per record structure. > 3. Create a dictionary of each record structure which will help me index > into into them.' > > I would like some feedback on the first 2 points. Seems like there is a > lot of boiler plate code I have to generate for creating 100s of record > attributes. Is this the only sane way to do this? What other patterns > should I consider while solving such a problem. > > Also, I do not want to add too many dependencies into the project, but > open to suggestions. > > Any input/advice on this would be very helpful. > > Thank you for the time! > Guru > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amin at aminb.org Sun Oct 1 17:31:00 2017 From: amin at aminb.org (Amin Bandali) Date: Sun, 01 Oct 2017 13:31:00 -0400 Subject: [Haskell-cafe] ANN: hledger 1.4 In-Reply-To: <22501960-62EA-4312-A5FC-CB966A38BCE6@joyful.com> References: <22501960-62EA-4312-A5FC-CB966A38BCE6@joyful.com> Message-ID: <87h8viyduz.fsf@aminb.org> Happy belated 10th birthday hledger! Simon, congratulations on the release and thank you and everyone else for all the hard work put in hledger to make it the awesome piece of software it is today. Here's to another 10! -amin From saurabhnanda at gmail.com Sun Oct 1 18:03:27 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Sun, 1 Oct 2017 23:33:27 +0530 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: If your data is originating from a DB, read the DB schema and use code-gen or TH to generate your record structure. Please confirm that your Haskell data pipeline is able to handle 100-field+ records beforehand. I have a strange feeling that some library or the other is going to break at the 64-field mark. If you don't have access to the underlying DB, read the CSV header and code-gen your data structures. This will still lead to a lot of boilerplate because your code-gen script will need to maintain a col-name<>data-type mapping. See if you can peek at the first row of the data and take an educated guess about each column's data-type based on the column values. This will not be 100% accurate, but you can get good results by manually specifying only a few data-types instead of the entire 100+ data-types. -- Saurabh. On Sun, Oct 1, 2017 at 4:38 PM, Leandro Ostera wrote: > Two things come to mind. > > The first one is *Crazy idea, bad pitch*: generate the record code from > the data. > > The second is to make the records dynamically typed: > > Would it be simpler to define a Column type you can parameterize with a > string for its name (GADTs?) so you automatically get a type of that > specific column? > > That way as you read the CSV files you could define the type of the > columns based on the actual column name. > > Rows would then become sets of pairings of defined columns and values, > perhaps having a Maybe would encode that any given value for a particular > column is missing. You could encode these pairings a list too. > > At least there you can have type guarantees that you’re joining fields > that are of the same column type. I think. > > Either way, my 2 cents and keep it up! > > > sön 1 okt. 2017 kl. 03:34 skrev Guru Devanla : > >> Hello All, >> >> I am in the process of replicating some code in Python in Haskell. >> >> In Python, I load a couple of csv files, each file having more than 100 >> columns into a Pandas' data frame. Panda's data-frame, in short is a >> tabular structure which lets me performs on bunch of joins, and filter out >> data. I generated different shapes of reports using these operations. Of >> course, I would love some type checking to help me with these merge, join >> operations as I create different reports. >> >> I am not looking to replicate the Pandas data-frame functionality in >> Haskell. First thing I want to do is reach out to the 'record' data >> structure. Here are some ideas I have: >> >> 1. I need to declare all these 100+ columns into multiple record >> structures. >> 2. Some of the columns can have NULL/NaN values. Therefore, some of the >> attributes of the record structure would be 'MayBe' values. Now, I could >> drop some columns during load and cut down the number of attributes i >> created per record structure. >> 3. Create a dictionary of each record structure which will help me index >> into into them.' >> >> I would like some feedback on the first 2 points. Seems like there is a >> lot of boiler plate code I have to generate for creating 100s of record >> attributes. Is this the only sane way to do this? What other patterns >> should I consider while solving such a problem. >> >> Also, I do not want to add too many dependencies into the project, but >> open to suggestions. >> >> Any input/advice on this would be very helpful. >> >> Thank you for the time! >> Guru >> _______________________________________________ >> 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. > > > _______________________________________________ > 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. > -- http://www.saurabhnanda.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Oct 1 18:53:44 2017 From: will.yager at gmail.com (William Yager) Date: Sun, 1 Oct 2017 14:53:44 -0400 Subject: [Haskell-cafe] ANN: hledger 1.4 In-Reply-To: <22501960-62EA-4312-A5FC-CB966A38BCE6@joyful.com> References: <22501960-62EA-4312-A5FC-CB966A38BCE6@joyful.com> Message-ID: Excellent work! I was just thinking that it will be annoying to have to de-duplicate subsequent CSV imports. Looks like the new import command will solve that nicely! On Sat, Sep 30, 2017 at 10:36 PM, Simon Michael wrote: > Aloha! I'm pleased to announce hledger 1.4. > > import (detects new transactions in multiple input files and adds them > to the main journal, particularly useful with CSV downloads). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sun Oct 1 18:58:30 2017 From: imantc at gmail.com (Imants Cekusins) Date: Sun, 1 Oct 2017 21:58:30 +0300 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: > Is this the only sane way to do this? Would Mutable Vector per column do? http://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Mutable.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at seas.upenn.edu Sun Oct 1 20:58:36 2017 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sun, 1 Oct 2017 16:58:36 -0400 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: > On Sep 30, 2017, at 9:30 PM, Guru Devanla wrote: > > Hello All, > > I am in the process of replicating some code in Python in Haskell. > > In Python, I load a couple of csv files, each file having more than 100 columns into a Pandas' data frame. Panda's data-frame, in short is a tabular structure which lets me performs on bunch of joins, and filter out data. I generated different shapes of reports using these operations. Of course, I would love some type checking to help me with these merge, join operations as I create different reports. > > I am not looking to replicate the Pandas data-frame functionality in Haskell. First thing I want to do is reach out to the 'record' data structure. Here are some ideas I have: > > 1. I need to declare all these 100+ columns into multiple record structures. > 2. Some of the columns can have NULL/NaN values. Therefore, some of the attributes of the record structure would be 'MayBe' values. Now, I could drop some columns during load and cut down the number of attributes i created per record structure. > 3. Create a dictionary of each record structure which will help me index into into them.' > > I would like some feedback on the first 2 points. Seems like there is a lot of boiler plate code I have to generate for creating 100s of record attributes. Is this the only sane way to do this? What other patterns should I consider while solving such a problem. > > Also, I do not want to add too many dependencies into the project, but open to suggestions. > > Any input/advice on this would be very helpful. > > Thank you for the time! > Guru The Frames package generates a vinyl record based on your data (like hlist; with a functor parameter that can be Maybe to support missing data), storing each column in a vector for very good runtime performance. As you get past 100 columns, you may encounter compile-time performance issues. If you have a sample data file you can make available, I can help diagnose performance troubles. Anthony From gurudev.devanla at gmail.com Mon Oct 2 01:55:05 2017 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sun, 1 Oct 2017 18:55:05 -0700 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: Thank you all for your helpful suggestions. As I wrote the original question, even I was trying to decide between the approach of using Records to represent each row or define a vector for each column and each vector becomes an attribute of the record. Even, I was leaning towards the latter given the performance needs. Since, the file is currently available as a CSV adding Persistent and any ORM library would be an added dependency. I was trying to solve this problem without too many dependencies of other libraries and wanting to learn new DSLs. Its a tempting time killer as everyone here would understand. @Anthony Thank your for your answer as well. I have explored Frames library in the past as I tried to look for Pandas like features in Haskell The library is useful and I have played around with it. But, I was never confident in adopting it for a serious project. Part of my reluctance, would be the learning curve plus I also need to familiarize myself with `lens` as well. But, looks like this project I have in hand is a good motivation to do both. I will try to use Frames and then report back. Also, apologies for not being able to share the data I am working on. With the original question, what I was trying to get to is, how are these kinds of problems solved in real-world projects. Like when Haskell is used in data mining, or in financial applications. I believe these applications deal with this kind of data where the tables are wide. Having to not have something which I can quickly start off on troubles me and makes me wonder if the reason is my lack of understanding or just the pain of using static typing. Regards On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley wrote: > > > > On Sep 30, 2017, at 9:30 PM, Guru Devanla > wrote: > > > > Hello All, > > > > I am in the process of replicating some code in Python in Haskell. > > > > In Python, I load a couple of csv files, each file having more than 100 > columns into a Pandas' data frame. Panda's data-frame, in short is a > tabular structure which lets me performs on bunch of joins, and filter out > data. I generated different shapes of reports using these operations. Of > course, I would love some type checking to help me with these merge, join > operations as I create different reports. > > > > I am not looking to replicate the Pandas data-frame functionality in > Haskell. First thing I want to do is reach out to the 'record' data > structure. Here are some ideas I have: > > > > 1. I need to declare all these 100+ columns into multiple record > structures. > > 2. Some of the columns can have NULL/NaN values. Therefore, some of the > attributes of the record structure would be 'MayBe' values. Now, I could > drop some columns during load and cut down the number of attributes i > created per record structure. > > 3. Create a dictionary of each record structure which will help me > index into into them.' > > > > I would like some feedback on the first 2 points. Seems like there is a > lot of boiler plate code I have to generate for creating 100s of record > attributes. Is this the only sane way to do this? What other patterns > should I consider while solving such a problem. > > > > Also, I do not want to add too many dependencies into the project, but > open to suggestions. > > > > Any input/advice on this would be very helpful. > > > > Thank you for the time! > > Guru > > The Frames package generates a vinyl record based on your data (like > hlist; with a functor parameter that can be Maybe to support missing data), > storing each column in a vector for very good runtime performance. As you > get past 100 columns, you may encounter compile-time performance issues. If > you have a sample data file you can make available, I can help diagnose > performance troubles. > > Anthony > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Mon Oct 2 02:22:09 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Mon, 2 Oct 2017 07:52:09 +0530 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: > Having to not have something which I can quickly start off on What do you mean by that? And what precisely is the discomfort between Haskell vs python for your use-case? On 02-Oct-2017 7:29 AM, "Guru Devanla" wrote: > Thank you all for your helpful suggestions. As I wrote the original > question, even I was trying to decide between the approach of using Records > to represent each row or define a vector for each column and each vector > becomes an attribute of the record. Even, I was leaning towards the latter > given the performance needs. > > Since, the file is currently available as a CSV adding Persistent and any > ORM library would be an added dependency. > > I was trying to solve this problem without too many dependencies of other > libraries and wanting to learn new DSLs. Its a tempting time killer as > everyone here would understand. > > @Anthony Thank your for your answer as well. I have explored Frames > library in the past as I tried to look for Pandas like features in Haskell > The library is useful and I have played around with it. But, I was never > confident in adopting it for a serious project. Part of my reluctance, > would be the learning curve plus I also need to familiarize myself with > `lens` as well. But, looks like this project I have in hand is a good > motivation to do both. I will try to use Frames and then report back. Also, > apologies for not being able to share the data I am working on. > > With the original question, what I was trying to get to is, how are these > kinds of problems solved in real-world projects. Like when Haskell is used > in data mining, or in financial applications. I believe these applications > deal with this kind of data where the tables are wide. Having to not have > something which I can quickly start off on troubles me and makes me wonder > if the reason is my lack of understanding or just the pain of using static > typing. > > Regards > > > On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley > wrote: > >> >> >> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >> wrote: >> > >> > Hello All, >> > >> > I am in the process of replicating some code in Python in Haskell. >> > >> > In Python, I load a couple of csv files, each file having more than 100 >> columns into a Pandas' data frame. Panda's data-frame, in short is a >> tabular structure which lets me performs on bunch of joins, and filter out >> data. I generated different shapes of reports using these operations. Of >> course, I would love some type checking to help me with these merge, join >> operations as I create different reports. >> > >> > I am not looking to replicate the Pandas data-frame functionality in >> Haskell. First thing I want to do is reach out to the 'record' data >> structure. Here are some ideas I have: >> > >> > 1. I need to declare all these 100+ columns into multiple record >> structures. >> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >> the attributes of the record structure would be 'MayBe' values. Now, I >> could drop some columns during load and cut down the number of attributes i >> created per record structure. >> > 3. Create a dictionary of each record structure which will help me >> index into into them.' >> > >> > I would like some feedback on the first 2 points. Seems like there is a >> lot of boiler plate code I have to generate for creating 100s of record >> attributes. Is this the only sane way to do this? What other patterns >> should I consider while solving such a problem. >> > >> > Also, I do not want to add too many dependencies into the project, but >> open to suggestions. >> > >> > Any input/advice on this would be very helpful. >> > >> > Thank you for the time! >> > Guru >> >> The Frames package generates a vinyl record based on your data (like >> hlist; with a functor parameter that can be Maybe to support missing data), >> storing each column in a vector for very good runtime performance. As you >> get past 100 columns, you may encounter compile-time performance issues. If >> you have a sample data file you can make available, I can help diagnose >> performance troubles. >> >> Anthony >> >> >> > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Mon Oct 2 02:49:56 2017 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sun, 1 Oct 2017 19:49:56 -0700 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: Did not mean to complain. For example, being able to use Data Frame library in Pandas, did not involve a big learning curve to understand the syntax of Pandas. With the basic knowledge of Python is was easy to learn and start using it. Trying, to replicate that kind of program in Haskell seems to be a lot difficult for me. For example, the leap from dynamic typing to static typing does involve this kind of boiler plate an I am fine with it. Now, when I try to reach out to the libraries in use, it involves a lot of learning of the library syntax/special operators etc to get stuff done. I understand that is the philosophy eschewed by Haskell community, but it takes up a lot of the spare time I have to both learn and also build my toy projects. I love coding in Haskell. But, that love takes a lot of time before it translates to any good code I can show. It could be just me. Again, I am happy to do this out of my love for Haskell. But, I am hesitant to recommend that to other team members since it is difficult for me to quantify the gains. And I say this with limited experience building real world Haskell applications and therefore my train of thought is totally mis-guided. On Sun, Oct 1, 2017 at 7:22 PM, Saurabh Nanda wrote: > > Having to not have something which I can quickly start off on > > What do you mean by that? And what precisely is the discomfort between > Haskell vs python for your use-case? > > On 02-Oct-2017 7:29 AM, "Guru Devanla" wrote: > >> Thank you all for your helpful suggestions. As I wrote the original >> question, even I was trying to decide between the approach of using Records >> to represent each row or define a vector for each column and each vector >> becomes an attribute of the record. Even, I was leaning towards the latter >> given the performance needs. >> >> Since, the file is currently available as a CSV adding Persistent and any >> ORM library would be an added dependency. >> >> I was trying to solve this problem without too many dependencies of other >> libraries and wanting to learn new DSLs. Its a tempting time killer as >> everyone here would understand. >> >> @Anthony Thank your for your answer as well. I have explored Frames >> library in the past as I tried to look for Pandas like features in Haskell >> The library is useful and I have played around with it. But, I was never >> confident in adopting it for a serious project. Part of my reluctance, >> would be the learning curve plus I also need to familiarize myself with >> `lens` as well. But, looks like this project I have in hand is a good >> motivation to do both. I will try to use Frames and then report back. Also, >> apologies for not being able to share the data I am working on. >> >> With the original question, what I was trying to get to is, how are these >> kinds of problems solved in real-world projects. Like when Haskell is used >> in data mining, or in financial applications. I believe these applications >> deal with this kind of data where the tables are wide. Having to not have >> something which I can quickly start off on troubles me and makes me wonder >> if the reason is my lack of understanding or just the pain of using static >> typing. >> >> Regards >> >> >> On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley >> wrote: >> >>> >>> >>> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >>> wrote: >>> > >>> > Hello All, >>> > >>> > I am in the process of replicating some code in Python in Haskell. >>> > >>> > In Python, I load a couple of csv files, each file having more than >>> 100 columns into a Pandas' data frame. Panda's data-frame, in short is a >>> tabular structure which lets me performs on bunch of joins, and filter out >>> data. I generated different shapes of reports using these operations. Of >>> course, I would love some type checking to help me with these merge, join >>> operations as I create different reports. >>> > >>> > I am not looking to replicate the Pandas data-frame functionality in >>> Haskell. First thing I want to do is reach out to the 'record' data >>> structure. Here are some ideas I have: >>> > >>> > 1. I need to declare all these 100+ columns into multiple record >>> structures. >>> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >>> the attributes of the record structure would be 'MayBe' values. Now, I >>> could drop some columns during load and cut down the number of attributes i >>> created per record structure. >>> > 3. Create a dictionary of each record structure which will help me >>> index into into them.' >>> > >>> > I would like some feedback on the first 2 points. Seems like there is >>> a lot of boiler plate code I have to generate for creating 100s of record >>> attributes. Is this the only sane way to do this? What other patterns >>> should I consider while solving such a problem. >>> > >>> > Also, I do not want to add too many dependencies into the project, but >>> open to suggestions. >>> > >>> > Any input/advice on this would be very helpful. >>> > >>> > Thank you for the time! >>> > Guru >>> >>> The Frames package generates a vinyl record based on your data (like >>> hlist; with a functor parameter that can be Maybe to support missing data), >>> storing each column in a vector for very good runtime performance. As you >>> get past 100 columns, you may encounter compile-time performance issues. If >>> you have a sample data file you can make available, I can help diagnose >>> performance troubles. >>> >>> Anthony >>> >>> >>> >> >> _______________________________________________ >> 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil_mayhew at users.sourceforge.net Mon Oct 2 03:24:26 2017 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Sun, 1 Oct 2017 21:24:26 -0600 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: <60bbb466-db44-ef37-9a0b-ab3698eba713@users.sourceforge.net> On 2017-10-01 07:55 PM, Guru Devanla wrote: > Having to not have something which I can quickly start off on troubles > me and makes me wonder if the reason is my lack of understanding or > just the pain of using static typing. Something, somewhere has to keep track of the type of each column, and since the data doesn’t have that itself you have to store it somewhere else. That could be in another data file of some kind which would be loaded at runtime, but then you would lose the benefit of static type checking by the compiler. So it’s better to have it in source code, even if that’s generated by TH or some other process. I recommend taking a look at the Cassava library. You can do some pretty neat things with it, including defining your own mapping from rows to records. In particular, if you need only a small subset of the 100 columns, you can provide a (de)serializer that looks at only the columns it needs. The library reads the row into a vector of Text, and your serialization code works with just the elements it needs. You could even have different record types (and associated serializers) for different tasks, all working off the same input record, since the serialization methods are from a typeclass and each record type can be a different instance of the class. Cassava supports Applicative, which makes for some very succinct code, and it can make use of a header record at the start of the data. Here’s an example: |data Account = Business | Visa | Personal | Cash | None deriving (Eq, Ord, Show, Read, Enum, Bounded) instance FromField Account where parseField f | f == "B" = pure Business | f == "V" = pure Visa | f == "P" = pure Personal | f == "C" = pure Cash | f == "CC" = pure Visa | f == "" = pure None | otherwise = fail $ "Invalid account type: \"" ++ B.unpack f ++ "\"" instance ToField Account where toField Business = "B" toField Visa = "V" toField Personal = "P" toField Cash = "C" toField None = "" type Money = Centi data Transaction = Transaction { date :: Day , description :: Text , category :: Text , account :: Account , debit :: Maybe Money , credit :: Maybe Money , business :: Money , visa :: Money , personal :: Money , cash :: Money } deriving (Eq, Ord, Show, Read) instance FromNamedRecord Transaction where parseNamedRecord r = Transaction <$> r .: "Date" <*> r .: "Description" <*> r .: "Category" <*> r .: "Account" <*> r .: "Debit" <*> r .: "Credit" <*> r .: "Business" <*> r .: "Visa" <*> r .: "Personal" <*> r .: "Cash" instance ToNamedRecord Transaction where toNamedRecord r = namedRecord [ "Date" .= date r, "Description" .= description r, "Category" .= category r, "Account" .= account r, "Debit" .= debit r, "Credit" .= credit r, "Business" .= business r, "Visa" .= visa r, "Personal" .= personal r, "Cash" .= cash r] | Note that the code doesn’t assume fixed positions for the different columns, nor a total number of columns in a row, because it indirects through the column headers. There could be 1000 columns and the code wouldn’t care. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at seas.upenn.edu Mon Oct 2 03:46:10 2017 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Sun, 1 Oct 2017 23:46:10 -0400 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: <39EF581F-6D1E-4382-9083-7A24B4A4D69B@seas.upenn.edu> > On Oct 1, 2017, at 9:55 PM, Guru Devanla wrote: > > Thank you all for your helpful suggestions. As I wrote the original question, even I was trying to decide between the approach of using Records to represent each row or define a vector for each column and each vector becomes an attribute of the record. Even, I was leaning towards the latter given the performance needs. > > Since, the file is currently available as a CSV adding Persistent and any ORM library would be an added dependency. > > I was trying to solve this problem without too many dependencies of other libraries and wanting to learn new DSLs. Its a tempting time killer as everyone here would understand. > > @Anthony Thank your for your answer as well. I have explored Frames library in the past as I tried to look for Pandas like features in Haskell The library is useful and I have played around with it. But, I was never confident in adopting it for a serious project. Part of my reluctance, would be the learning curve plus I also need to familiarize myself with `lens` as well. But, looks like this project I have in hand is a good motivation to do both. I will try to use Frames and then report back. Also, apologies for not being able to share the data I am working on. > > With the original question, what I was trying to get to is, how are these kinds of problems solved in real-world projects. Like when Haskell is used in data mining, or in financial applications. I believe these applications deal with this kind of data where the tables are wide. Having to not have something which I can quickly start off on troubles me and makes me wonder if the reason is my lack of understanding or just the pain of using static typing. > > Regards The pain is that of a rock yet to be smoothed by a running current: it is neither your lack of understanding nor something inherent to static typing. I ask for a sample file because the only way we can improve is through contact with real world use. I can say that Frames has been demonstrated to give performance neck and neck with Pandas in conjunction with greatly reduced (ie order of magnitude less) memory use. You also get the confidence of writing transformation and reduction functions whose types are consistent with your actual data, and that consistency can be verified as you type by tooling like Intero. Your concerns are justified: the problem with using Haskell for data processing is that without attempts like Frames, you still have this disconnect between the types that characterize your data and the types delineating your program code. Add to this the comparative dearth of statistical analysis and plotting options between Haskell and R or Python, and you can see that Haskell only makes sense if you want to use it for other reasons (eg familiarity, or interpretation with streaming or server libraries where the Haskell ecosystem is healthy). In the realm of data analysis, you are taking a risk choosing Haskell, but it is not a thoughtless risk. The upside is compiler-verified safety, and runtime performance informed by that compile-time work. So I’ll be happy if you can help improve the Frames story, but it is certainly a story still in progress. Anthony > > >> On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley wrote: >> >> >> > On Sep 30, 2017, at 9:30 PM, Guru Devanla wrote: >> > >> > Hello All, >> > >> > I am in the process of replicating some code in Python in Haskell. >> > >> > In Python, I load a couple of csv files, each file having more than 100 columns into a Pandas' data frame. Panda's data-frame, in short is a tabular structure which lets me performs on bunch of joins, and filter out data. I generated different shapes of reports using these operations. Of course, I would love some type checking to help me with these merge, join operations as I create different reports. >> > >> > I am not looking to replicate the Pandas data-frame functionality in Haskell. First thing I want to do is reach out to the 'record' data structure. Here are some ideas I have: >> > >> > 1. I need to declare all these 100+ columns into multiple record structures. >> > 2. Some of the columns can have NULL/NaN values. Therefore, some of the attributes of the record structure would be 'MayBe' values. Now, I could drop some columns during load and cut down the number of attributes i created per record structure. >> > 3. Create a dictionary of each record structure which will help me index into into them.' >> > >> > I would like some feedback on the first 2 points. Seems like there is a lot of boiler plate code I have to generate for creating 100s of record attributes. Is this the only sane way to do this? What other patterns should I consider while solving such a problem. >> > >> > Also, I do not want to add too many dependencies into the project, but open to suggestions. >> > >> > Any input/advice on this would be very helpful. >> > >> > Thank you for the time! >> > Guru >> >> The Frames package generates a vinyl record based on your data (like hlist; with a functor parameter that can be Maybe to support missing data), storing each column in a vector for very good runtime performance. As you get past 100 columns, you may encounter compile-time performance issues. If you have a sample data file you can make available, I can help diagnose performance troubles. >> >> Anthony >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Mon Oct 2 04:02:12 2017 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sun, 1 Oct 2017 21:02:12 -0700 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: <39EF581F-6D1E-4382-9083-7A24B4A4D69B@seas.upenn.edu> References: <39EF581F-6D1E-4382-9083-7A24B4A4D69B@seas.upenn.edu> Message-ID: Yes, I am totally in agreement. My motivation to replicate this project and demonstrate the power of Haskell in these scenarios boils down to the 2 reasons you rightly mentioned: >> You also get the confidence of writing transformation and reduction functions whose types are consistent with your actual data, Just this aspect makes me loose sleep looking at Python code. I crave for such guarantees at compile-time and that is the reason why I am replicating this implementation in Haskell. I am sure I will get this guarantee is Haskell. **But, at what cost is what I am in the process of understanding.** >> The upside is compiler-verified safety, and runtime performance informed by that compile-time work. I agree with compiler-verified safety.* I will have to prove the performance part of this exercise to myself.* I was not able to share the data due to licensing restrictions. But, I will get in touch with you offline once I am at a point of sharing some stats. Thank you very much for your input and the effort you have been putting into Frames. Regards Guru On Sun, Oct 1, 2017 at 8:46 PM, Anthony Cowley wrote: > > > On Oct 1, 2017, at 9:55 PM, Guru Devanla > wrote: > > Thank you all for your helpful suggestions. As I wrote the original > question, even I was trying to decide between the approach of using Records > to represent each row or define a vector for each column and each vector > becomes an attribute of the record. Even, I was leaning towards the latter > given the performance needs. > > Since, the file is currently available as a CSV adding Persistent and any > ORM library would be an added dependency. > > I was trying to solve this problem without too many dependencies of other > libraries and wanting to learn new DSLs. Its a tempting time killer as > everyone here would understand. > > @Anthony Thank your for your answer as well. I have explored Frames > library in the past as I tried to look for Pandas like features in Haskell > The library is useful and I have played around with it. But, I was never > confident in adopting it for a serious project. Part of my reluctance, > would be the learning curve plus I also need to familiarize myself with > `lens` as well. But, looks like this project I have in hand is a good > motivation to do both. I will try to use Frames and then report back. Also, > apologies for not being able to share the data I am working on. > > With the original question, what I was trying to get to is, how are these > kinds of problems solved in real-world projects. Like when Haskell is used > in data mining, or in financial applications. I believe these applications > deal with this kind of data where the tables are wide. Having to not have > something which I can quickly start off on troubles me and makes me wonder > if the reason is my lack of understanding or just the pain of using static > typing. > > Regards > > > > The pain is that of a rock yet to be smoothed by a running current: it is > neither your lack of understanding nor something inherent to static typing. > I ask for a sample file because the only way we can improve is through > contact with real world use. I can say that Frames has been demonstrated to > give performance neck and neck with Pandas in conjunction with greatly > reduced (ie order of magnitude less) memory use. You also get the > confidence of writing transformation and reduction functions whose types > are consistent with your actual data, and that consistency can be verified > as you type by tooling like Intero. > > Your concerns are justified: the problem with using Haskell for data > processing is that without attempts like Frames, you still have this > disconnect between the types that characterize your data and the types > delineating your program code. Add to this the comparative dearth of > statistical analysis and plotting options between Haskell and R or Python, > and you can see that Haskell only makes sense if you want to use it for > other reasons (eg familiarity, or interpretation with streaming or server > libraries where the Haskell ecosystem is healthy). In the realm of data > analysis, you are taking a risk choosing Haskell, but it is not a > thoughtless risk. The upside is compiler-verified safety, and runtime > performance informed by that compile-time work. > > So I’ll be happy if you can help improve the Frames story, but it is > certainly a story still in progress. > > Anthony > > > > > On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley > wrote: > >> >> >> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >> wrote: >> > >> > Hello All, >> > >> > I am in the process of replicating some code in Python in Haskell. >> > >> > In Python, I load a couple of csv files, each file having more than 100 >> columns into a Pandas' data frame. Panda's data-frame, in short is a >> tabular structure which lets me performs on bunch of joins, and filter out >> data. I generated different shapes of reports using these operations. Of >> course, I would love some type checking to help me with these merge, join >> operations as I create different reports. >> > >> > I am not looking to replicate the Pandas data-frame functionality in >> Haskell. First thing I want to do is reach out to the 'record' data >> structure. Here are some ideas I have: >> > >> > 1. I need to declare all these 100+ columns into multiple record >> structures. >> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >> the attributes of the record structure would be 'MayBe' values. Now, I >> could drop some columns during load and cut down the number of attributes i >> created per record structure. >> > 3. Create a dictionary of each record structure which will help me >> index into into them.' >> > >> > I would like some feedback on the first 2 points. Seems like there is a >> lot of boiler plate code I have to generate for creating 100s of record >> attributes. Is this the only sane way to do this? What other patterns >> should I consider while solving such a problem. >> > >> > Also, I do not want to add too many dependencies into the project, but >> open to suggestions. >> > >> > Any input/advice on this would be very helpful. >> > >> > Thank you for the time! >> > Guru >> >> The Frames package generates a vinyl record based on your data (like >> hlist; with a functor parameter that can be Maybe to support missing data), >> storing each column in a vector for very good runtime performance. As you >> get past 100 columns, you may encounter compile-time performance issues. If >> you have a sample data file you can make available, I can help diagnose >> performance troubles. >> >> Anthony >> >> >> > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Mon Oct 2 05:00:01 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Mon, 2 Oct 2017 10:30:01 +0530 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: I whole heartedly agree with your sentiment. I have felt the same way in my initial days, and only my stubborn head prevented me from giving up on Haskell [1] Haskell is **unnecessarily** hard. It doesn't have to be that way. Stop beating yourself up over what is essentially a tooling, API design, and documentation problem. Start speaking up instead. Wrt the current problem at hand, try thinking of the types as a **spec** rather than boilerplate. That spec is necessary to give you your compile time guarantees. Without the spec the compiler can't do anything. This spec is non-existent in python. Also, be sure of what exactly is the warm fuzzy feeling that the compiler is giving you. From whatever you have described, most of your bugs are going to occur when you change your data transformation pipeline (core logic) or your CSV format. Compilation and static types will help in only one of those. [1] https://medium.com/@saurabhnanda/why-building-web-apps-in-haskell-is-harder-than-it-ought-to-be-c9b13de0be4f On 02-Oct-2017 8:20 AM, "Guru Devanla" wrote: Did not mean to complain. For example, being able to use Data Frame library in Pandas, did not involve a big learning curve to understand the syntax of Pandas. With the basic knowledge of Python is was easy to learn and start using it. Trying, to replicate that kind of program in Haskell seems to be a lot difficult for me. For example, the leap from dynamic typing to static typing does involve this kind of boiler plate an I am fine with it. Now, when I try to reach out to the libraries in use, it involves a lot of learning of the library syntax/special operators etc to get stuff done. I understand that is the philosophy eschewed by Haskell community, but it takes up a lot of the spare time I have to both learn and also build my toy projects. I love coding in Haskell. But, that love takes a lot of time before it translates to any good code I can show. It could be just me. Again, I am happy to do this out of my love for Haskell. But, I am hesitant to recommend that to other team members since it is difficult for me to quantify the gains. And I say this with limited experience building real world Haskell applications and therefore my train of thought is totally mis-guided. On Sun, Oct 1, 2017 at 7:22 PM, Saurabh Nanda wrote: > > Having to not have something which I can quickly start off on > > What do you mean by that? And what precisely is the discomfort between > Haskell vs python for your use-case? > > On 02-Oct-2017 7:29 AM, "Guru Devanla" wrote: > >> Thank you all for your helpful suggestions. As I wrote the original >> question, even I was trying to decide between the approach of using Records >> to represent each row or define a vector for each column and each vector >> becomes an attribute of the record. Even, I was leaning towards the latter >> given the performance needs. >> >> Since, the file is currently available as a CSV adding Persistent and any >> ORM library would be an added dependency. >> >> I was trying to solve this problem without too many dependencies of other >> libraries and wanting to learn new DSLs. Its a tempting time killer as >> everyone here would understand. >> >> @Anthony Thank your for your answer as well. I have explored Frames >> library in the past as I tried to look for Pandas like features in Haskell >> The library is useful and I have played around with it. But, I was never >> confident in adopting it for a serious project. Part of my reluctance, >> would be the learning curve plus I also need to familiarize myself with >> `lens` as well. But, looks like this project I have in hand is a good >> motivation to do both. I will try to use Frames and then report back. Also, >> apologies for not being able to share the data I am working on. >> >> With the original question, what I was trying to get to is, how are these >> kinds of problems solved in real-world projects. Like when Haskell is used >> in data mining, or in financial applications. I believe these applications >> deal with this kind of data where the tables are wide. Having to not have >> something which I can quickly start off on troubles me and makes me wonder >> if the reason is my lack of understanding or just the pain of using static >> typing. >> >> Regards >> >> >> On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley >> wrote: >> >>> >>> >>> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >>> wrote: >>> > >>> > Hello All, >>> > >>> > I am in the process of replicating some code in Python in Haskell. >>> > >>> > In Python, I load a couple of csv files, each file having more than >>> 100 columns into a Pandas' data frame. Panda's data-frame, in short is a >>> tabular structure which lets me performs on bunch of joins, and filter out >>> data. I generated different shapes of reports using these operations. Of >>> course, I would love some type checking to help me with these merge, join >>> operations as I create different reports. >>> > >>> > I am not looking to replicate the Pandas data-frame functionality in >>> Haskell. First thing I want to do is reach out to the 'record' data >>> structure. Here are some ideas I have: >>> > >>> > 1. I need to declare all these 100+ columns into multiple record >>> structures. >>> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >>> the attributes of the record structure would be 'MayBe' values. Now, I >>> could drop some columns during load and cut down the number of attributes i >>> created per record structure. >>> > 3. Create a dictionary of each record structure which will help me >>> index into into them.' >>> > >>> > I would like some feedback on the first 2 points. Seems like there is >>> a lot of boiler plate code I have to generate for creating 100s of record >>> attributes. Is this the only sane way to do this? What other patterns >>> should I consider while solving such a problem. >>> > >>> > Also, I do not want to add too many dependencies into the project, but >>> open to suggestions. >>> > >>> > Any input/advice on this would be very helpful. >>> > >>> > Thank you for the time! >>> > Guru >>> >>> The Frames package generates a vinyl record based on your data (like >>> hlist; with a functor parameter that can be Maybe to support missing data), >>> storing each column in a vector for very good runtime performance. As you >>> get past 100 columns, you may encounter compile-time performance issues. If >>> you have a sample data file you can make available, I can help diagnose >>> performance troubles. >>> >>> Anthony >>> >>> >>> >> >> _______________________________________________ >> 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vhaisman at gmail.com Mon Oct 2 13:43:43 2017 From: vhaisman at gmail.com (=?UTF-8?Q?V=C3=A1clav_Haisman?=) Date: Mon, 2 Oct 2017 15:43:43 +0200 Subject: [Haskell-cafe] hs-bibutils 6.2 candidate package Message-ID: Hi. I have created a candidate package for hs-bibutils 6.2. This synchronizes the hs-bibutils with Bibutils which it wraps. The candidate is at https://hackage.haskell.org/package/hs-bibutils-6.2/candidate. Please check it out and test it if you are interested. -- VH From gurudev.devanla at gmail.com Mon Oct 2 14:56:51 2017 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Mon, 2 Oct 2017 07:56:51 -0700 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: Yes, Thank you for the encouraging words. I will keep at it. >> Also, be sure of what exactly is the warm fuzzy feeling that the compiler is giving you. From whatever you have described, most of your bugs are going to occur when you change your data transformation pipeline (core logic) or your CSV format. Compilation and static types will help in only one of those. Yes, i am aware of that. I have tests for the core logic, but the mechanical part of type checking the data that passes through this pipeline is much desired. On Sun, Oct 1, 2017 at 10:00 PM, Saurabh Nanda wrote: > I whole heartedly agree with your sentiment. I have felt the same way in > my initial days, and only my stubborn head prevented me from giving up on > Haskell [1] > > Haskell is **unnecessarily** hard. It doesn't have to be that way. Stop > beating yourself up over what is essentially a tooling, API design, and > documentation problem. Start speaking up instead. > > Wrt the current problem at hand, try thinking of the types as a **spec** > rather than boilerplate. That spec is necessary to give you your compile > time guarantees. Without the spec the compiler can't do anything. This spec > is non-existent in python. > > Also, be sure of what exactly is the warm fuzzy feeling that the compiler > is giving you. From whatever you have described, most of your bugs are > going to occur when you change your data transformation pipeline (core > logic) or your CSV format. Compilation and static types will help in only > one of those. > > [1] https://medium.com/@saurabhnanda/why-building-web- > apps-in-haskell-is-harder-than-it-ought-to-be-c9b13de0be4f > > > On 02-Oct-2017 8:20 AM, "Guru Devanla" wrote: > > Did not mean to complain. For example, being able to use Data Frame > library in Pandas, did not involve a big learning curve to understand the > syntax of Pandas. With the basic knowledge of Python is was easy to learn > and start using it. Trying, to replicate that kind of program in Haskell > seems to be a lot difficult for me. For example, the leap from dynamic > typing to static typing does involve this kind of boiler plate an I am fine > with it. Now, when I try to reach out to the libraries in use, it involves > a lot of learning of the library syntax/special operators etc to get stuff > done. > I understand that is the philosophy eschewed by Haskell community, but it > takes up a lot of the spare time I have to both learn and also build my toy > projects. I love coding in Haskell. But, that love takes a lot of time > before it translates to any good code I can show. It could be just me. > > Again, I am happy to do this out of my love for Haskell. But, I am > hesitant to recommend that to other team members since it is difficult for > me to quantify the gains. And I say this with limited experience building > real world Haskell applications and therefore my train of thought is > totally mis-guided. > > On Sun, Oct 1, 2017 at 7:22 PM, Saurabh Nanda > wrote: > >> > Having to not have something which I can quickly start off on >> >> What do you mean by that? And what precisely is the discomfort between >> Haskell vs python for your use-case? >> >> On 02-Oct-2017 7:29 AM, "Guru Devanla" wrote: >> >>> Thank you all for your helpful suggestions. As I wrote the original >>> question, even I was trying to decide between the approach of using Records >>> to represent each row or define a vector for each column and each vector >>> becomes an attribute of the record. Even, I was leaning towards the latter >>> given the performance needs. >>> >>> Since, the file is currently available as a CSV adding Persistent and >>> any ORM library would be an added dependency. >>> >>> I was trying to solve this problem without too many dependencies of >>> other libraries and wanting to learn new DSLs. Its a tempting time killer >>> as everyone here would understand. >>> >>> @Anthony Thank your for your answer as well. I have explored Frames >>> library in the past as I tried to look for Pandas like features in Haskell >>> The library is useful and I have played around with it. But, I was never >>> confident in adopting it for a serious project. Part of my reluctance, >>> would be the learning curve plus I also need to familiarize myself with >>> `lens` as well. But, looks like this project I have in hand is a good >>> motivation to do both. I will try to use Frames and then report back. Also, >>> apologies for not being able to share the data I am working on. >>> >>> With the original question, what I was trying to get to is, how are >>> these kinds of problems solved in real-world projects. Like when Haskell is >>> used in data mining, or in financial applications. I believe these >>> applications deal with this kind of data where the tables are wide. Having >>> to not have something which I can quickly start off on troubles me and >>> makes me wonder if the reason is my lack of understanding or just the pain >>> of using static typing. >>> >>> Regards >>> >>> >>> On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley >>> wrote: >>> >>>> >>>> >>>> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >>>> wrote: >>>> > >>>> > Hello All, >>>> > >>>> > I am in the process of replicating some code in Python in Haskell. >>>> > >>>> > In Python, I load a couple of csv files, each file having more than >>>> 100 columns into a Pandas' data frame. Panda's data-frame, in short is a >>>> tabular structure which lets me performs on bunch of joins, and filter out >>>> data. I generated different shapes of reports using these operations. Of >>>> course, I would love some type checking to help me with these merge, join >>>> operations as I create different reports. >>>> > >>>> > I am not looking to replicate the Pandas data-frame functionality in >>>> Haskell. First thing I want to do is reach out to the 'record' data >>>> structure. Here are some ideas I have: >>>> > >>>> > 1. I need to declare all these 100+ columns into multiple record >>>> structures. >>>> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >>>> the attributes of the record structure would be 'MayBe' values. Now, I >>>> could drop some columns during load and cut down the number of attributes i >>>> created per record structure. >>>> > 3. Create a dictionary of each record structure which will help me >>>> index into into them.' >>>> > >>>> > I would like some feedback on the first 2 points. Seems like there is >>>> a lot of boiler plate code I have to generate for creating 100s of record >>>> attributes. Is this the only sane way to do this? What other patterns >>>> should I consider while solving such a problem. >>>> > >>>> > Also, I do not want to add too many dependencies into the project, >>>> but open to suggestions. >>>> > >>>> > Any input/advice on this would be very helpful. >>>> > >>>> > Thank you for the time! >>>> > Guru >>>> >>>> The Frames package generates a vinyl record based on your data (like >>>> hlist; with a functor parameter that can be Maybe to support missing data), >>>> storing each column in a vector for very good runtime performance. As you >>>> get past 100 columns, you may encounter compile-time performance issues. If >>>> you have a sample data file you can make available, I can help diagnose >>>> performance troubles. >>>> >>>> Anthony >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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. >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Mon Oct 2 23:42:25 2017 From: simon at joyful.com (Simon Michael) Date: Mon, 2 Oct 2017 13:42:25 -1000 Subject: [Haskell-cafe] EduHaskell In-Reply-To: References: <1E41D48D-AD5B-4C5F-9595-721392525C50@oregonstate.edu> Message-ID: On 9/24/17 5:19 PM, Stuart A. Kurtz wrote: > Here's the URL for our first lecture: > > http://cmsc-16100.cs.uchicago.edu/2017/Lectures/01/intro.php Enjoyed it! Thank you. From saurabhnanda at gmail.com Tue Oct 3 05:04:01 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Tue, 3 Oct 2017 10:34:01 +0530 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: Do evaluate the option of peeking at the first few rows of the CSV and generating the types via code-gen. This will allow your transformation pipeline to fail-fast if your CSV format changes. On 02-Oct-2017 8:27 PM, "Guru Devanla" wrote: > Yes, Thank you for the encouraging words. I will keep at it. > > >> Also, be sure of what exactly is the warm fuzzy feeling that the > compiler is giving you. From whatever you have described, most of your bugs > are going to occur when you change your data transformation pipeline (core > logic) or your CSV format. Compilation and static types will help in only > one of those. > > Yes, i am aware of that. I have tests for the core logic, but the > mechanical part of type checking the data that passes through this pipeline > is much desired. > > > > > On Sun, Oct 1, 2017 at 10:00 PM, Saurabh Nanda > wrote: > >> I whole heartedly agree with your sentiment. I have felt the same way in >> my initial days, and only my stubborn head prevented me from giving up on >> Haskell [1] >> >> Haskell is **unnecessarily** hard. It doesn't have to be that way. Stop >> beating yourself up over what is essentially a tooling, API design, and >> documentation problem. Start speaking up instead. >> >> Wrt the current problem at hand, try thinking of the types as a **spec** >> rather than boilerplate. That spec is necessary to give you your compile >> time guarantees. Without the spec the compiler can't do anything. This spec >> is non-existent in python. >> >> Also, be sure of what exactly is the warm fuzzy feeling that the compiler >> is giving you. From whatever you have described, most of your bugs are >> going to occur when you change your data transformation pipeline (core >> logic) or your CSV format. Compilation and static types will help in only >> one of those. >> >> [1] https://medium.com/@saurabhnanda/why-building-web-apps- >> in-haskell-is-harder-than-it-ought-to-be-c9b13de0be4f >> >> >> On 02-Oct-2017 8:20 AM, "Guru Devanla" wrote: >> >> Did not mean to complain. For example, being able to use Data Frame >> library in Pandas, did not involve a big learning curve to understand the >> syntax of Pandas. With the basic knowledge of Python is was easy to learn >> and start using it. Trying, to replicate that kind of program in Haskell >> seems to be a lot difficult for me. For example, the leap from dynamic >> typing to static typing does involve this kind of boiler plate an I am fine >> with it. Now, when I try to reach out to the libraries in use, it involves >> a lot of learning of the library syntax/special operators etc to get stuff >> done. >> I understand that is the philosophy eschewed by Haskell community, but it >> takes up a lot of the spare time I have to both learn and also build my toy >> projects. I love coding in Haskell. But, that love takes a lot of time >> before it translates to any good code I can show. It could be just me. >> >> Again, I am happy to do this out of my love for Haskell. But, I am >> hesitant to recommend that to other team members since it is difficult for >> me to quantify the gains. And I say this with limited experience building >> real world Haskell applications and therefore my train of thought is >> totally mis-guided. >> >> On Sun, Oct 1, 2017 at 7:22 PM, Saurabh Nanda >> wrote: >> >>> > Having to not have something which I can quickly start off on >>> >>> What do you mean by that? And what precisely is the discomfort between >>> Haskell vs python for your use-case? >>> >>> On 02-Oct-2017 7:29 AM, "Guru Devanla" >>> wrote: >>> >>>> Thank you all for your helpful suggestions. As I wrote the original >>>> question, even I was trying to decide between the approach of using Records >>>> to represent each row or define a vector for each column and each vector >>>> becomes an attribute of the record. Even, I was leaning towards the latter >>>> given the performance needs. >>>> >>>> Since, the file is currently available as a CSV adding Persistent and >>>> any ORM library would be an added dependency. >>>> >>>> I was trying to solve this problem without too many dependencies of >>>> other libraries and wanting to learn new DSLs. Its a tempting time killer >>>> as everyone here would understand. >>>> >>>> @Anthony Thank your for your answer as well. I have explored Frames >>>> library in the past as I tried to look for Pandas like features in Haskell >>>> The library is useful and I have played around with it. But, I was never >>>> confident in adopting it for a serious project. Part of my reluctance, >>>> would be the learning curve plus I also need to familiarize myself with >>>> `lens` as well. But, looks like this project I have in hand is a good >>>> motivation to do both. I will try to use Frames and then report back. Also, >>>> apologies for not being able to share the data I am working on. >>>> >>>> With the original question, what I was trying to get to is, how are >>>> these kinds of problems solved in real-world projects. Like when Haskell is >>>> used in data mining, or in financial applications. I believe these >>>> applications deal with this kind of data where the tables are wide. Having >>>> to not have something which I can quickly start off on troubles me and >>>> makes me wonder if the reason is my lack of understanding or just the pain >>>> of using static typing. >>>> >>>> Regards >>>> >>>> >>>> On Sun, Oct 1, 2017 at 1:58 PM, Anthony Cowley >>>> wrote: >>>> >>>>> >>>>> >>>>> > On Sep 30, 2017, at 9:30 PM, Guru Devanla >>>>> wrote: >>>>> > >>>>> > Hello All, >>>>> > >>>>> > I am in the process of replicating some code in Python in Haskell. >>>>> > >>>>> > In Python, I load a couple of csv files, each file having more than >>>>> 100 columns into a Pandas' data frame. Panda's data-frame, in short is a >>>>> tabular structure which lets me performs on bunch of joins, and filter out >>>>> data. I generated different shapes of reports using these operations. Of >>>>> course, I would love some type checking to help me with these merge, join >>>>> operations as I create different reports. >>>>> > >>>>> > I am not looking to replicate the Pandas data-frame functionality in >>>>> Haskell. First thing I want to do is reach out to the 'record' data >>>>> structure. Here are some ideas I have: >>>>> > >>>>> > 1. I need to declare all these 100+ columns into multiple record >>>>> structures. >>>>> > 2. Some of the columns can have NULL/NaN values. Therefore, some of >>>>> the attributes of the record structure would be 'MayBe' values. Now, I >>>>> could drop some columns during load and cut down the number of attributes i >>>>> created per record structure. >>>>> > 3. Create a dictionary of each record structure which will help me >>>>> index into into them.' >>>>> > >>>>> > I would like some feedback on the first 2 points. Seems like there >>>>> is a lot of boiler plate code I have to generate for creating 100s of >>>>> record attributes. Is this the only sane way to do this? What other >>>>> patterns should I consider while solving such a problem. >>>>> > >>>>> > Also, I do not want to add too many dependencies into the project, >>>>> but open to suggestions. >>>>> > >>>>> > Any input/advice on this would be very helpful. >>>>> > >>>>> > Thank you for the time! >>>>> > Guru >>>>> >>>>> The Frames package generates a vinyl record based on your data (like >>>>> hlist; with a functor parameter that can be Maybe to support missing data), >>>>> storing each column in a vector for very good runtime performance. As you >>>>> get past 100 columns, you may encounter compile-time performance issues. If >>>>> you have a sample data file you can make available, I can help diagnose >>>>> performance troubles. >>>>> >>>>> Anthony >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Tue Oct 3 08:48:16 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Tue, 3 Oct 2017 09:48:16 +0100 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: <81237A7F-5F17-4283-8D6C-03D107C92877@steinitz.org> I don’t know if this helps but here’s something I created in 5 minutes yesterday. Once you have the data you can convert to e.g. frames with all the help that types can give. I once used frames on a file with 10,000 columns and it worked (probably I shouldn’t have done this). Also an option is in Chris Done’s blog: https://www.fpcomplete.com/blog/2016/09/data-haskell PS My script below will fail if I have missing data but then I can use something better than read. > {-# OPTIONS_GHC -Wall #-} > > import qualified Data.Vector as V > import qualified Data.ByteString.Lazy as BL > import qualified Data.ByteString.Lazy.Char8 as BLC > import Data.Csv > import Data.List > import Plots > import Diagrams.Prelude > import Diagrams.Backend.Rasterific > > main :: IO () > main = do > evalsCsv <- BLC.readFile "/Users/dom/.local/share/simwork/data/Models/Lorenz.csv" > let records :: Either String (V.Vector (V.Vector BL.ByteString)) > records = decode NoHeader $ BLC.unlines $ BLC.lines evalsCsv > case records of > Left err -> putStrLn err > Right evals -> do > let hdrs :: V.Vector String > hdrs = V.map BLC.unpack $ V.head evals > let zss :: [[Double]] > zss = map (map read) $ map (map BLC.unpack) $ > transpose $ V.toList $ V.map V.toList $ V.drop 1 evals > renderRasterific "diagrams/lorenz.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!0) (zss!!1)) > renderRasterific "diagrams/lorenz1.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!0) (zss!!2)) > renderRasterific "diagrams/lorenz2.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!0) (zss!!3)) > renderRasterific "diagrams/lorenz3.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!1) (zss!!2)) > renderRasterific "diagrams/lorenz4.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!1) (zss!!3)) > renderRasterific "diagrams/lorenz5.png" (dims2D 500.0 500.0) > (renderAxis $ jSaxis (zss!!2) (zss!!3)) > > jSaxis :: [Double] -> [Double] -> Axis B V2 Double > jSaxis ts xs = r2Axis &~ do > linePlot' $ zip ts xs Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From arjenvanweelden at gmail.com Tue Oct 3 16:04:11 2017 From: arjenvanweelden at gmail.com (Arjen) Date: Tue, 03 Oct 2017 18:04:11 +0200 Subject: [Haskell-cafe] CfP: Dutch FP-day 2018 References: <1507046510.3643.4.camel@gmail.com> Message-ID: <1507046651.3643.6.camel@gmail.com> Dear all, The next Dutch Functional Programming day will take place on Friday 5th of January 2018, at the Walter Bos Complex of the Dutch Tax Service at the John F. Kennedylaan 8, Apeldoorn. This is the first call for presentations, and we apologize if you received multiple copies. If you would like to give a presentation, please send an e-mail to  a.van.weelden at belastingdienst.nl with a title,  abstract, name of the speaker and expected duration of the talk. We'll try our best to make a proper program out of it with various subjects related to functional programming. Please note that to the nature of the location, registration in advance is required. As well as matching identification (passport, driver's license, or similar) before entering the venue! Photography and/or setting up a local WiFi network is explicitly not allowed. A dinner (pizza's) and drinks will be provided free of charge at the end of the day at the same location. Given that registration is mandatory this time, we'll assume that you stay around for this unless you specify otherwise. More information about registering for attendance and a website with information about the schedule and location will follow soon(ish). Feel free to invite other people who might take an interest. Best regards and looking forward to seeing you, Betsy Pepels and Arjen van Weelden From vl81 at kent.ac.uk Tue Oct 3 17:59:15 2017 From: vl81 at kent.ac.uk (Vilem-Benjamin Liepelt) Date: Tue, 3 Oct 2017 18:59:15 +0100 Subject: [Haskell-cafe] Catch-all considered harmful? Message-ID: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> Catch-all considered harmful? ============================= I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts. Motivation ---------- Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price? I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.") I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs. My questions to the community— 1. Are there real world examples of bugs caused by catch-alls? 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases? 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls? Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence). Example ------- Consider the sum type: data Answer = No | Yes and the function: foo : Answer -> String foo Yes = "Woo-hoo!" foo _ = "Bother." Say we need to extend our sum type: data Answer = No | Perhaps | Yes However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences. (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl81 at kent.ac.uk Tue Oct 3 18:02:31 2017 From: vl81 at kent.ac.uk (Vilem-Benjamin Liepelt) Date: Tue, 3 Oct 2017 19:02:31 +0100 Subject: [Haskell-cafe] Catch-all considered harmful? In-Reply-To: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> References: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> Message-ID: PS: Some people have already commented on this here: https://gist.github.com/vimuel/ee9b054b42bbc2ed06992a323b7dfbd8 > On 2017-10-03, at 18:59, Vilem-Benjamin Liepelt wrote: > > Catch-all considered harmful? > ============================= > I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts. > > > Motivation > ---------- > Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price? > > I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.") > > I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs. > > My questions to the community— > > 1. Are there real world examples of bugs caused by catch-alls? > 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases? > 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls? > > Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence). > > > Example > ------- > Consider the sum type: > > data Answer = No | Yes > > and the function: > > foo : Answer -> String > foo Yes = "Woo-hoo!" > foo _ = "Bother." > > Say we need to extend our sum type: > > data Answer = No | Perhaps | Yes > > However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences. > > (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.) > > From cma at bitemyapp.com Tue Oct 3 18:04:58 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 3 Oct 2017 13:04:58 -0500 Subject: [Haskell-cafe] Catch-all considered harmful? In-Reply-To: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> References: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> Message-ID: We made it a policy at a previous company using Haskell to not use catch-all patterns whenever possible because it meant adding a new value to a sum type could mean silent problems. We had one bad experience with that, did the five-whys thing, never did it again. This mostly applied to the data types we made to represent domain specific information. Less true for stuff like `Int`, naturally. On Tue, Oct 3, 2017 at 12:59 PM, Vilem-Benjamin Liepelt wrote: > Catch-all considered harmful? > > ============================= > > I have been thinking about a potential source of bugs from catch-all pattern > matches on sum types and would like to know your thoughts. > > Motivation > > ---------- > > Totality is usually a desirable property of a function and the catch-all can > conveniently buy us totality. But at what price? > > I have been indoctrinated that rigour goes above convenience (think along > the lines of: "Once we indulge in the impurities of I/O, there is no > redemption.") > > I would like to evaluate the trade-offs between convenience for the > programmer and a potential source of bugs. > > My questions to the community— > > 1. Are there real world examples of bugs caused by catch-alls? > 2. Do you think that a language extension that disallows catch-alls (and > annotations to opt back in at pattern match sites or type declaration) could > be useful for certain code bases? > 3. If this is a potential problem, then can you think of any better > solutions a compiler could provide (i.e. that don't rely on an IDE / > structured editing) other than disallowing catch-alls? > > Feel free to chip in with your 2p (or 2¢), but please only if you have any > concrete experience (or compelling theoretical evidence). > > Example > > ------- > > Consider the sum type: > > data Answer = No | Yes > > and the function: > > foo : Answer -> String > foo Yes = "Woo-hoo!" > foo _ = "Bother." > > Say we need to extend our sum type: > > data Answer = No | Perhaps | Yes > > However, we forget to handle the new case appropriately in `foo`. The > compiler is happy, but at runtime `foo Perhaps` would evaluate to > `"Bother."`—with potentially catastrophic consequences. > > (Please imagine this happening in a large codebase with several > contributors, no single one of whom knows the entire codebase.) > > > > _______________________________________________ > 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. -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Tue Oct 3 18:07:58 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 3 Oct 2017 13:07:58 -0500 Subject: [Haskell-cafe] Catch-all considered harmful? In-Reply-To: References: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> Message-ID: Addendum: it's more a smell when you aren't unconditionally ignoring an sum type argument - it's when you're special casing _some_ behavior for specific constructors and then not doing so for others that I would tend to reject it on code review. On Tue, Oct 3, 2017 at 1:02 PM, Vilem-Benjamin Liepelt wrote: > PS: Some people have already commented on this here: https://gist.github.com/vimuel/ee9b054b42bbc2ed06992a323b7dfbd8 > >> On 2017-10-03, at 18:59, Vilem-Benjamin Liepelt wrote: >> >> Catch-all considered harmful? >> ============================= >> I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts. >> >> >> Motivation >> ---------- >> Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price? >> >> I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.") >> >> I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs. >> >> My questions to the community— >> >> 1. Are there real world examples of bugs caused by catch-alls? >> 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases? >> 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls? >> >> Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence). >> >> >> Example >> ------- >> Consider the sum type: >> >> data Answer = No | Yes >> >> and the function: >> >> foo : Answer -> String >> foo Yes = "Woo-hoo!" >> foo _ = "Bother." >> >> Say we need to extend our sum type: >> >> data Answer = No | Perhaps | Yes >> >> However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences. >> >> (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.) >> >> > > _______________________________________________ > 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. -- Chris Allen Currently working on http://haskellbook.com From lysxia at gmail.com Tue Oct 3 18:39:48 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 3 Oct 2017 14:39:48 -0400 Subject: [Haskell-cafe] Catch-all considered harmful? In-Reply-To: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> References: <2116CC86-B68A-4D82-9D97-FA4CD45CE8DA@kent.ac.uk> Message-ID: <17c0174d-c09d-b5c9-f5b8-b4bd0ade0da2@gmail.com> There was a discussion about that here some time ago: https://mail.haskell.org/pipermail/haskell-cafe/2017-January/126157.html Li-yao On 10/03/2017 01:59 PM, Vilem-Benjamin Liepelt wrote: > Catch-all considered harmful? > ============================= > > I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts. > > > Motivation > ---------- > > Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price? > > I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.") > > I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs. > > My questions to the community— > > 1. Are there real world examples of bugs caused by catch-alls? > 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases? > 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls? > > Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence). > > > Example > ------- > > Consider the sum type: > > data Answer = No | Yes > > and the function: > > foo : Answer -> String > foo Yes = "Woo-hoo!" > foo _ = "Bother." > > Say we need to extend our sum type: > > data Answer = No | Perhaps | Yes > > However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences. > > (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.) > > > > > _______________________________________________ > 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. From mblazevic at stilo.com Wed Oct 4 13:32:34 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Wed, 4 Oct 2017 09:32:34 -0400 Subject: [Haskell-cafe] Loading a csv file with ~200 columns into Haskell Record In-Reply-To: References: Message-ID: On 2017-09-30 09:30 PM, Guru Devanla wrote: > ... > I am not looking to replicate the Pandas data-frame functionality in > Haskell. First thing I want to do is reach out to the 'record' data > structure. Here are some ideas I have: > > 1.  I need to declare all these 100+ columns into multiple record > structures. > 2.  Some of the columns can have NULL/NaN values. Therefore, some of the > attributes of the record structure would be 'MayBe' values. Now, I could > drop some columns during load and cut down the number of attributes i > created per record structure. > 3.  Create a dictionary of each record structure which will help me > index into into them.' > > I would like some feedback on the first 2 points. Seems like there is a > lot of boiler plate code I have to generate for creating 100s of record > attributes. Is this the only sane way to do this?  What other patterns > should I consider while solving such a problem. I can only offer a suggestion with point #2. Have a look at the README for the rank2classes package. You'd still need to generate the boilerplate code for the 100+ record fields, but only once. http://hackage.haskell.org/package/rank2classes From guillaumh at gmail.com Wed Oct 4 14:22:53 2017 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Wed, 4 Oct 2017 11:22:53 -0300 Subject: [Haskell-cafe] claiming maintainer position of a HackageDB package Message-ID: Hi, I would like to submit a new version of the following package: https://hackage.haskell.org/package/mime-string Unfortunately, I only received private consent from the current maintainer that I would become the maintainer of this package, more than one month ago. Since then I had not received any answer to my request and I cannot upload a new version to HackageDB. Is there a procedure I could summon to become the maintainer of this package on HackageDB? Thanks Guillaume PS: for the anecdote, darcsden needs this new version of mime-string. From wolfgang-it at jeltsch.info Wed Oct 4 22:41:00 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Thu, 05 Oct 2017 01:41:00 +0300 Subject: [Haskell-cafe] Haskell in Leipzig 2017: 2nd call for participation Message-ID: <1507156860.28222.44.camel@jeltsch.info> Event:    Haskell in Leipzig 2017 Time:     October 26–28, 2017 Place:    HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Invited Speaker ===============   * Ivan Perez, University of Nottingham, UK Invited Performer =================   * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Registration ============ Registration information is available on the web page of the local organizers at http://nfa.imn.htwk-leipzig.de/HAL2017/. Program Committee =================   * Edward Amsden, Plow Technologies, USA   * Heinrich Apfelmus, Germany   * Jurriaan Hage, Utrecht University, The Netherlands   * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany   * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair)   * Andres Löh, Well-Typed LLP, Germany   * Keiko Nakata, SAP SE, Germany   * Henrik Nilsson, University of Nottingham, UK   * Ertuğrul Söylemez, Intelego GmbH, Germany   * Henning Thielemann, Germany   * Niki Vazou, University of Maryland, USA   * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it at jeltsch.info. From guthrie at mum.edu Thu Oct 5 00:10:28 2017 From: guthrie at mum.edu (Gregory Guthrie) Date: Wed, 4 Oct 2017 19:10:28 -0500 Subject: [Haskell-cafe] Functional Languages Beat Procedural/Object-Oriented Message-ID: <08EF9DA445C4B5439C4733E1F35705BA066E74BD6428@MAIL.cs.mum.edu> Functional Languages Beat Procedural/Object-Oriented Application Development Trends David Ramel October 3, 2017 Researchers at the University of Virginia and the University of California, Davis say they have completed a study evaluating the impact of programming languages on software quality, and found functional languages are superior to procedural/object-oriented languages in some respects. The team analyzed more than 700 GitHub projects containing about 63 million lines of source code. The researchers note empirically assessing software quality is complex, shaped by numerous interacting variables. "By triangulating findings from different methods, and controlling for confounding effects such as team size, project size, and project history, we report that language design does have a significant, but modest effect on software quality," the team says. Among their findings is that disallowing type confusion seems to offer an improvement over permitting it, while static typing is somewhat better than dynamic in functional languages. The team also found functional languages are associated with fewer defects than procedural/scripting languages, and that managed memory usage is better than unmanaged. The research was published in the October edition of Communications of the ACM. https://orange.hosting.lsoft.com/trk/click?ref=znwrbbrs9_6-17370x31326fx040969& --------------------------------------------------------------- From jo at durchholz.org Thu Oct 5 04:40:29 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 5 Oct 2017 06:40:29 +0200 Subject: [Haskell-cafe] Functional Languages Beat Procedural/Object-Oriented In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA066E74BD6428@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA066E74BD6428@MAIL.cs.mum.edu> Message-ID: <403a9523-219d-e9ec-3a44-3addb9c15d2e@durchholz.org> Are the researchers aware of the replication crisis(1), and did they apply the lessons learned from that? The abstract just mentions the confirming anti-bias indicators, but not the absence of negative ones that have become the hallmark of non-replicable research, so I am somewhat sceptical. Regards, Jo 1) https://en.wikipedia.org/wiki/Replication_crisis From simonpj at microsoft.com Thu Oct 5 09:58:00 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 5 Oct 2017 09:58:00 +0000 Subject: [Haskell-cafe] Determine instance method from class method callsite In-Reply-To: References: Message-ID: Did you get a reply? I’m not 100% certain of your question, but consider the bar = show for some expression e. In the input to the type type checker the syntax tree for the RHS will be something like HsApp (HsVar “show”) (The “show” isn’t really a string, it’s the Name for the class method.) After typechecking the syntax tree is augmented (or “elaborated”) with type and dictionary application. So in concrete form it might look like bar = show @Foo dShowFoo Because show :: forall a. Show a => a -> String, so show is apply to the type of its argument, and then to the dictionary. In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper. The elaborated syntax tree look like HsApp (HsWrap (HsVar “show”)) The part expresses the type and dictionary application. In this case it’ll look like WpEvApp dShowFoo (WpTyApp Foo WpHole) See the notes with `HsWrapper` in TcEvidence. Does that help? It would be great to augment the https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it already). If you augment I can review. Email is quickly lost. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Robin Palotai Sent: 19 September 2017 06:39 To: GHC developers ; haskell Subject: Determine instance method from class method callsite Sorry, I messed up subject and mailing list. Copying to both list now after the mistake (wanted only ghc-devs for specificity). Thanks! 2017-09-19 7:36 GMT+02:00 Robin Palotai >: Hello GHC devs, Before inventing the wheel, want to check if there is a GHC API way to look up the (fully) resolved instance method from a class method. For example, given a code data Foo Int deriving Show bar = show (Foo 3) when inspecting the Typechecked AST for bar's show call, I would like to get to the Name / Id of 'show' of the 'Show' typeclass. I believe I could use splitHsSigmaTy on the HsType of the function call to get the context, and then evaluate the HsWrapper somehow to find out what instance dictionary is applied to the class restriction in the context, and then look up the instance method from the dictionary.. Two questions: 1) Is there maybe functionality for this? 2) If not, is there any guarantee about the constraint order in the context, at the method call? So I could more easily determine which constraint's application to look for.. Any hints welcome && Thank you! Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Thu Oct 5 10:16:58 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 5 Oct 2017 12:16:58 +0200 Subject: [Haskell-cafe] Determine instance method from class method callsite In-Reply-To: References: Message-ID: Hello Simon - I outlined the approach in https://github.com/google/haskell-indexer/issues/73. TLDR is 1) at callsite, indeed the HsWrapper needs to be analysed to get the instance DFunId 2) at instance declaration site, we need to again take note of the DFunId. It is slightly more complicated than I expected the API. I would have expected that from having the Var of a class method, and the of the instance (here DFunId), it would be easy to resolve the Var of the instance method. But it seems there's no direct way, one has to build a lookup table from the instance methods' (DFunId + plain stringy method name), and look that up from the callsite. Or I might have missed a way to deconstruct / query a DFunId for the method Vars. I'll put augmenting the commentary on my mental TODO list :) 2017-10-05 11:58 GMT+02:00 Simon Peyton Jones : > Did you get a reply? > > > > I’m not 100% certain of your question, but consider the > > > > bar = show > > for some expression e. In the input to the type type checker the syntax > tree for the RHS will be something like > > HsApp (HsVar “show”) > > > > (The “show” isn’t really a string, it’s the Name for the class method.) > > > > After typechecking the syntax tree is augmented (or “elaborated”) with > type and dictionary application. So in concrete form it might look like > > bar = show @Foo dShowFoo > > > > Because show :: forall a. Show a => a -> String, so show is apply to the > type of its argument, and then to the dictionary. > > > > In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper. The > elaborated syntax tree look like > > > > HsApp (HsWrap (HsVar “show”)) > > > > > > The part expresses the type and dictionary application. In this > case it’ll look like > > WpEvApp dShowFoo (WpTyApp Foo WpHole) > > > > See the notes with `HsWrapper` in TcEvidence. > > > > Does that help? > > > > It would be great to augment the https://ghc.haskell.org/trac/ > ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it > already). If you augment I can review. Email is quickly lost. > > > > Simon > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Robin > Palotai > *Sent:* 19 September 2017 06:39 > *To:* GHC developers ; haskell < > haskell-cafe at haskell.org> > *Subject:* Determine instance method from class method callsite > > > > Sorry, I messed up subject and mailing list. Copying to both list now > after the mistake (wanted only ghc-devs for specificity). > > > > Thanks! > > > > 2017-09-19 7:36 GMT+02:00 Robin Palotai : > > Hello GHC devs, > > > > Before inventing the wheel, want to check if there is a GHC API way to > look up the (fully) resolved instance method from a class method. > > > > For example, given a code > > > > data Foo Int deriving Show > > > > bar = show (Foo 3) > > > > when inspecting the Typechecked AST for bar's show call, I would like to > get to the Name / Id of 'show' of the 'Show' typeclass. > > > > I believe I could use splitHsSigmaTy on the HsType of the function call to > get the context, and then evaluate the HsWrapper somehow to find out what > instance dictionary is applied to the class restriction in the context, and > then look up the instance method from the dictionary.. > > > > Two questions: > > > > 1) Is there maybe functionality for this? > > > > 2) If not, is there any guarantee about the constraint order in the > context, at the method call? So I could more easily determine which > constraint's application to look for.. > > > > Any hints welcome && Thank you! > > Robin > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cs.uchicago.edu Thu Oct 5 15:29:24 2017 From: stuart at cs.uchicago.edu (Stuart A. Kurtz) Date: Thu, 5 Oct 2017 10:29:24 -0500 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) Message-ID: Dear Cafe, I've had my first extended visit into cabal hell... ghc: 8.2.1 (Haskell Platform) cabal: 2.0.0.2 cabal-install: 2.0.0.0 OS: MacOS X 10.13 (High Sierra) I have problems around trying to install some standard packages: hlint, aeson. A typical error reported by cabal is : cannot satisfy -package-id hashable-1.2.6.1-14fEJP30YhAG9w115PODz0: hashable-1.2.6.1-14fEJP30YhAG9w115PODz0 is unusable due to shadowed dependencies: text-1.2.2.2-EGUst8sqNAZCw1xLPcmcMH FWIW, the versions of these packages reported by ghc-pkg are hashable-1.2.6.1 text-1.2.2.2 Suggestions welcome... Peace, Stu From cma at bitemyapp.com Thu Oct 5 15:36:53 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 5 Oct 2017 10:36:53 -0500 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: New version of Haskell Platform, like past ones, has proven troublesome for users. I'd suggest using Stack (http://haskellstack.org) with the current LTS which uses GHC 8.0.2, which is has been stable my work. I'm happy to help if you have any questions. — Chris On Thu, Oct 5, 2017 at 10:29 AM, Stuart A. Kurtz wrote: > Dear Cafe, > > I've had my first extended visit into cabal hell... > > ghc: 8.2.1 (Haskell Platform) > cabal: 2.0.0.2 > cabal-install: 2.0.0.0 > OS: MacOS X 10.13 (High Sierra) > > I have problems around trying to install some standard packages: hlint, aeson. A typical error reported by cabal is > > : cannot satisfy -package-id hashable-1.2.6.1-14fEJP30YhAG9w115PODz0: > hashable-1.2.6.1-14fEJP30YhAG9w115PODz0 is unusable due to shadowed dependencies: > text-1.2.2.2-EGUst8sqNAZCw1xLPcmcMH > > FWIW, the versions of these packages reported by ghc-pkg are > > hashable-1.2.6.1 > text-1.2.2.2 > > Suggestions welcome... > > Peace, > > Stu > > _______________________________________________ > 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. -- Chris Allen Currently working on http://haskellbook.com From jonathan at scrive.com Thu Oct 5 15:47:57 2017 From: jonathan at scrive.com (Jonathan Jouty) Date: Thu, 5 Oct 2017 17:47:57 +0200 Subject: [Haskell-cafe] Job opportunity at Scrive Message-ID: Hey! We have a "full stack" Haskell position that just opened up: https://stackoverflow.com/jobs/156727/haskell-full-stack-developer-scrive Please apply directly on Stack Overflow. I'll be at Haskell eXchange in London next week if you want to meet, otherwise send an email. Cheers. -- Jonathan Jouty *Lead Developer* at *Scrive* www.scrive.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.glushenkov at gmail.com Thu Oct 5 15:47:47 2017 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Thu, 5 Oct 2017 16:47:47 +0100 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: Hi, On 5 October 2017 at 16:29, Stuart A. Kurtz wrote: > I have problems around trying to install some standard packages: hlint, aeson. A typical error reported by cabal is > > : cannot satisfy -package-id hashable-1.2.6.1-14fEJP30YhAG9w115PODz0: > hashable-1.2.6.1-14fEJP30YhAG9w115PODz0 is unusable due to shadowed dependencies: > text-1.2.2.2-EGUst8sqNAZCw1xLPcmcMH This looks like a known Cabal 2.0 bug, which I haven't yet got around to fix: https://github.com/haskell/cabal/issues/4728 IIUC, this affects both Stack and Cabal, but only when used with GHC 8.2.1. Downgrading to GHC 8.0.2 should help for now. From simonpj at microsoft.com Thu Oct 5 16:00:08 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 5 Oct 2017 16:00:08 +0000 Subject: [Haskell-cafe] Determine instance method from class method callsite In-Reply-To: References: Message-ID: well the HsWrapper might have something much more complicated than a DFunId. It might need to construct the dictionary for Eq [a] from the DFun for Eq [a] and a dictionary for Eq a. it would be easy to resolve the Var of the instance method. I don't know what "the var of the instance method" is. I feel I'm missing the point. maybe others can help? Simon From: Robin Palotai [mailto:palotai.robin at gmail.com] Sent: 05 October 2017 11:17 To: Simon Peyton Jones Cc: GHC developers ; haskell Subject: Re: Determine instance method from class method callsite Hello Simon - I outlined the approach in https://github.com/google/haskell-indexer/issues/73. TLDR is 1) at callsite, indeed the HsWrapper needs to be analysed to get the instance DFunId 2) at instance declaration site, we need to again take note of the DFunId. It is slightly more complicated than I expected the API. I would have expected that from having the Var of a class method, and the of the instance (here DFunId), it would be easy to resolve the Var of the instance method. But it seems there's no direct way, one has to build a lookup table from the instance methods' (DFunId + plain stringy method name), and look that up from the callsite. Or I might have missed a way to deconstruct / query a DFunId for the method Vars. I'll put augmenting the commentary on my mental TODO list :) 2017-10-05 11:58 GMT+02:00 Simon Peyton Jones >: Did you get a reply? I'm not 100% certain of your question, but consider the bar = show for some expression e. In the input to the type type checker the syntax tree for the RHS will be something like HsApp (HsVar "show") (The "show" isn't really a string, it's the Name for the class method.) After typechecking the syntax tree is augmented (or "elaborated") with type and dictionary application. So in concrete form it might look like bar = show @Foo dShowFoo Because show :: forall a. Show a => a -> String, so show is apply to the type of its argument, and then to the dictionary. In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper. The elaborated syntax tree look like HsApp (HsWrap (HsVar "show")) The part expresses the type and dictionary application. In this case it'll look like WpEvApp dShowFoo (WpTyApp Foo WpHole) See the notes with `HsWrapper` in TcEvidence. Does that help? It would be great to augment the https://ghc.haskell.org/trac/ghc/wiki/Commentary with this sort of info (insofar as it doesn't have it already). If you augment I can review. Email is quickly lost. Simon From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Robin Palotai Sent: 19 September 2017 06:39 To: GHC developers >; haskell > Subject: Determine instance method from class method callsite Sorry, I messed up subject and mailing list. Copying to both list now after the mistake (wanted only ghc-devs for specificity). Thanks! 2017-09-19 7:36 GMT+02:00 Robin Palotai >: Hello GHC devs, Before inventing the wheel, want to check if there is a GHC API way to look up the (fully) resolved instance method from a class method. For example, given a code data Foo Int deriving Show bar = show (Foo 3) when inspecting the Typechecked AST for bar's show call, I would like to get to the Name / Id of 'show' of the 'Show' typeclass. I believe I could use splitHsSigmaTy on the HsType of the function call to get the context, and then evaluate the HsWrapper somehow to find out what instance dictionary is applied to the class restriction in the context, and then look up the instance method from the dictionary.. Two questions: 1) Is there maybe functionality for this? 2) If not, is there any guarantee about the constraint order in the context, at the method call? So I could more easily determine which constraint's application to look for.. Any hints welcome && Thank you! Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cs.uchicago.edu Thu Oct 5 17:52:27 2017 From: stuart at cs.uchicago.edu (Stuart A. Kurtz) Date: Thu, 5 Oct 2017 12:52:27 -0500 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: <53BCD118-4054-40AB-8296-91A3A8B01F43@cs.uchicago.edu> Message-ID: Dear Imants, > Is it possible that some ghc version is installed with /usr prefix, and another with /usr/local > ? > > If yes - try uninstalling the older versions. > You may need to clean up the obsolete library folders. Joy! Which is to say, after several unsuccessful attempts involving progressively more draconian deletion strategies, ending with % uninstall-hs all --remove and reinstalling the Core Platform from the installer, which finally worked. Many thanks! Peace, Stu From mszamot at gmail.com Thu Oct 5 20:10:29 2017 From: mszamot at gmail.com (Marcin Szamotulski) Date: Thu, 5 Oct 2017 22:10:29 +0200 Subject: [Haskell-cafe] Job opportunity at Scrive In-Reply-To: References: Message-ID: Hi Jonathan, I am interested and I will be at Haskell exchange too. Are you interested in using Purescript. It can be integrated with javascript codebases, there are binding for react and you can keep writting free monad dsl's :). You can even share haskell types on both ends of the wire. Recently I gave an introductory talk about it at Monadic Warsaw meetup: https://youtu.be/klpKIs84_bU See you in London, Marcin Szamotulski https://marcinszamotulski.me On 5 Oct 2017 17:49, "Jonathan Jouty" wrote: > Hey! > > We have a "full stack" Haskell position that just opened up: > https://stackoverflow.com/jobs/156727/haskell-full-stack-developer-scrive > > Please apply directly on Stack Overflow. > I'll be at Haskell eXchange in London next week if you want to meet, > otherwise send an email. > > Cheers. > -- > Jonathan Jouty > *Lead Developer* at *Scrive* > www.scrive.com > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Oct 5 23:02:25 2017 From: ben at well-typed.com (Ben Gamari) Date: Thu, 05 Oct 2017 19:02:25 -0400 Subject: [Haskell-cafe] Deprecating STM invariant mechanism Message-ID: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org> tl;dr. Do you use Control.Monad.STM.always? If so say so on this [1] proposal otherwise the interface may be removed. Hello everyone, GHC's STM subsystem has long had the ability to run user-specified invariant checks when committing transactions, embodied by the Control.Monad.STM.always and alwaysSucceeds functions. However, if Hackage is any indication this feature has seen very little use of the past ten years. In fact, it has very likely been quite broken (#14310) for this entire duration. Consequently, I suggest that we begin deprecating the mechanism. See the deprecation Proposal [1] for full details. Please leave a comment if you object. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mihai.maruseac at gmail.com Fri Oct 6 02:17:10 2017 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Thu, 5 Oct 2017 19:17:10 -0700 Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, November 2017 edition (33rd edition) Message-ID: Dear all, We would like to collect contributions for the 33rd edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 5 November 2017 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac FAQ: Q: What format should I write in? A: The usual format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2017/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2017/hcar.sty that you can use to preview your entry. If you do not know LaTeX or don't want to use it or don't have time to translate your entry into it, then please use plain text, it is better to have an entry in plain-text which we will translate than not have it at all. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then. PNG is preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachments are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From trebla at vex.net Fri Oct 6 02:48:57 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 5 Oct 2017 22:48:57 -0400 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: On 2017-10-05 11:47 AM, Mikhail Glushenkov wrote: > Hi, > > On 5 October 2017 at 16:29, Stuart A. Kurtz wrote: >> I have problems around trying to install some standard packages: hlint, aeson. A typical error reported by cabal is >> >> : cannot satisfy -package-id hashable-1.2.6.1-14fEJP30YhAG9w115PODz0: >> hashable-1.2.6.1-14fEJP30YhAG9w115PODz0 is unusable due to shadowed dependencies: >> text-1.2.2.2-EGUst8sqNAZCw1xLPcmcMH > > This looks like a known Cabal 2.0 bug, which I haven't yet got around to fix: > > https://github.com/haskell/cabal/issues/4728 > > IIUC, this affects both Stack and Cabal, but only when used with GHC > 8.2.1. Downgrading to GHC 8.0.2 should help for now. I have found the cause (first-order cause anyway) and wrote it up on the cabal issue and the haskell-platform issue, and explained why the stack issue is unrelated, all on github. Please refer to those issues separately for details. Oh too bad the Haskell Platform people closed theirs, because it is totally a Haskell Platform build error for some builds. In short, while I don't have Mac and so I need you to do the following checks, I have Linux and checked it. Best to start with a fresh install, full binary version, for minimum doubt: 1. "ghc -v" to see you already have shadowing messages right from the start with a clean slate. 2. "ghc-pkg field hashable abi-depends" for example and look at the oddity "text-...=inplace" in contrast to more common ones like "base-...=hexstring". This is why GHC says it can't find the right text for hashable. (See also "ghc-pkg field base abi" and "ghc-pkg field text abi", these are what GHC checks against.) The Windows version doesn't have this problem because the abi-depends fields don't even exist there. This is probably because the Windows versions was built by Cabal 1.x. The core versions don't have this problem. From allbery.b at gmail.com Fri Oct 6 03:13:12 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 5 Oct 2017 23:13:12 -0400 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: On Thu, Oct 5, 2017 at 10:48 PM, Albert Y. C. Lai wrote: > 2. "ghc-pkg field hashable abi-depends" for example and look at the oddity > "text-...=inplace" in contrast to more common ones like > "base-...=hexstring". This is why GHC says it can't find the right text for > hashable. (See also "ghc-pkg field base abi" and "ghc-pkg field text abi", > these are what GHC checks against.) > There are already a couple of nasty bugs that were found in Cabal 2.0; this one might even be known already. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri Oct 6 03:27:50 2017 From: gershomb at gmail.com (Gershom B) Date: Thu, 5 Oct 2017 23:27:50 -0400 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: Thanks for the heads-up Albert, and for the good detective work. I’m digging into this now… -g On October 5, 2017 at 10:51:20 PM, Albert Y. C. Lai (trebla at vex.net) wrote: > On 2017-10-05 11:47 AM, Mikhail Glushenkov wrote: > > Hi, > > > > On 5 October 2017 at 16:29, Stuart A. Kurtz wrote: > >> I have problems around trying to install some standard packages: hlint, aeson. A typical > error reported by cabal is > >> > >> : cannot satisfy -package-id hashable-1.2.6.1-14fEJP30YhAG9w115PODz0: > >> hashable-1.2.6.1-14fEJP30YhAG9w115PODz0 is unusable due to shadowed dependencies: > >> text-1.2.2.2-EGUst8sqNAZCw1xLPcmcMH > > > > This looks like a known Cabal 2.0 bug, which I haven't yet got around to fix: > > > > https://github.com/haskell/cabal/issues/4728 > > > > IIUC, this affects both Stack and Cabal, but only when used with GHC > > 8.2.1. Downgrading to GHC 8.0.2 should help for now. > > I have found the cause (first-order cause anyway) and wrote it up on the > cabal issue and the haskell-platform issue, and explained why the stack > issue is unrelated, all on github. Please refer to those issues > separately for details. Oh too bad the Haskell Platform people closed > theirs, because it is totally a Haskell Platform build error for some > builds. > > In short, while I don't have Mac and so I need you to do the following > checks, I have Linux and checked it. Best to start with a fresh install, > full binary version, for minimum doubt: > > 1. "ghc -v" to see you already have shadowing messages right from the > start with a clean slate. > > 2. "ghc-pkg field hashable abi-depends" for example and look at the > oddity "text-...=inplace" in contrast to more common ones like > "base-...=hexstring". This is why GHC says it can't find the right text > for hashable. (See also "ghc-pkg field base abi" and "ghc-pkg field text > abi", these are what GHC checks against.) > > The Windows version doesn't have this problem because the abi-depends > fields don't even exist there. This is probably because the Windows > versions was built by Cabal 1.x. > > The core versions don't have this problem. > _______________________________________________ > 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. From allbery.b at gmail.com Fri Oct 6 03:37:59 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 5 Oct 2017 23:37:59 -0400 Subject: [Haskell-cafe] Cabal hell (8.2.1,/Haskell Package/MacOS X) In-Reply-To: References: Message-ID: On Thu, Oct 5, 2017 at 11:13 PM, Brandon Allbery wrote: > On Thu, Oct 5, 2017 at 10:48 PM, Albert Y. C. Lai wrote: > >> 2. "ghc-pkg field hashable abi-depends" for example and look at the >> oddity "text-...=inplace" in contrast to more common ones like >> "base-...=hexstring". This is why GHC says it can't find the right text for >> hashable. (See also "ghc-pkg field base abi" and "ghc-pkg field text abi", >> these are what GHC checks against.) >> > > There are already a couple of nasty bugs that were found in Cabal 2.0; > this one might even be known already. > To be more clear: at least one case known of mis-registering a package. This could be a case where, on later registering an inplace build (the stuff in dist/), it's accidentally using the information from dist instead of the correct information. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Oct 6 03:48:18 2017 From: david.feuer at gmail.com (David Feuer) Date: Thu, 5 Oct 2017 23:48:18 -0400 Subject: [Haskell-cafe] claiming maintainer position of a HackageDB package In-Reply-To: References: Message-ID: The appropriate procedures are described at https://wiki.haskell.org/Taking_over_a_package On Wed, Oct 4, 2017 at 10:22 AM, Guillaume Hoffmann wrote: > Hi, > > I would like to submit a new version of the following package: > > https://hackage.haskell.org/package/mime-string > > Unfortunately, I only received private consent from the current > maintainer that I would become the maintainer of this package, more > than one month ago. Since then I had not received any answer to my > request and I cannot upload a new version to HackageDB. > > Is there a procedure I could summon to become the maintainer of this > package on HackageDB? > > Thanks > > Guillaume > > PS: for the anecdote, darcsden needs this new version of mime-string. > _______________________________________________ > 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. From palotai.robin at gmail.com Fri Oct 6 05:20:05 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Fri, 6 Oct 2017 07:20:05 +0200 Subject: [Haskell-cafe] Determine instance method from class method callsite In-Reply-To: References: Message-ID: About "Var" - that is just a Name with additional info, but happens in the typechecked tree (according to API docs). 2017-10-05 18:00 GMT+02:00 Simon Peyton Jones : > well the HsWrapper might have something much more complicated than a > DFunId. It might need to construct the dictionary for Eq [a] from the DFun > for Eq [a] and a dictionary for Eq a. > > > > it would be easy to resolve the Var of the instance method. > > I don’t know what “the var of the instance method” is. > > > > I feel I’m missing the point. maybe others can help? > > > > Simon > > > > *From:* Robin Palotai [mailto:palotai.robin at gmail.com] > *Sent:* 05 October 2017 11:17 > *To:* Simon Peyton Jones > *Cc:* GHC developers ; haskell < > haskell-cafe at haskell.org> > *Subject:* Re: Determine instance method from class method callsite > > > > Hello Simon - I outlined the approach in https://github.com/google/ > haskell-indexer/issues/73 > > . > TLDR is > 1) at callsite, indeed the HsWrapper needs to be analysed to get the > instance DFunId > > 2) at instance declaration site, we need to again take note of the DFunId. > > It is slightly more complicated than I expected the API. I would have > expected that from having the Var of a class method, and the of > the instance (here DFunId), it would be easy to resolve the Var of the > instance method. > > But it seems there's no direct way, one has to build a lookup table from > the instance methods' (DFunId + plain stringy method name), and look that > up from the callsite. > > Or I might have missed a way to deconstruct / query a DFunId for the > method Vars. > > I'll put augmenting the commentary on my mental TODO list :) > > > > 2017-10-05 11:58 GMT+02:00 Simon Peyton Jones : > > Did you get a reply? > > > > I’m not 100% certain of your question, but consider the > > > > bar = show > > for some expression e. In the input to the type type checker the syntax > tree for the RHS will be something like > > HsApp (HsVar “show”) > > > > (The “show” isn’t really a string, it’s the Name for the class method.) > > > > After typechecking the syntax tree is augmented (or “elaborated”) with > type and dictionary application. So in concrete form it might look like > > bar = show @Foo dShowFoo > > > > Because show :: forall a. Show a => a -> String, so show is apply to the > type of its argument, and then to the dictionary. > > > > In HsSyn this part is done with a HsWrapper See TcEvidence.HsWrapper. The > elaborated syntax tree look like > > > > HsApp (HsWrap (HsVar “show”)) > > > > > > The part expresses the type and dictionary application. In this > case it’ll look like > > WpEvApp dShowFoo (WpTyApp Foo WpHole) > > > > See the notes with `HsWrapper` in TcEvidence. > > > > Does that help? > > > > It would be great to augment the https://ghc.haskell.org/trac/ > ghc/wiki/Commentary with this sort of info (insofar as it doesn’t have it > already). If you augment I can review. Email is quickly lost. > > > > Simon > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Robin > Palotai > *Sent:* 19 September 2017 06:39 > *To:* GHC developers ; haskell < > haskell-cafe at haskell.org> > *Subject:* Determine instance method from class method callsite > > > > Sorry, I messed up subject and mailing list. Copying to both list now > after the mistake (wanted only ghc-devs for specificity). > > > > Thanks! > > > > 2017-09-19 7:36 GMT+02:00 Robin Palotai : > > Hello GHC devs, > > > > Before inventing the wheel, want to check if there is a GHC API way to > look up the (fully) resolved instance method from a class method. > > > > For example, given a code > > > > data Foo Int deriving Show > > > > bar = show (Foo 3) > > > > when inspecting the Typechecked AST for bar's show call, I would like to > get to the Name / Id of 'show' of the 'Show' typeclass. > > > > I believe I could use splitHsSigmaTy on the HsType of the function call to > get the context, and then evaluate the HsWrapper somehow to find out what > instance dictionary is applied to the class restriction in the context, and > then look up the instance method from the dictionary.. > > > > Two questions: > > > > 1) Is there maybe functionality for this? > > > > 2) If not, is there any guarantee about the constraint order in the > context, at the method call? So I could more easily determine which > constraint's application to look for.. > > > > Any hints welcome && Thank you! > > Robin > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at maximka.de Fri Oct 6 05:58:15 2017 From: info at maximka.de (info at maximka.de) Date: Fri, 6 Oct 2017 07:58:15 +0200 (CEST) Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, November 2017 edition (33rd edition) In-Reply-To: References: Message-ID: <1550567449.564033.1507269495233@communicator.strato.de> Hi Mihai, the WIKI-link in "4.13.3 Haskino" should be replaced by https://github.com/ku-fpg/haskino/wiki Regards, Alexei > On 06 October 2017 at 04:17 Mihai Maruseac wrote: > > > Dear all, > > We would like to collect contributions for the 33rd edition of the > > ============================================================ > Haskell Communities & Activities Report > > http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report > > Submission deadline: 5 November 2017 > > (please send your contributions to hcar at haskell.org, > in plain text or LaTeX format, both are equally accepted) > ============================================================ > > This is the short story: > > * If you are working on any project that is in some way related to > Haskell, please write a short entry and submit it. Even if the project > is very small or unfinished or you think it is not important enough > --- please reconsider and submit an entry anyway! > > * If you are interested in an existing project related to Haskell that > has not previously been mentioned in the HCAR, please tell us, so that > we can contact the project leaders and ask them to submit an entry. > > * If you are working on a project that is looking for contributors, > please write a short entry and submit it, mentioning that your are > looking for contributors. > > * Feel free to pass on this call for contributions to others that > might be interested. > > More detailed information: > > The Haskell Communities & Activities Report is a bi-annual overview of > the state of Haskell as well as Haskell-related projects over the > last, and possibly the upcoming six months. If you have only recently > been exposed to Haskell, it might be a good idea to browse the > previous edition --- you will find interesting projects described as > well as several starting points and links that may provide answers to > many questions. > > Contributions will be collected until the submission deadline. They > will then be compiled into a coherent report that is published online > as soon as it is ready. As always, this is a great opportunity to > update your webpages, make new releases, announce or even start new > projects, or to talk about developments you want every Haskeller to > know about! > > Looking forward to your contributions, > > Mihai Maruseac > > > FAQ: > > Q: What format should I write in? > > A: The usual format is a LaTeX source file, adhering to the template > that is available at: > > http://haskell.org/communities/11-2017/template.tex > > There is also a LaTeX style file at > > http://haskell.org/communities/11-2017/hcar.sty > > that you can use to preview your entry. > > If you do not know LaTeX or don't want to use it or don't have time to > translate your entry into it, then please use plain text, it is better > to have an entry in plain-text which we will translate than not have > it at all. > > If you modify an old entry that you have written for an earlier > edition of the report, you should soon receive your old entry as a > template (provided we have your valid email address). Please modify > that template, rather than using your own version of the old entry as > a template. > > Q: Can I include Haskell code? > > A: Yes. Please use lhs2tex syntax > (http://www.andres-loeh.de/lhs2tex/). The report is compiled in mode > polycode.fmt. > > Q: Can I include images? > > A: Yes, you are even encouraged to do so. Please use .jpg or .png > format, then. PNG is preferred for simplicity. > > Q: Should I send files in .zip archives or similar? > > A: No, plain file attachments are the way. > > Q: How much should I write? > > A: Authors are asked to limit entries to about one column of text. A > general introduction is helpful. Apart from that, you should focus on > recent or upcoming developments. Pointers to online content can be > given for more comprehensive or "historic" overviews of a project. > Images do not count towards the length limit, so you may want to use > this opportunity to pep up entries. There is no minimum length of an > entry! The report aims for being as complete as possible, so please > consider writing an entry, even if it is only a few lines long. > > Q: Which topics are relevant? > > A: All topics which are related to Haskell in some way are relevant. > We usually had reports from users of Haskell (private, academic, or > commercial), from authors or contributors to projects related to > Haskell, from people working on the Haskell language, libraries, on > language extensions or variants. We also like reports about > distributions of Haskell software, Haskell infrastructure, books and > tutorials on Haskell. Reports on past and upcoming events related to > Haskell are also relevant. Finally, there might be new topics we do > not even think about. As a rule of thumb: if in doubt, then it > probably is relevant and has a place in the HCAR. You can also simply > ask us. > > Q: Is unfinished work relevant? Are ideas for projects relevant? > > A: Yes! You can use the HCAR to talk about projects you are currently > working on. You can use it to look for other developers that might > help you. You can use HCAR to ask for more contributors to your > project, it is a good way to gain visibility and traction. > > Q: If I do not update my entry, but want to keep it in the report, > what should I do? > > A: Tell us that there are no changes. The old entry will typically be > reused in this case, but it might be dropped if it is older than a > year, to give more room and more attention to projects that change a > lot. Do not resend complete entries if you have not changed them. > > Q: Will I get confirmation if I send an entry? How do I know whether > my email has even reached its destination, and not ended up in a spam > folder? > > A: Prior to publication of the final report, we will send a draft to > all contributors, for possible corrections. So if you do not hear from > us within two weeks after the deadline, it is safer to send another > mail and check whether your first one was received. > > -- > Mihai Maruseac (MM) > "If you can't solve a problem, then there's an easier problem you can > solve: find it." -- George Polya > _______________________________________________ > 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. From info at maximka.de Fri Oct 6 06:10:58 2017 From: info at maximka.de (info at maximka.de) Date: Fri, 6 Oct 2017 08:10:58 +0200 (CEST) Subject: [Haskell-cafe] claiming maintainership of bsd-sysctl package In-Reply-To: <590576603.4944.1485896678131@communicator.strato.de> References: <590576603.4944.1485896678131@communicator.strato.de> Message-ID: <1531299402.564520.1507270258733@communicator.strato.de> I'm still interested to take over the package. Regards, Alexei > ---------- Original Message ---------- > From: Alexei Pastuchov > To: admin at hackage.haskell.org > Cc: mhenrion at gmail.com, info at maximka.de > Date: 31 January 2017 at 22:04 > Subject: bsd-sysctl 1.0.7 > > Hi, > the installation of bsd-sysctl v1.0.7 ends in exception: > Not in scope: `catch' > > I created a pull request for the bug at the end of 2015 and short time later the author/maintainer asked me if I'm interested in taking over the maintainership. > > As described in https://wiki.haskell.org/Taking_over_a_package I asked him to add my hackage account 'palik' to the maintainer group in my last message a couple of months ago and I'm going to ask you for the maintainer permissions. > > Here the aforementioned pull request https://bitbucket.org/mux/bsd-sysctl/pull-requests/ > > Best regards, > Alexei From gershomb at gmail.com Fri Oct 6 06:14:24 2017 From: gershomb at gmail.com (Gershom B) Date: Fri, 6 Oct 2017 02:14:24 -0400 Subject: [Haskell-cafe] ANN: New Full Platform Build of Haskell Platform 8.2.1 for Mac Message-ID: Thanks to some intrepid sleuthing by Albert Y. C. Lai, we realized there was a serious problem in the full (not core) builds of HP for Mac and Linux (not Windows). If you've seen lots of "unusable due to shadowed dependencies" errors on packages that came with full 8.2.1 platform installs on those systems, this is likely why. We should have tested better and caught this, and I'm sorry for the trouble it has caused. I've released a new build of the full mac installer, and updated the hash on the site. A new generic-linux build should follow soon. Regards, Gershom P.s. For those interested, the technical details are at https://github.com/haskell/haskell-platform/issues/285 -- in brief, the platform had done builds using inplace conf files but deployed using proper target package-conf files. This worked just fine until the new abi-depends machinery was introduced for better computing dependency mismatches (https://phabricator.haskell.org/D2846 is one place to start reading about that). That new machinery then recognized that different abis were generated for the inplace conf than the target conf, and things went screwy. But the problem here isn't with those changes -- it's with our inadequate testing that should have caught when things went wrong and alerted us that we needed to step back and fix things earlier, and the responsibility for that is all on me. From gershomb at gmail.com Fri Oct 6 06:16:31 2017 From: gershomb at gmail.com (Gershom B) Date: Fri, 6 Oct 2017 02:16:31 -0400 Subject: [Haskell-cafe] claiming maintainership of bsd-sysctl package In-Reply-To: <1531299402.564520.1507270258733@communicator.strato.de> References: <590576603.4944.1485896678131@communicator.strato.de> <1531299402.564520.1507270258733@communicator.strato.de> Message-ID: The user palik appears to have already been added to the maintainers group for that package on Feb 19. Cheers, Gershom On Fri, Oct 6, 2017 at 2:10 AM, wrote: > I'm still interested to take over the package. > Regards, > Alexei >> ---------- Original Message ---------- >> From: Alexei Pastuchov >> To: admin at hackage.haskell.org >> Cc: mhenrion at gmail.com, info at maximka.de >> Date: 31 January 2017 at 22:04 >> Subject: bsd-sysctl 1.0.7 >> >> Hi, >> the installation of bsd-sysctl v1.0.7 ends in exception: >> Not in scope: `catch' >> >> I created a pull request for the bug at the end of 2015 and short time later the author/maintainer asked me if I'm interested in taking over the maintainership. >> >> As described in https://wiki.haskell.org/Taking_over_a_package I asked him to add my hackage account 'palik' to the maintainer group in my last message a couple of months ago and I'm going to ask you for the maintainer permissions. >> >> Here the aforementioned pull request https://bitbucket.org/mux/bsd-sysctl/pull-requests/ >> >> Best regards, >> Alexei From info at maximka.de Fri Oct 6 06:29:09 2017 From: info at maximka.de (info at maximka.de) Date: Fri, 6 Oct 2017 08:29:09 +0200 (CEST) Subject: [Haskell-cafe] claiming maintainership of bsd-sysctl package In-Reply-To: References: <590576603.4944.1485896678131@communicator.strato.de> <1531299402.564520.1507270258733@communicator.strato.de> Message-ID: <1456899518.565281.1507271349458@communicator.strato.de> Thank you, Gershom. Indeed I'm able to maintain the package now. Regards, Alexei > On 06 October 2017 at 08:16 Gershom B wrote: > > > The user palik appears to have already been added to the maintainers > group for that package on Feb 19. > > Cheers, > Gershom > > On Fri, Oct 6, 2017 at 2:10 AM, wrote: > > I'm still interested to take over the package. > > Regards, > > Alexei > >> ---------- Original Message ---------- > >> From: Alexei Pastuchov > >> To: admin at hackage.haskell.org > >> Cc: mhenrion at gmail.com, info at maximka.de > >> Date: 31 January 2017 at 22:04 > >> Subject: bsd-sysctl 1.0.7 > >> > >> Hi, > >> the installation of bsd-sysctl v1.0.7 ends in exception: > >> Not in scope: `catch' > >> > >> I created a pull request for the bug at the end of 2015 and short time later the author/maintainer asked me if I'm interested in taking over the maintainership. > >> > >> As described in https://wiki.haskell.org/Taking_over_a_package I asked him to add my hackage account 'palik' to the maintainer group in my last message a couple of months ago and I'm going to ask you for the maintainer permissions. > >> > >> Here the aforementioned pull request https://bitbucket.org/mux/bsd-sysctl/pull-requests/ > >> > >> Best regards, > >> Alexei From guillaumh at gmail.com Fri Oct 6 12:28:50 2017 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Fri, 6 Oct 2017 09:28:50 -0300 Subject: [Haskell-cafe] claiming maintainer position of a HackageDB package In-Reply-To: References: Message-ID: Thanks! From i.sergey at ucl.ac.uk Fri Oct 6 17:49:53 2017 From: i.sergey at ucl.ac.uk (Sergey, Ilya) Date: Fri, 6 Oct 2017 17:49:53 +0000 Subject: [Haskell-cafe] CoqPL 2018: Call for Presentations Message-ID: <321FC33D-DA55-4E28-B203-57ABF7FC0A82@ucl.ac.uk> ==================================================================== CoqPL 2018 Coq for Programming Languages -- A Coq users and developers meeting 13 January 2018, co-located with POPL (as usual) Los Angeles, California, United States CALL FOR PRESENTATIONS https://popl18.sigplan.org/track/CoqPL-2018 ==================================================================== Workshop Overview ----------------- The series of CoqPL workshops provide an opportunity for programming languages researchers to meet and interact with one another and members from the core Coq development team. At the meeting, we will discuss upcoming new features, see talks and demonstrations of exciting current projects, solicit feedback for potential future changes, and generally work to strengthen the vibrant community around our favourite proof assistant. Topics in scope include but are no limited to: * General purpose libraries and tactic language extensions; * Domain-specific libraries for programming language formalization and verification; * IDEs, profilers, tracers, debuggers, and testing tools; * Reports on ongoing proof efforts conducted via (or in the context of) the Coq proof assistant; * Experience reports from Coq usage in educational or industrial contexts. To foster open discussion of cutting edge research which can later be published in full conference proceedings, we will not publish papers from the workshop. Workshop Format --------------- The workshop format will be driven by members of the Coq community. We will solicit abstracts for talks and proposals for demonstrations and flesh out format details based on responses. We expect the final program to include experiment reports, panel discussions, and invited talks. Talks will be selected according to relevance to the workshop, based on the submission of an extended abstract. Submission Details ------------------ * Abstract Submission : Monday, October, 16th, 2017 * Author Notification : Monday, November 6th, 2017 * Workshop : Saturday, January 13th, 2018 Submissions should be extended abstracts of 1-2 pages in portable document format (PDF). Submission is via EasyChair: https://easychair.org/conferences/?conf=coqpl2018 Program Committee ----------------- * Yves Bertot, INRIA (Workshop Co-chair) * Ilya Sergey, University College London (Workshop Co-chair) * Andrew Appel, Princeton University * Benjamin Delaware, Purdue University * Xinyu Feng, University of Science and Technology of China * Hugo Herbelin, INRIA * Chantal Keller, Université Paris-Sud * Ekaterina Komendantskaya, Heriot-Watt University * Beta Ziliani, Universidad Nacional de Córdoba Contact ----------------- For any queries, please contact : coqpl2018 at easychair.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sun Oct 8 15:46:25 2017 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 8 Oct 2017 08:46:25 -0700 Subject: [Haskell-cafe] Let's plan BayHac 2018 In-Reply-To: References: Message-ID: I'm thinking late February this time. How is that looking for everyone? I am also hoping to cut down a touch on the talks and focus a little more on the hacking. Maybe bring back the old koans, or write some new ones. Location has not yet been decided. Obviously it will be somewhere in the San Francisco Bay Area or Silicon Valley. Over the next month or so I will be reviewing the data from the last survey and reaching out to those who expressed interest in organizing the event. Regardless of whether you filled out the survey or not, please feel free to contact me if you are interested in assisting with the planning and organizing of BayHac 2018. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Mon Oct 9 03:33:23 2017 From: ekmett at gmail.com (Edward Kmett) Date: Sun, 8 Oct 2017 23:33:23 -0400 Subject: [Haskell-cafe] Deprecating STM invariant mechanism In-Reply-To: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org> References: <87wp49p5a6.fsf@ben-laptop.smart-cactus.org> Message-ID: I only have two uses of it at present and come to think of it I'm now dubious about if they were doing anything, so I can pretty readily work around its removal! +1 No objection here. -Edward On Thu, Oct 5, 2017 at 7:02 PM, Ben Gamari wrote: > tl;dr. Do you use Control.Monad.STM.always? If so say so on > this [1] proposal otherwise the interface may be removed. > > > Hello everyone, > > GHC's STM subsystem has long had the ability to run user-specified > invariant checks when committing transactions, embodied by the > Control.Monad.STM.always and alwaysSucceeds functions. > > However, if Hackage is any indication this feature has seen very little > use of the past ten years. In fact, it has very likely been quite broken > (#14310) for this entire duration. > > Consequently, I suggest that we begin deprecating the mechanism. See > the deprecation Proposal [1] for full details. Please leave a comment if > you object. > > Cheers, > > - Ben > > > [1] https://github.com/ghc-proposals/ghc-proposals/pull/77 > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Mon Oct 9 07:33:33 2017 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 9 Oct 2017 07:33:33 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: <4316F1A3-501B-46A1-AC55-A5BC024422B6@exmail.nottingham.ac.uk> Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, deadline 31st October 2017. Please share! Best wishes, Graham ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st October 2017 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 31st October 2017. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From k-bx at k-bx.com Mon Oct 9 12:21:21 2017 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Mon, 9 Oct 2017 15:21:21 +0300 Subject: [Haskell-cafe] Kyiv Haskell Learning Group Meetups Message-ID: Hi! We're starting a Haskell Learning Group in Kyiv, Ukraine. First Meetup will be at 17 October (Tuesday) and will continue on weekly basis at the Institute of Mathematics. See full info about the first meetup at https://www.meetup.com/Kyiv-Haskell-Learning-Group/events/243945548/ Info about the course itself (in Ukrainian): https://github.com/KyivHaskell/haskell-study-startup See you there! -------------- next part -------------- An HTML attachment was scrubbed... URL: From masterdezign at yandex.com Mon Oct 9 13:03:28 2017 From: masterdezign at yandex.com (masterdeZign) Date: Mon, 09 Oct 2017 15:03:28 +0200 Subject: [Haskell-cafe] ANN: hmep -- genetic multi expression programming package Message-ID: <830231507554208@web25o.yandex.ru> Dear Haskell community, I am delighted to contribute a new package for the first time. Today, I am happy to announce `hmep` http://hackage.haskell.org/package/hmep/ bringing Multi Expression Programming to Haskell. Multi Expression Programming is a genetic programming variant encoding multiple solutions in the same chromosome. A chromosome is a computer program. Each gene is featuring code reuse. The latest version is of course on GitHub https://github.com/masterdezign/hmep Thank you for your kind attention, Happy Monday, Bogdan Penkovsky From michael.antosha at gmail.com Mon Oct 9 14:23:52 2017 From: michael.antosha at gmail.com (Michael V. Antosha) Date: Mon, 9 Oct 2017 17:23:52 +0300 Subject: [Haskell-cafe] Kyiv Haskell Learning Group Meetups In-Reply-To: References: Message-ID: Hello Kostiantyn, Are there mailing lists available for event announcements and communication regarding Haskell Study Group and/or Kyiv Haskell User Group? (For those who do not use/like Slack, which seems to be declared as the only communication option.) Best regards, Michael. On 10/9/17, Kostiantyn Rybnikov wrote: > > We're starting a Haskell Learning Group in Kyiv, Ukraine... > > See full info about the first meetup at > https://www.meetup.com/Kyiv-Haskell-Learning-Group/events/243945548/ > > Info about the course itself (in Ukrainian): > https://github.com/KyivHaskell/haskell-study-startup From k-bx at k-bx.com Mon Oct 9 14:33:15 2017 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Mon, 9 Oct 2017 17:33:15 +0300 Subject: [Haskell-cafe] Kyiv Haskell Learning Group Meetups In-Reply-To: References: Message-ID: Hi Michael, All meetings are announced through our Meetup.com page, so following Slack is not required to not miss important announcements. You are free to get help with the material in any community (even here) and through any technology, for example, by simply emailing me! You can also start new mailing lists with other group members once you get in contact. Thank you. On Mon, Oct 9, 2017 at 5:23 PM, Michael V. Antosha < michael.antosha at gmail.com> wrote: > Hello Kostiantyn, > > Are there mailing lists available for event announcements and > communication regarding Haskell Study Group and/or Kyiv Haskell User > Group? > > (For those who do not use/like Slack, which seems to be declared as > the only communication option.) > > Best regards, > Michael. > > > On 10/9/17, Kostiantyn Rybnikov wrote: > > > > We're starting a Haskell Learning Group in Kyiv, Ukraine... > > > > See full info about the first meetup at > > https://www.meetup.com/Kyiv-Haskell-Learning-Group/events/243945548/ > > > > Info about the course itself (in Ukrainian): > > https://github.com/KyivHaskell/haskell-study-startup > -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Mon Oct 9 15:43:36 2017 From: conal at conal.net (Conal Elliott) Date: Mon, 9 Oct 2017 08:43:36 -0700 Subject: [Haskell-cafe] [bayhac] Let's plan BayHac 2018 In-Reply-To: References: Message-ID: Thanks for starting the conversation, Dan. ICFP submission deadline is March 16, so perhaps not too close to that date. Regards, - Conal On Sun, Oct 8, 2017 at 8:46 AM, Dan Burton wrote: > I'm thinking late February this time. How is that looking for everyone? I > am also hoping to cut down a touch on the talks and focus a little more on > the hacking. Maybe bring back the old koans, or write some new ones. > > Location has not yet been decided. Obviously it will be somewhere in the > San Francisco Bay Area or Silicon Valley. > > Over the next month or so I will be reviewing the data from the last > survey and reaching out to those who expressed interest in organizing the > event. > > Regardless of whether you filled out the survey or not, please feel free > to contact me if you are interested in assisting with the planning and > organizing of BayHac 2018. > > -- > BayHac '13 info: http://www.haskell.org/haskellwiki/BayHac2013 > --- > You received this message because you are subscribed to the Google Groups > "Bay Area Haskell Hackathon" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bayhac+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul-mirone at qq.com Tue Oct 10 11:34:16 2017 From: saul-mirone at qq.com (=?utf-8?B?bWlyb25l?=) Date: Tue, 10 Oct 2017 19:34:16 +0800 Subject: [Haskell-cafe] Confusing `bind` and (>>=) Message-ID: Hi there, I'm learning haskell for weeks and I'm trying to write a parser using haskell. First I create a datatype: newtype Parser a = P (String -> [(a, String)]) I create a function called `bind` : bind :: Parser a -> ( a -> Parser b) -> Parser b bind f g = P $ \s -> concatMap (\(a, s') -> parse (g a) s') $ parse f s and then: instance Monad Parser where (>>=) = bind that's looks cool, than I write a function liftToken :: (Char -> [a]) -> Parser a liftToken f = P g where g [] = [] g (c:cs) = f c >>= (\x -> return (x, cs)) It works well, then I change this function to liftToken :: (Char -> [a]) -> Parser a liftToken f = P g where g [] = [] g (c:cs) = f c `bind` (\x -> return (x, cs)) GHC throw errors: regular.hs|153 col 14 error| • Couldn't match expected type ‘Parser t0’ with actual type ‘[a]’ • In the first argument of ‘bind’, namely ‘f c’ In the expression: f c `bind` (\ x -> return (x, cs)) In an equation for ‘g’: g (c : cs) = f c `bind` (\ x -> return (x, cs)) • Relevant bindings include f :: Char -> [a] (bound at regular.hs:151:11) liftToken :: (Char -> [a]) -> Parser a (bound at regular.hs:151:1) That's really confusing, why I can use (>>=) but I can't use `bind`? Is there any difference between them? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue Oct 10 11:43:41 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 10 Oct 2017 22:43:41 +1100 Subject: [Haskell-cafe] Confusing `bind` and (>>=) In-Reply-To: References: Message-ID: On 10 October 2017 at 22:34, mirone wrote: > Hi there, > I'm learning haskell for weeks and I'm trying to write a parser using > haskell. > First I create a datatype: > newtype Parser a = P (String -> [(a, String)]) > I create a function called `bind` : > bind :: Parser a -> ( a -> Parser b) -> Parser b > bind f g = P $ \s -> concatMap (\(a, s') -> parse (g a) s') $ parse f s > and then: > instance Monad Parser where > (>>=) = bind > that's looks cool, than I write a function > liftToken :: (Char -> [a]) -> Parser a > liftToken f = P g where > g [] = [] > g (c:cs) = f c >>= (\x -> return (x, cs)) Here, f c :: [a], so you're using the [] instance of Monad, hence (>>=) :: [a] -> (a -> [b]) -> [b] > It works well, then I change this function to > liftToken :: (Char -> [a]) -> Parser a > liftToken f = P g where > g [] = [] > g (c:cs) = f c `bind` (\x -> return (x, cs)) > GHC throw errors: > regular.hs|153 col 14 error| • Couldn't match expected type ‘Parser t0’ > with actual type ‘[a]’ • In the first argument of ‘bind’, namely ‘f c’ In > the expression: f c `bind` (\ x -> return (x, cs)) In an equation for ‘g’: g > (c : cs) = f c `bind` (\ x -> return (x, cs)) • Relevant bindings include f > :: Char -> [a] (bound at regular.hs:151:11) liftToken :: (Char -> [a]) -> > Parser a (bound at regular.hs:151:1) > > That's really confusing, why I can use (>>=) but I can't use `bind`? Is > there any difference between them? > > _______________________________________________ > 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. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jpaugh at gmx.com Tue Oct 10 13:48:24 2017 From: jpaugh at gmx.com (jpaugh at gmx.com) Date: Tue, 10 Oct 2017 08:48:24 -0500 Subject: [Haskell-cafe] Confusing `bind` and (>>=) In-Reply-To: References: Message-ID: <7B3EE1B8-C708-4739-87E5-5CC04CF32A4A@gmx.com> On October 10, 2017 6:43:41 AM CDT, Ivan Lazar Miljenovic wrote: >On 10 October 2017 at 22:34, mirone wrote: >> Hi there, >> I'm learning haskell for weeks and I'm trying to write a parser >using >> haskell. >> First I create a datatype: >> newtype Parser a = P (String -> [(a, String)]) >> I create a function called `bind` : >> bind :: Parser a -> ( a -> Parser b) -> Parser b >> bind f g = P $ \s -> concatMap (\(a, s') -> parse (g a) s') $ >parse f s >> and then: >> instance Monad Parser where >> (>>=) = bind >> that's looks cool, than I write a function >> liftToken :: (Char -> [a]) -> Parser a >> liftToken f = P g where >> g [] = [] >> g (c:cs) = f c >>= (\x -> return (x, cs)) > >Here, f c :: [a], so you're using the [] instance of Monad, hence >(>>=) :: [a] -> (a -> [b]) -> [b] Yep, and >>= for [a] will often have different semantics then whatever monad you had in mind. You can inject the list into the parser monad by using return. return (f c) `bind` (\x -> return (x, cs)) > >> It works well, then I change this function to >> liftToken :: (Char -> [a]) -> Parser a >> liftToken f = P g where >> g [] = [] >> g (c:cs) = f c `bind` (\x -> return (x, cs)) >> GHC throw errors: >> regular.hs|153 col 14 error| • Couldn't match expected type >‘Parser t0’ >> with actual type ‘[a]’ • In the first argument of ‘bind’, namely ‘f >c’ In >> the expression: f c `bind` (\ x -> return (x, cs)) In an equation for >‘g’: g >> (c : cs) = f c `bind` (\ x -> return (x, cs)) • Relevant bindings >include f >> :: Char -> [a] (bound at regular.hs:151:11) liftToken :: (Char -> >[a]) -> >> Parser a (bound at regular.hs:151:1) >> >> That's really confusing, why I can use (>>=) but I can't use >`bind`? Is >> there any difference between them? >> >> _______________________________________________ >> 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. > > > >-- >Ivan Lazar Miljenovic >Ivan.Miljenovic at gmail.com >http://IvanMiljenovic.wordpress.com >_______________________________________________ >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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From johannes.waldmann at htwk-leipzig.de Tue Oct 10 16:39:51 2017 From: johannes.waldmann at htwk-leipzig.de (waldmann) Date: Tue, 10 Oct 2017 18:39:51 +0200 Subject: [Haskell-cafe] parallel strategies for foldMap? Message-ID: <75ed4e4e-f07c-bbd9-8eff-d3605ab0f322@htwk-leipzig.de> Dear Cafe, I wonder if there is some accepted wisdom (and implementation) to support parallel foldMap in some uniform way. It should probably be tuneable for the case that mappend is less or more expensive than the function to apply in the elements. I can do the following, but it does not parallelize the mappends: import qualified Data.Foldable as F import Control.Parallel.Strategies foldMapPar :: (Foldable f, Monoid b) => Int -> (a -> b) -> f a -> b foldMapPar block f xs = F.fold ( map f (F.toList xs) `using` parBuffer block rseq ) In my application, the Foldable thingy is an unbalanced tree. - J.W. ( the above is a genuine question, while the following is a genuine announcement: don't miss the early registration deadline for "Haskell in Leipzig" https://hal2017.softbase.org/ ) From yotam2206 at gmail.com Tue Oct 10 16:56:25 2017 From: yotam2206 at gmail.com (Yotam Ohad) Date: Tue, 10 Oct 2017 16:56:25 +0000 Subject: [Haskell-cafe] Pattern Matching with Different Types Message-ID: Hello cafe, I am trying to do the following: data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } data Bar = Bar { a1 :: Int -> Int } func :: a -> Maybe (Int -> Int) -- a is either Foo or Bar func (x::(Bar/Foo) = Just $ a1 x func _ = Nothing I'm not sure how to implement this. All I know that the types are matching so I think it could be possible. Thanks for your help -Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue Oct 10 17:33:31 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 10 Oct 2017 17:33:31 +0000 Subject: [Haskell-cafe] Pattern Matching with Different Types In-Reply-To: References: Message-ID: Hi Yotam, One way to do this is to take an `Either Foo Bar` as an argument instead, then you can pattern match on its Left and Right. This is preferable if the function is only meant to work for a limited number of types. If you want it to be extensible to any number of types you can write a typeclass that contains `func` with the same type signature as you have now. There are also some extensions built in to GHC to do this automatically for you, but I don't recall exactly which ones to enable... HTH, Adam On Tue, 10 Oct 2017 at 18:58 Yotam Ohad wrote: > Hello cafe, > I am trying to do the following: > > data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } > data Bar = Bar { a1 :: Int -> Int } > > func :: a -> Maybe (Int -> Int) -- a is either Foo or Bar > func (x::(Bar/Foo) = Just $ a1 x > func _ = Nothing > > I'm not sure how to implement this. All I know that the types are matching > so I think it could be possible. > > Thanks for your help > -Yotam > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From parsonsmatt at gmail.com Tue Oct 10 17:39:49 2017 From: parsonsmatt at gmail.com (Matt) Date: Tue, 10 Oct 2017 11:39:49 -0600 Subject: [Haskell-cafe] Pattern Matching with Different Types In-Reply-To: References: Message-ID: Hi Yotam, A type variable `a` means that you know absolutely nothing about the variable, and can't treat it specially. So you can't special-case your function to "either Foo or Bar." You can achieve your goal like this: func :: Either Foo Bar -> (Int -> Int) func (Left (Foo a _)) = a func (Right (Bar a)) = a The kind of runtime type inspection you might be used to from other langauges is available via the Typeable class. It's extremely non-idiomatic Haskell, and I strongly recommend against writing this sort of code. For completeness, this also works: func :: Typeable a => a -> Maybe (Int -> Int) func a = maybeFoo <|> maybeBar where maybeFoo = case cast a of Just (Foo a _) -> Just a Nothing -> Nothing maybeBar = case cast a of Just (Bar a) -> Just a Nothing -> Nothing Matt Parsons On Tue, Oct 10, 2017 at 10:56 AM, Yotam Ohad wrote: > Hello cafe, > I am trying to do the following: > > data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } > data Bar = Bar { a1 :: Int -> Int } > > func :: a -> Maybe (Int -> Int) -- a is either Foo or Bar > func (x::(Bar/Foo) = Just $ a1 x > func _ = Nothing > > I'm not sure how to implement this. All I know that the types are matching > so I think it could be possible. > > Thanks for your help > -Yotam > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Oct 11 00:48:35 2017 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 11 Oct 2017 09:48:35 +0900 (JST) Subject: [Haskell-cafe] random library Message-ID: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> Hello, I'm preparing for a major release of the dns package version 3.0.0. https://github.com/kazu-yamamoto/dns/issues/88 Before the release, I would like to replace the random package since it is slow. I'm looking for a random library which is - fast - thread-safe (good for concurrent use) Any recommendations? // Kazu From djohnson.m at gmail.com Wed Oct 11 00:57:23 2017 From: djohnson.m at gmail.com (David Johnson) Date: Tue, 10 Oct 2017 17:57:23 -0700 Subject: [Haskell-cafe] random library In-Reply-To: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> Message-ID: I've heard good things about *mwc-random* (https://github.com/bos/mwc-random ) On Tue, Oct 10, 2017 at 5:48 PM, Kazu Yamamoto wrote: > Hello, > > I'm preparing for a major release of the dns package version 3.0.0. > https://github.com/kazu-yamamoto/dns/issues/88 > > Before the release, I would like to replace the random package since > it is slow. I'm looking for a random library which is > - fast > - thread-safe (good for concurrent use) > > Any recommendations? > > // Kazu > _______________________________________________ > 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. -- Cell: 1.630.740.8204 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed Oct 11 01:06:24 2017 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 11 Oct 2017 10:06:24 +0900 (JST) Subject: [Haskell-cafe] random library In-Reply-To: References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> Message-ID: <20171011.100624.320145164201478039.kazu@iij.ad.jp> Hi David, Thank you for your reply. > I've heard good things about *mwc-random* (https://github.com/bos/mwc-random > ) Are there any example code to use mwc-random safely from multiple threads? // Kazu From will.yager at gmail.com Wed Oct 11 01:30:34 2017 From: will.yager at gmail.com (William Yager) Date: Tue, 10 Oct 2017 21:30:34 -0400 Subject: [Haskell-cafe] random library In-Reply-To: <20171011.100624.320145164201478039.kazu@iij.ad.jp> References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <20171011.100624.320145164201478039.kazu@iij.ad.jp> Message-ID: The best way to generate random values in multiple threads is to safely split your random generator every time you fork. In the case of mwc-random, it looks like you will want to do something like gen' <- initialize =<< (uniformVector gen 32 :: IO (Vector Word32)) forkIO $ ... gen' ... gen There is no good reason to share RNG state across threads. Just use a separate RNG state for every thread. This is inherently thread-safe and more performant. If you're forking very frequently, you will want to benchmark the effect of using a more efficient vector type (i.e. Vector.Unboxed instead of Vector) or fewer elements during initialization. On Tue, Oct 10, 2017 at 9:06 PM, Kazu Yamamoto wrote: > Hi David, > > Thank you for your reply. > > > I've heard good things about *mwc-random* (https://github.com/bos/mwc- > random > > ) > > Are there any example code to use mwc-random safely from multiple > threads? > > // Kazu > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Wed Oct 11 03:11:58 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 10 Oct 2017 23:11:58 -0400 Subject: [Haskell-cafe] random library In-Reply-To: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> Message-ID: <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> > On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) wrote: > > Before the release, I would like to replace the random package since > it is slow. I'm looking for a random library which is > - fast > - thread-safe (good for concurrent use) > > Any recommendations? Just to make it more interesting, I should mention that the RNG should be not just statistically random, but should in fact be crypto random (resist predictability through cryptanalysis when properly seeded). So indeed there are two more issues here: - Securely seeding the RNG (likely using the OS API for random seeds, and/or the RDSEED/RDRAND instructions on Intel CPUs), IIRC we can that from cryptonite, I hope at a reasonable cost. - Choosing a suitable DRBG based on the seed. Likely again something from cryptonite. Some time back I posted to the cryptography list about the soundness of relying on RDRAND in cryptonite's RNG (uses it instead of /dev/urandom and the like when available). The rough consensus IIRC was not rely solely on RDRAND. I never went back to write a PR to address that... http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859 -- Viktor. From thomas.dubuisson at gmail.com Wed Oct 11 03:23:14 2017 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Tue, 10 Oct 2017 20:23:14 -0700 Subject: [Haskell-cafe] random library In-Reply-To: <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> Message-ID: The hash drbg from the drbg package should meet your needs. Deterministic, pure Haskell except the actual hash function. On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" wrote: > > > On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) > wrote: > > > > Before the release, I would like to replace the random package since > > it is slow. I'm looking for a random library which is > > - fast > > - thread-safe (good for concurrent use) > > > > Any recommendations? > > Just to make it more interesting, I should mention that the RNG > should be not just statistically random, but should in fact be > crypto random (resist predictability through cryptanalysis when > properly seeded). > > So indeed there are two more issues here: > > - Securely seeding the RNG (likely using the OS API for > random seeds, and/or the RDSEED/RDRAND instructions on > Intel CPUs), IIRC we can that from cryptonite, I hope > at a reasonable cost. > > - Choosing a suitable DRBG based on the seed. Likely again > something from cryptonite. > > Some time back I posted to the cryptography list about the > soundness of relying on RDRAND in cryptonite's RNG (uses > it instead of /dev/urandom and the like when available). > The rough consensus IIRC was not rely solely on RDRAND. > I never went back to write a PR to address that... > > http://www.metzdowd.com/pipermail/cryptography/2016- > November/thread.html#30859 > > -- > Viktor. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpaugh at gmx.com Wed Oct 11 03:46:49 2017 From: jpaugh at gmx.com (jpaugh at gmx.com) Date: Tue, 10 Oct 2017 22:46:49 -0500 Subject: [Haskell-cafe] random library In-Reply-To: References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> Message-ID: All, Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html Thomas, In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package. Thanks, Jonathan On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson wrote: >The hash drbg from the drbg package should meet your needs. >Deterministic, >pure Haskell except the actual hash function. > >On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" >wrote: > >> >> > On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) >> wrote: >> > >> > Before the release, I would like to replace the random package >since >> > it is slow. I'm looking for a random library which is >> > - fast >> > - thread-safe (good for concurrent use) >> > >> > Any recommendations? >> >> Just to make it more interesting, I should mention that the RNG >> should be not just statistically random, but should in fact be >> crypto random (resist predictability through cryptanalysis when >> properly seeded). >> >> So indeed there are two more issues here: >> >> - Securely seeding the RNG (likely using the OS API for >> random seeds, and/or the RDSEED/RDRAND instructions on >> Intel CPUs), IIRC we can that from cryptonite, I hope >> at a reasonable cost. >> >> - Choosing a suitable DRBG based on the seed. Likely again >> something from cryptonite. >> >> Some time back I posted to the cryptography list about the >> soundness of relying on RDRAND in cryptonite's RNG (uses >> it instead of /dev/urandom and the like when available). >> The rough consensus IIRC was not rely solely on RDRAND. >> I never went back to write a PR to address that... >> >> http://www.metzdowd.com/pipermail/cryptography/2016- >> November/thread.html#30859 >> >> -- >> Viktor. >> >> _______________________________________________ >> 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Wed Oct 11 12:39:30 2017 From: will.yager at gmail.com (William Yager) Date: Wed, 11 Oct 2017 08:39:30 -0400 Subject: [Haskell-cafe] random library In-Reply-To: References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> Message-ID: On Tue, Oct 10, 2017 at 11:23 PM, Thomas DuBuisson < thomas.dubuisson at gmail.com> wrote: > The hash drbg from the drbg package should meet your needs. Deterministic, > pure Haskell except the actual hash function. > > I was looking at this recently; may I ask why drbg and crypto-api even bother to expose the possibility of CSPRNGs "running out" of entropy? This is not thought to be a concern on any cryptographically sound primitive, and it substantially complicates both the implementation and the user-facing API. The currently selected reseed interval of 2^48 is already large enough that it might as well not be there; it's too large to provide forward secrecy and almost large enough that you'll never hit it. If you're looking for a more reputable source for this claim, there is a wealth of literature on the current best practices for OS-level CSPRNGs. In particular, both Linux (via the new getrandom(2) API) and the BSDs (via the block device API which has done the right thing for a long time) now have the behavior of waiting for ~256 bits of initial entropy and then providing unlimited random bytes forever without ever blocking or requiring a reseed. Might I suggest in a future revision of the drbg/crypto-api libraries dropping all mentions of "Either" from the CryptoRandomGen typeclass API, except maybe "newGen"? I think this would make your job a lot easier *and* make the library a lot easier to consume (e.g. via RandT). --Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Wed Oct 11 12:50:49 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Wed, 11 Oct 2017 13:50:49 +0100 Subject: [Haskell-cafe] random library Message-ID: No-one should be using the de facto random package. It is slow and produces surprising results. I think one of the posters suggested using mwc-random and splitting by using a different seed. Although mwc-random has reasonably good properties, there is no guarantee about how correlated the various streams of random numbers will be. QuickCheck uses tf-random to avoid such problems. There is also a version of SplitMix https://hackage.haskell.org/package/splitmix but I don’t think this has been heavily road-tested. But in this case, cryptographically secure randomness is required so I would follow Thomas’ suggestion. PS I just noticed my spellchecker changed defacto to defect! Perhaps AI is taking over. > All, > > Interesting library! Here's a link: http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html > > Thomas, > > In the linked docs, there's a claim that Hash DRBG is the fastest cryptographically secure RNG on Hackage. Do you have a link to the benchmark results, or perhaps some updated ones? Unlike Viktor, I'm interested in less secure applications, but if the performance is good, it might be worth switching from the defacto random package. > > Thanks, > Jonathan > > On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson > wrote: >> The hash drbg from the drbg package should meet your needs. >> Deterministic, >> pure Haskell except the actual hash function. >> >> On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" > >> wrote: >> >>> >>>> On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) > >>> wrote: >>>> >>>> Before the release, I would like to replace the random package >> since >>>> it is slow. I'm looking for a random library which is >>>> - fast >>>> - thread-safe (good for concurrent use) >>>> >>>> Any recommendations? >>> >>> Just to make it more interesting, I should mention that the RNG >>> should be not just statistically random, but should in fact be >>> crypto random (resist predictability through cryptanalysis when >>> properly seeded). >>> >>> So indeed there are two more issues here: >>> >>> - Securely seeding the RNG (likely using the OS API for >>> random seeds, and/or the RDSEED/RDRAND instructions on >>> Intel CPUs), IIRC we can that from cryptonite, I hope >>> at a reasonable cost. >>> >>> - Choosing a suitable DRBG based on the seed. Likely again >>> something from cryptonite. >>> >>> Some time back I posted to the cryptography list about the >>> soundness of relying on RDRAND in cryptonite's RNG (uses >>> it instead of /dev/urandom and the like when available). >>> The rough consensus IIRC was not rely solely on RDRAND. >>> I never went back to write a PR to address that... >>> >>> http://www.metzdowd.com/pipermail/cryptography/2016- >>> November/thread.html#30859 >>> >>> -- >>> Viktor. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.dubuisson at gmail.com Wed Oct 11 14:13:10 2017 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed, 11 Oct 2017 07:13:10 -0700 Subject: [Haskell-cafe] random library In-Reply-To: References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> Message-ID: > I was looking at this recently; may I ask why drbg and crypto-api even > bother to expose the possibility of CSPRNGs "running out" of entropy? Because most standards discuss this possibility and my decisions at the time were motivated by trying to make those implementations as much of a mindless "translate English to Haskell" job as possible. > This is not thought to be a concern on any cryptographically sound primitive The primitive's soundness doesn't have anything to do with the period. We can construct a sound cipher with small block size and claim the counter mode of this cipher is a DRBG that is both secure and with a small period. > , and > it substantially complicates both the implementation and the user-facing > API. The implementations are not substantially harder. For the users I had begun moving to exceptions with separate `.Pure` and `.Exceptions` modules. The API is all a bit long in the tooth and could stand for me to spend some time on it though. > The currently selected reseed interval of 2^48 is already large enough > that it might as well not be there; it's too large to provide forward > secrecy Again, this is unrelated. The instantiated Hash and HMAC DRBGs both have forward secrecy and large intervals. > and almost large enough that you'll never hit it. Yes! That is the convincing argument right there. The fact that no user actually cares (beyond getting an exception instead of unsafe operation) or will ever hit such a bound is rather important. > Might I suggest in a future revision of the drbg/crypto-api libraries > dropping all mentions of "Either" from the CryptoRandomGen typeclass API, > except maybe "newGen"? I think this would make your job a lot easier *and* > make the library a lot easier to consume (e.g. via RandT). Well my job is easiest doing nothing. But yes, making it nice for users would be good. I've been meaning to give these packages some more attention and I'll take this as motivation. -Thomas From thomas.dubuisson at gmail.com Wed Oct 11 14:27:15 2017 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed, 11 Oct 2017 07:27:15 -0700 Subject: [Haskell-cafe] random library In-Reply-To: References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> Message-ID: Jonathan, The full claim is: > As of 1July2014 this remains the fastest cryptographic RNG on hackage that has been ran against known answer tests. Many other packaged generators are off-the-cuff inventions of the programmer - IIRC the two designs I saw most were 1. Pick a random IV or counter, generate some data with a block cipher, repeat and 2. Just run a stream cipher like AES-CTR (so, no forward secrecy). The developers are often people who's knowledge I have faith in but the decision is too serious to make such designs lightly. The only package I knew of at the time that tried to implement a standard that included KATs (unit tests) was my DRBG package w/ tests for the Hash generator and HMAC. In this case, the Hash generator is notably faster than HMAC. As for the performance of this and other generators, I did some benchmarking now 4 years ago: http://tommd.github.io/posts/RNG-Bench.html N.B. I intentionally did not discuss security in that post. Many people want a standard, some just don't care about forward secrecy, others won't touch RDRAND with a ten foot pole. All fine, but too many dimensions for me to want to talk about in a blog post. Cheers, Thomas On Tue, Oct 10, 2017 at 8:46 PM, wrote: > All, > > Interesting library! Here's a link: > http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html > > Thomas, > > In the linked docs, there's a claim that Hash DRBG is the fastest > cryptographically secure RNG on Hackage. Do you have a link to the benchmark > results, or perhaps some updated ones? Unlike Viktor, I'm interested in less > secure applications, but if the performance is good, it might be worth > switching from the defacto random package. > > Thanks, > Jonathan > > > On October 10, 2017 10:23:14 PM CDT, Thomas DuBuisson > wrote: >> >> The hash drbg from the drbg package should meet your needs. Deterministic, >> pure Haskell except the actual hash function. >> >> On Oct 10, 2017 8:13 PM, "Viktor Dukhovni" wrote: >>> >>> >>> > On Oct 10, 2017, at 8:48 PM, Kazu Yamamoto (山本和彦) >>> > wrote: >>> > >>> > Before the release, I would like to replace the random package since >>> > it is slow. I'm looking for a random library which is >>> > - fast >>> > - thread-safe (good for concurrent use) >>> > >>> > Any recommendations? >>> >>> Just to make it more interesting, I should mention that the RNG >>> should be not just statistically random, but should in fact be >>> crypto random (resist predictability through cryptanalysis when >>> properly seeded). >>> >>> So indeed there are two more issues here: >>> >>> - Securely seeding the RNG (likely using the OS API for >>> random seeds, and/or the RDSEED/RDRAND instructions on >>> Intel CPUs), IIRC we can that from cryptonite, I hope >>> at a reasonable cost. >>> >>> - Choosing a suitable DRBG based on the seed. Likely again >>> something from cryptonite. >>> >>> Some time back I posted to the cryptography list about the >>> soundness of relying on RDRAND in cryptonite's RNG (uses >>> it instead of /dev/urandom and the like when available). >>> The rough consensus IIRC was not rely solely on RDRAND. >>> I never went back to write a PR to address that... >>> >>> >>> http://www.metzdowd.com/pipermail/cryptography/2016-November/thread.html#30859 >>> >>> -- >>> Viktor. >>> >>> _______________________________________________ >>> 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. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. From emertens at gmail.com Wed Oct 11 23:04:51 2017 From: emertens at gmail.com (Eric Mertens) Date: Wed, 11 Oct 2017 23:04:51 +0000 Subject: [Haskell-cafe] Galois is hiring Message-ID: Hello, Galois is growing again! We're looking for researchers, principal investigators, software engineers, including those with expertise in functional programming, formal methods, machine learning, embedded systems, computer security, or networking. For the exact available positions, please have a look at our website: http://galois.com/careers We now have three locations: Portland, Ore.; Arlington, Va.; and Dayton, Ohio. There are positions available at all locations. We are looking for people to work on-site, not remotely. Mostly, we are looking for candidates who are already authorized to work in the US, but in exceptional situations we can work with the candidate to obtain the necessary documentation. If you are interested, please apply through the web site. If you have questions about working at Galois, you're welcome to contact me directly. Best regards, Eric Mertens glguy -------------- next part -------------- An HTML attachment was scrubbed... URL: From emertens at gmail.com Wed Oct 11 23:10:17 2017 From: emertens at gmail.com (Eric Mertens) Date: Wed, 11 Oct 2017 23:10:17 +0000 Subject: [Haskell-cafe] Pattern Matching with Different Types In-Reply-To: References: Message-ID: If you want a function's behavior to vary by the types at which it is used, you'd need to use a type class. For example: data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } data Bar = Bar { a3 :: Int -> Int } class Func a where func :: a -> Maybe (Int -> Int) instance Func Foo where func = Just . a1 instance Func Bar where func = Just . a3 On Tue, Oct 10, 2017 at 10:42 AM Matt wrote: > Hi Yotam, > > A type variable `a` means that you know absolutely nothing about the > variable, and can't treat it specially. So you can't special-case your > function to "either Foo or Bar." > > You can achieve your goal like this: > > func :: Either Foo Bar -> (Int -> Int) > func (Left (Foo a _)) = a > func (Right (Bar a)) = a > > The kind of runtime type inspection you might be used to from other > langauges is available via the Typeable class. It's extremely non-idiomatic > Haskell, and I strongly recommend against writing this sort of code. For > completeness, this also works: > > func :: Typeable a => a -> Maybe (Int -> Int) > func a = maybeFoo <|> maybeBar > where > maybeFoo = case cast a of > Just (Foo a _) -> Just a > Nothing -> Nothing > maybeBar = case cast a of > Just (Bar a) -> Just a > Nothing -> Nothing > > Matt Parsons > > On Tue, Oct 10, 2017 at 10:56 AM, Yotam Ohad wrote: > >> Hello cafe, >> I am trying to do the following: >> >> data Foo = Foo { a1 :: Int -> Int, a2 :: Int -> Char } >> data Bar = Bar { a1 :: Int -> Int } >> >> func :: a -> Maybe (Int -> Int) -- a is either Foo or Bar >> func (x::(Bar/Foo) = Just $ a1 x >> func _ = Nothing >> >> I'm not sure how to implement this. All I know that the types are >> matching so I think it could be possible. >> >> Thanks for your help >> -Yotam >> >> _______________________________________________ >> 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. >> > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.fine at gmail.com Sat Oct 14 02:14:33 2017 From: mark.fine at gmail.com (Mark Fine) Date: Fri, 13 Oct 2017 19:14:33 -0700 Subject: [Haskell-cafe] Network Connect Timeouts Message-ID: I'd like a configurable network connect timeout. Has anyone solved this reasonably? *System.Timeout.timeout* times out connections, but works on the granularity of the life of the connection. Is there a reasonable way to configure a timeout around just establishing the connection? Maybe something like a conditional timeout that enables an action to disable the timeout once it expires? As a workaround, I'm spinning trying to successfully connect first before trying to connect for real: -- | Try the TCP connection and see if you can connect... -- tryTCPClient :: Int -> ClientSettings -> IO () tryTCPClient microseconds settings = do ok <- newIORef False void $ timeout microseconds $ runTCPClient settings $ const $ writeIORef ok True ok' <- readIORef ok unless ok' $ tryTCPClient microseconds settings -- | Wrap runTCPClient with a connect timeout. -- -- Tries the TCP connection first, and the runs the regular runTCPClient. -- Of course, this only enforces a TCP connect timeout on the first connect. -- The second TCP connect has no timeout :( -- runTCPClient' :: Int -> ClientSettings -> (AppData -> IO a) -> IO a runTCPClient' microseconds settings action = do tryTCPClient microseconds settings runTCPClient settings action I've also tried running the *tryTCPClient* in its own thread concurrently with *runTCPClient* and throwing an exception if it can't connect in *microseconds*. None of these offer an actual true connection establishment timeout. Has anyone found a way to solve this? Thanks! Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Oct 14 09:35:49 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 14 Oct 2017 11:35:49 +0200 Subject: [Haskell-cafe] Network Connect Timeouts In-Reply-To: References: Message-ID: <4a9584c4-0dba-b817-a824-d7a9cee7458b@durchholz.org> I do not have an answer to your actual question, just a side node on your workaround: Am 14.10.2017 um 04:14 schrieb Mark Fine: > As a workaround, I'm spinning trying to successfully connect first > before trying to connect for real: This does not give you the effect you want out of it. Nowadays, middleboxes and servers keep track of past connections, for various reasons - mostly it's NAT in things like cable modems, and intrusion detection systems (IDSes) in servers or close-to-server middleboxes. Cable modems and similar tend to operate under memory-constrained conditions. If you open two connections, this may be the final straw that breaks the cable modem, causing all kinds of weird behaviour (the better ones will drop the longest-unused connections, but I have seen some that will start exhibiting all kinds of bugs). This failure mode is particularly important if you plan to open many connections from a client at the user's home; otherwise it is less relevant. IDSes will notice that you quickly opened and closed connections, and potentially flag this as suspicious. The usual solution is to open the connection, and retry a few times. (Failed connection attempts tend to be not remembered by middleboxes.) If retrying fails, either ask the user if the program should retry connecting (not telling the user that there were retries already, they don't care and wouldn't understand), or if it's a server, do the retries with an exponential standoff and log the situation once it becomes severe enough. Neither solution is really doable at the network connection layer, so maybe it's actually okay if there is no answer to your original question :-) Regards, Jo From lambda.fairy at gmail.com Sat Oct 14 10:09:51 2017 From: lambda.fairy at gmail.com (Chris Wong) Date: Sat, 14 Oct 2017 23:09:51 +1300 Subject: [Haskell-cafe] Network Connect Timeouts In-Reply-To: References: Message-ID: Hi Mark, What networking library are you using? There should be a lower level interface which allows for managing the lifetime of a connection by hand. Chris On Oct 14, 2017 15:17, "Mark Fine" wrote: > I'd like a configurable network connect timeout. Has anyone solved this > reasonably? > > *System.Timeout.timeout* times out connections, but works on the > granularity of the life of the connection. Is there a reasonable way to > configure a timeout around just establishing the connection? Maybe > something like a conditional timeout that enables an action to disable the > timeout once it expires? > > As a workaround, I'm spinning trying to successfully connect first before > trying to connect for real: > > -- | Try the TCP connection and see if you can connect... > -- > tryTCPClient :: Int -> ClientSettings -> IO () > tryTCPClient microseconds settings = do > ok <- newIORef False > void $ timeout microseconds $ runTCPClient settings $ const $ > writeIORef ok True > ok' <- readIORef ok > unless ok' $ > tryTCPClient microseconds settings > > -- | Wrap runTCPClient with a connect timeout. > -- > -- Tries the TCP connection first, and the runs the regular runTCPClient. > -- Of course, this only enforces a TCP connect timeout on the first > connect. > -- The second TCP connect has no timeout :( > -- > runTCPClient' :: Int -> ClientSettings -> (AppData -> IO a) -> IO a > runTCPClient' microseconds settings action = do > tryTCPClient microseconds settings > runTCPClient settings action > > I've also tried running the *tryTCPClient* in its own thread concurrently > with *runTCPClient* and throwing an exception if it can't connect in > *microseconds*. None of these offer an actual true connection > establishment timeout. > > Has anyone found a way to solve this? Thanks! > > Mark > > > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sat Oct 14 13:09:51 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sat, 14 Oct 2017 14:09:51 +0100 Subject: [Haskell-cafe] haskell-cafe brown out [Was: random library] In-Reply-To: <20171011162852.s2pwppeiteu6ivgk@matica.foolinux.mooo.com> References: <20171011162852.s2pwppeiteu6ivgk@matica.foolinux.mooo.com> Message-ID: <9F7C1BBD-E37E-457A-9AF2-E935BA7D7265@steinitz.org> I get a daily digest from the mailing list and then cut out the bit that seemed relevant fwiw. Well done for caring about mailing lists :) > On 11 Oct 2017, at 17:28, Ian Zimmerman wrote: > > On 2017-10-11 13:50, dominic at steinitz.org wrote: > >>> Interesting library! Here's a link: >>> http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html >>> >>> >>> Thomas, >>> >>> In the linked docs, there's a claim that Hash DRBG is the fastest >>> cryptographically secure RNG on Hackage. Do you have a link to the >>> benchmark results, or perhaps some updated ones? Unlike Viktor, I'm >>> interested in less secure applications, but if the performance is >>> good, it might be worth switching from the defacto random package. >>> >>> Thanks, Jonathan > >> No-one should be using the de facto random package. It is slow and >> produces surprising results. >> >> I think one of the posters suggested using mwc-random and splitting by >> using a different seed. Although mwc-random has reasonably good >> properties, there is no guarantee about how correlated the various >> streams of random numbers will be. QuickCheck uses tf-random to avoid >> such problems. There is also a version of SplitMix >> https://hackage.haskell.org/package/splitmix >> but I don’t think this >> has been heavily road-tested. >> >> But in this case, cryptographically secure randomness is required so I >> would follow Thomas’ suggestion. >> >> PS I just noticed my spellchecker changed defacto to defect! Perhaps >> AI is taking over. > > Hello, may I ask how exactly you posted the above message? > > Your message has no threading headers (In-Reply-To or References), but I > _think_ I never received the message to which you appear to be reacting > (that one by "Jonathan"). I cannot prove it beyond doubt because of the > missing headers. Was "Jonathan"'s message posted on the haskell-cafe > mailing list at all? Or what else is going on here? > > Ian, who cares about his mailing lists > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > Do obvious transformation on domain to reply privately _only_ on Usenet. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From itz at very.loosely.org Sat Oct 14 16:58:35 2017 From: itz at very.loosely.org (Ian Zimmerman) Date: Sat, 14 Oct 2017 09:58:35 -0700 Subject: [Haskell-cafe] haskell-cafe brown out [Was: random library] In-Reply-To: <9F7C1BBD-E37E-457A-9AF2-E935BA7D7265@steinitz.org> References: <20171011162852.s2pwppeiteu6ivgk@matica.foolinux.mooo.com> <9F7C1BBD-E37E-457A-9AF2-E935BA7D7265@steinitz.org> Message-ID: <20171014165835.ndttxirgpiwevvfz@matica.foolinux.mooo.com> On 2017-10-14 14:09, dominic at steinitz.org wrote: > > Your message has no threading headers (In-Reply-To or References), > > but I _think_ I never received the message to which you appear to be > > reacting (that one by "Jonathan"). I cannot prove it beyond doubt > > because of the missing headers. Was "Jonathan"'s message posted on > > the haskell-cafe mailing list at all? Or what else is going on > > here? > I get a daily digest from the mailing list and then cut out the bit > that seemed relevant fwiw. Well done for caring about mailing lists :) [replying to list because that's what Dominic did, I wouldn't otherwise] Never mind, Jonathan's message was in my spam box. (I'll look into the cause of _that_ shortly). Some MUAs are smart enough to handle the replying-to-digest case and insert the proper threading headers. They are unfortunately (?) not the same ones as those smart enough to draw nice GUI sprites :P Maybe you can investigate that some time when you're bored. But in general I have to say haskell.org lists are _a lot_ cleaner now than a few years ago when pretty much _every_ thread was broken due to ppl posting via shmooglegroups. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet. From lambda.fairy at gmail.com Sun Oct 15 00:17:10 2017 From: lambda.fairy at gmail.com (Chris Wong) Date: Sun, 15 Oct 2017 13:17:10 +1300 Subject: [Haskell-cafe] Network Connect Timeouts In-Reply-To: References: Message-ID: Hi Mark, >From reading the source code for *runTCPClient* [1], it looks like a thin wrapper around *getSocketFamilyTCP* and *close*. It should be sufficient to copy that definition into your project and wrap the *getSocketFamilyTCP* call in a *timeout*. You might need to import *Data.Streaming.Network.Internal* to get access to the *AppData* constructor. Hope this helps! [1] https://hackage.haskell.org/package/streaming-commons-0.1.18/docs/src/Data-Streaming-Network.html#runTCPClient On Sun, Oct 15, 2017 at 9:08 AM, Mark Fine wrote: > Hi Chris, > > In my application, I'm using *Data.Conduit.Network* from *conduit-extra* directly > (*Data.Streaming.Network* from *streaming-commons* indirectly). The > timeout I'm interested in managing is the connection establishment timeout > - how long does the connect call wait to establish a connection. I haven't > been able to figure out how to control this outside of applying a > non-conditional timeout to the connect call (which is a timeout on the > lifetime of a connection, not a timeout on the establishment of a > connection). Thanks! > > Mark > > On Sat, Oct 14, 2017 at 3:09 AM, Chris Wong > wrote: > >> Hi Mark, >> >> What networking library are you using? >> >> There should be a lower level interface which allows for managing the >> lifetime of a connection by hand. >> >> Chris >> >> On Oct 14, 2017 15:17, "Mark Fine" wrote: >> >>> I'd like a configurable network connect timeout. Has anyone solved this >>> reasonably? >>> >>> *System.Timeout.timeout* times out connections, but works on the >>> granularity of the life of the connection. Is there a reasonable way to >>> configure a timeout around just establishing the connection? Maybe >>> something like a conditional timeout that enables an action to disable the >>> timeout once it expires? >>> >>> As a workaround, I'm spinning trying to successfully connect first >>> before trying to connect for real: >>> >>> -- | Try the TCP connection and see if you can connect... >>> -- >>> tryTCPClient :: Int -> ClientSettings -> IO () >>> tryTCPClient microseconds settings = do >>> ok <- newIORef False >>> void $ timeout microseconds $ runTCPClient settings $ const $ >>> writeIORef ok True >>> ok' <- readIORef ok >>> unless ok' $ >>> tryTCPClient microseconds settings >>> >>> -- | Wrap runTCPClient with a connect timeout. >>> -- >>> -- Tries the TCP connection first, and the runs the regular runTCPClient. >>> -- Of course, this only enforces a TCP connect timeout on the first >>> connect. >>> -- The second TCP connect has no timeout :( >>> -- >>> runTCPClient' :: Int -> ClientSettings -> (AppData -> IO a) -> IO a >>> runTCPClient' microseconds settings action = do >>> tryTCPClient microseconds settings >>> runTCPClient settings action >>> >>> I've also tried running the *tryTCPClient* in its own thread >>> concurrently with *runTCPClient* and throwing an exception if it can't >>> connect in *microseconds*. None of these offer an actual true >>> connection establishment timeout. >>> >>> Has anyone found a way to solve this? Thanks! >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> 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. >>> >> > -- Chris Wong (https://lambda.xyz) "I had not the vaguest idea what this meant and when I could not remember the words, my tutor threw the book at my head, which did not stimulate my intellect in any way." -- Bertrand Russell -------------- next part -------------- An HTML attachment was scrubbed... URL: From serge.kosyrev at iohk.io Sun Oct 15 23:07:41 2017 From: serge.kosyrev at iohk.io (Kosyrev Serge) Date: Mon, 16 Oct 2017 02:07:41 +0300 Subject: [Haskell-cafe] Exposing a GADT-provided dictionary Message-ID: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> Good day, cafe! I found a way to expose a GADT-provided dictionary, but I don't quite like it: > {-# LANGUAGE GADTs, RankNTypes #-} > > import Data.Function ((&)) > > class HasDict a where > > data GADT a where > G1 :: HasDict a => a -> GADT a > -- ... > Gn :: HasDict a => a -> GADT a > > -- | Execute @body with the dictionary for HasDict extracted from the > -- GADT. > withGADTDict :: > (forall b. (b ~ a, HasDict b) => GADT b -> c) -> GADT a -> c > withGADTDict body x = x & case x of > G1 _ -> body > -- ... > Gn _ -> body The problem is in withGADTDict's proportionality to the number of GADT's clauses, as it is somewhat anti-modular. Is that the only light-weight option? I can imagine there is a way to leverage generic programming, but that's a bit heavy.. -- с уважениeм / respectfully, Kosyrev Serge PGP Key ID: 3F62F118E38BED6D -- “Most deadly errors arise from obsolete assumptions.” -- Frank Herbert, Children of Dune From lysxia at gmail.com Mon Oct 16 11:56:38 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 16 Oct 2017 07:56:38 -0400 Subject: [Haskell-cafe] Exposing a GADT-provided dictionary In-Reply-To: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> References: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> Message-ID: <894738d7-0892-2f36-cf2f-acfa4d092cb1@gmail.com> Hi Kosyrev, Would refactoring the type like this work for you? > data GADT a where > G :: HasDict a => Tag -> a -> GADT a > > data Tag = Tag1 | ... | Tagn > > withGADTDict :: ... > withGADTDict body x = x & case x of > G _ _ -> body Li-yao On 10/15/2017 07:07 PM, Kosyrev Serge wrote: > Good day, cafe! > > I found a way to expose a GADT-provided dictionary, but I don't quite > like it: > >> {-# LANGUAGE GADTs, RankNTypes #-} >> >> import Data.Function ((&)) >> >> class HasDict a where >> >> data GADT a where >> G1 :: HasDict a => a -> GADT a >> -- ... >> Gn :: HasDict a => a -> GADT a >> >> -- | Execute @body with the dictionary for HasDict extracted from the >> -- GADT. >> withGADTDict :: >> (forall b. (b ~ a, HasDict b) => GADT b -> c) -> GADT a -> c >> withGADTDict body x = x & case x of >> G1 _ -> body >> -- ... >> Gn _ -> body > > The problem is in withGADTDict's proportionality to the number of GADT's > clauses, as it is somewhat anti-modular. > > Is that the only light-weight option? I can imagine there is a way to > leverage generic programming, but that's a bit heavy.. > From capn.freako at gmail.com Mon Oct 16 15:42:48 2017 From: capn.freako at gmail.com (David Banas) Date: Mon, 16 Oct 2017 08:42:48 -0700 Subject: [Haskell-cafe] Where to import Id from? Message-ID: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> Hi all, Would someone tell me where I can import Id from, please? I’ve struck out with both Hoogle and Google searches. Thanks! -db From benjamin.peter.doyle at gmail.com Mon Oct 16 15:49:28 2017 From: benjamin.peter.doyle at gmail.com (Ben Doyle) Date: Mon, 16 Oct 2017 15:49:28 +0000 Subject: [Haskell-cafe] Where to import Id from? In-Reply-To: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> References: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> Message-ID: id (lowercase), the function, is in Prelude. Do you mean that, or a type called Id? If the latter, what's the context? On Mon, Oct 16, 2017 at 11:44 AM David Banas wrote: > Hi all, > > Would someone tell me where I can import Id from, please? > I’ve struck out with both Hoogle and Google searches. > > Thanks! > -db > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Oct 16 15:49:44 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 16 Oct 2017 18:49:44 +0300 Subject: [Haskell-cafe] Where to import Id from? In-Reply-To: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> References: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> Message-ID: I'm not sure which one you're looking for, but there are a number of matches on Stackage: https://www.stackage.org/lts-9.9/hoogle?q=Id On Mon, Oct 16, 2017 at 6:42 PM, David Banas wrote: > Hi all, > > Would someone tell me where I can import Id from, please? > I’ve struck out with both Hoogle and Google searches. > > Thanks! > -db > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cs.uchicago.edu Mon Oct 16 16:06:57 2017 From: stuart at cs.uchicago.edu (Stuart A. Kurtz) Date: Mon, 16 Oct 2017 11:06:57 -0500 Subject: [Haskell-cafe] Where to import Id from? In-Reply-To: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> References: <25C6AA4E-8A9D-4E66-8854-A51B39FBA45C@gmail.com> Message-ID: Dear David, > Would someone tell me where I can import Id from, please? > I’ve struck out with both Hoogle and Google searches. Perhaps you're looking for the Identity type class from Data.Functor.Identity. Peace, Stu From jpaugh at gmx.com Mon Oct 16 17:32:10 2017 From: jpaugh at gmx.com (jpaugh at gmx.com) Date: Mon, 16 Oct 2017 12:32:10 -0500 Subject: [Haskell-cafe] Your haskell-cafe message [Was: random library] In-Reply-To: <20171014172903.dw26p6jf2hmywmce@matica.foolinux.mooo.com> References: <20171011.094835.1630496721874215133.kazu@iij.ad.jp> <60751636-19D8-4C8B-91CF-1CDDF72F9F5B@dukhovni.org> <20171014172903.dw26p6jf2hmywmce@matica.foolinux.mooo.com> Message-ID: <7402D298-01FF-4F07-8FA2-DEAAA5E55956@gmx.com> Ian, Thanks for the note. I work for a secondary school, so that explains the block. I'll keep that in mind, and send mail from home. Thanks, Jon On October 14, 2017 12:29:03 PM CDT, Ian Zimmerman wrote: >On 2017-10-10 22:46, jpaugh at gmx.com wrote: > >> Interesting library! Here's a link: >> >http://hackage.haskell.org/package/DRBG-0.5.5/docs/Crypto-Random-DRBG.html > >The address from which you posted this is listed by spamhaus: > > ahiker!2 itz$ rblcheck 172.56.6.158 >172.56.6.158 not listed by sbl.spamhaus.org >172.56.6.158 listed by xbl.spamhaus.org >172.56.6.158 listed by pbl.spamhaus.org >172.56.6.158 not listed by bl.spamcop.net >172.56.6.158 not listed by psbl.surriel.com >172.56.6.158 not listed by dul.dnsbl.sorbs.net > >This often happens when people post from cafes and similar, and if this >is the case here not much can be done, unfortunately - other than >perhaps trying a different cafe next time :-) > >-- >Please don't Cc: me privately on mailing lists and Usenet, >if you also post the followup to the list or newsgroup. >Do obvious transformation on domain to reply privately _only_ on >Usenet. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.fine at gmail.com Mon Oct 16 18:09:52 2017 From: mark.fine at gmail.com (Mark Fine) Date: Mon, 16 Oct 2017 11:09:52 -0700 Subject: [Haskell-cafe] Network Connect Timeouts In-Reply-To: References: Message-ID: Hi Chris, Yeah, definitely looks like I can reconstitute *runTCPClient* with a wrapped *getSocketFamilyTCP* - messy, but should work. Thanks! Mark On Sat, Oct 14, 2017 at 5:17 PM, Chris Wong wrote: > Hi Mark, > > From reading the source code for *runTCPClient* [1], it looks like a thin > wrapper around *getSocketFamilyTCP* and *close*. > > It should be sufficient to copy that definition into your project and wrap > the *getSocketFamilyTCP* call in a *timeout*. You might need to import > *Data.Streaming.Network.Internal* to get access to the *AppData* > constructor. > > Hope this helps! > > [1] https://hackage.haskell.org/package/streaming-commons-0.1. > 18/docs/src/Data-Streaming-Network.html#runTCPClient > > On Sun, Oct 15, 2017 at 9:08 AM, Mark Fine wrote: > >> Hi Chris, >> >> In my application, I'm using *Data.Conduit.Network* from *conduit-extra* directly >> (*Data.Streaming.Network* from *streaming-commons* indirectly). The >> timeout I'm interested in managing is the connection establishment timeout >> - how long does the connect call wait to establish a connection. I haven't >> been able to figure out how to control this outside of applying a >> non-conditional timeout to the connect call (which is a timeout on the >> lifetime of a connection, not a timeout on the establishment of a >> connection). Thanks! >> >> Mark >> >> On Sat, Oct 14, 2017 at 3:09 AM, Chris Wong >> wrote: >> >>> Hi Mark, >>> >>> What networking library are you using? >>> >>> There should be a lower level interface which allows for managing the >>> lifetime of a connection by hand. >>> >>> Chris >>> >>> On Oct 14, 2017 15:17, "Mark Fine" wrote: >>> >>>> I'd like a configurable network connect timeout. Has anyone solved this >>>> reasonably? >>>> >>>> *System.Timeout.timeout* times out connections, but works on the >>>> granularity of the life of the connection. Is there a reasonable way to >>>> configure a timeout around just establishing the connection? Maybe >>>> something like a conditional timeout that enables an action to disable the >>>> timeout once it expires? >>>> >>>> As a workaround, I'm spinning trying to successfully connect first >>>> before trying to connect for real: >>>> >>>> -- | Try the TCP connection and see if you can connect... >>>> -- >>>> tryTCPClient :: Int -> ClientSettings -> IO () >>>> tryTCPClient microseconds settings = do >>>> ok <- newIORef False >>>> void $ timeout microseconds $ runTCPClient settings $ const $ >>>> writeIORef ok True >>>> ok' <- readIORef ok >>>> unless ok' $ >>>> tryTCPClient microseconds settings >>>> >>>> -- | Wrap runTCPClient with a connect timeout. >>>> -- >>>> -- Tries the TCP connection first, and the runs the regular >>>> runTCPClient. >>>> -- Of course, this only enforces a TCP connect timeout on the first >>>> connect. >>>> -- The second TCP connect has no timeout :( >>>> -- >>>> runTCPClient' :: Int -> ClientSettings -> (AppData -> IO a) -> IO a >>>> runTCPClient' microseconds settings action = do >>>> tryTCPClient microseconds settings >>>> runTCPClient settings action >>>> >>>> I've also tried running the *tryTCPClient* in its own thread >>>> concurrently with *runTCPClient* and throwing an exception if it can't >>>> connect in *microseconds*. None of these offer an actual true >>>> connection establishment timeout. >>>> >>>> Has anyone found a way to solve this? Thanks! >>>> >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >> > > > -- > Chris Wong (https://lambda.xyz) > > "I had not the vaguest idea what this meant and when I could not remember > the words, my tutor threw the book at my head, which did not stimulate my > intellect in any way." -- Bertrand Russell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Mon Oct 16 22:13:23 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 16 Oct 2017 18:13:23 -0400 Subject: [Haskell-cafe] Exposing a GADT-provided dictionary In-Reply-To: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> References: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> Message-ID: <3b6feaab-04fe-efca-6b20-8c201bb94bb9@vex.net> What is an example of how I would usually use withGADTDict? On 2017-10-15 07:07 PM, Kosyrev Serge wrote: > Good day, cafe! > > I found a way to expose a GADT-provided dictionary, but I don't quite > like it: > >> {-# LANGUAGE GADTs, RankNTypes #-} >> >> import Data.Function ((&)) >> >> class HasDict a where >> >> data GADT a where >> G1 :: HasDict a => a -> GADT a >> -- ... >> Gn :: HasDict a => a -> GADT a >> >> -- | Execute @body with the dictionary for HasDict extracted from the >> -- GADT. >> withGADTDict :: >> (forall b. (b ~ a, HasDict b) => GADT b -> c) -> GADT a -> c >> withGADTDict body x = x & case x of >> G1 _ -> body >> -- ... >> Gn _ -> body > > The problem is in withGADTDict's proportionality to the number of GADT's > clauses, as it is somewhat anti-modular. > > Is that the only light-weight option? I can imagine there is a way to > leverage generic programming, but that's a bit heavy.. > From serge.kosyrev at iohk.io Tue Oct 17 12:25:35 2017 From: serge.kosyrev at iohk.io (Kosyrev Serge) Date: Tue, 17 Oct 2017 15:25:35 +0300 Subject: [Haskell-cafe] Exposing a GADT-provided dictionary In-Reply-To: <894738d7-0892-2f36-cf2f-acfa4d092cb1@gmail.com> References: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> <894738d7-0892-2f36-cf2f-acfa4d092cb1@gmail.com> Message-ID: <7e7c129e-e800-b27b-606c-ba49c796d905@iohk.io> On 10/16/2017 02:56 PM, Li-yao Xia wrote: > > Would refactoring the type like this work for you? > >> data GADT a where >>   G :: HasDict a => Tag -> a -> GADT a >> >> data Tag = Tag1 | ... | Tagn >> >> withGADTDict :: ... >> withGADTDict body x = x & case x of >>   G _ _ -> body Li, thank you for your reply! I've needed the GADT clauses for their different structure, so I've had to add a layer of structural indirection to a plain ADT. But the spirit of your suggestion (to reduce the dict-providing GADT to a single clause) was all the same. -- с уважениeм / respectfully, Kosyrev Serge PGP Key ID: 3F62F118E38BED6D -- “Most deadly errors arise from obsolete assumptions.” -- Frank Herbert, Children of Dune From serge.kosyrev at iohk.io Tue Oct 17 12:56:05 2017 From: serge.kosyrev at iohk.io (Kosyrev Serge) Date: Tue, 17 Oct 2017 15:56:05 +0300 Subject: [Haskell-cafe] Exposing a GADT-provided dictionary In-Reply-To: <3b6feaab-04fe-efca-6b20-8c201bb94bb9@vex.net> References: <34f4ec3b-ee5f-1ce0-e7b8-bcb6597c6825@iohk.io> <3b6feaab-04fe-efca-6b20-8c201bb94bb9@vex.net> Message-ID: <9eb6ff76-297b-9223-66da-8e41ed11b419@iohk.io> On 10/17/2017 01:13 AM, Albert Y. C. Lai wrote: > What is an example of how I would usually use withGADTDict? The use case is accessing the dictionary in the context of a natural transformation, during a free applicative traversal [1]. I.e. given: > runAp_ :: Monoid m => (forall a. f a -> m) -> Ap f b -> m ..the 'GADT' type being the first argument for the 'Ap' type: > data GADT a where > G1 :: HasDict a => a -> GADT a > -- ... ..and the extraction function: > transform ∷ HasDict a => GADT a -> Result -- where 'Result' has a Monoid instance ..there needs to be a way to call 'transform' inside the natural transformation, the first argument of 'runAp_', which 'withGADTDict' neatly fits: > runAp_ (withGADTDict transform) someFreeAp -- 1. https://hackage.haskell.org/package/free-4.12.4/docs/Control-Applicative-Free.html#v:runAp_ -- с уважениeм / respectfully, Kosyrev Serge PGP Key ID: 3F62F118E38BED6D -- “Most deadly errors arise from obsolete assumptions.” -- Frank Herbert, Children of Dune From m at jaspervdj.be Tue Oct 17 16:53:49 2017 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Tue, 17 Oct 2017 18:53:49 +0200 Subject: [Haskell-cafe] [Announce] ZuriHac 2018 - 8-10 June in Zurich, Switzerland Message-ID: <20171017165349.GB2451@colony6.localdomain> It is our pleasure to announce that, like in previous years, ZuriHac will also take place in 2018 -- from Friday June 8th to Sunday the 10th. It will be hosted at the Hochschule Rapperswil right besides the beautiful lake Zurich, like last year. The Zurich Haskell Hackathon is a free (as in beer), international, grassroots collaborative coding festival whose goal is to expand the community and to build and improve Haskell libraries, tools, and infrastructure. This is already the 7th Haskell Hackathon in Zurich! This year, we will enjoy keynotes from: - Niki Vazou - Edward Kmett - Stephen Diehl More keynote speakers will be announced. This event is open to any experience level, from beginners to gurus. This year, Julie Moronuki, co-author of Haskell Programming from first principles [1], has kindly agreed to teach a beginners course in one of the classrooms we have available. Additionally, there will be mentors on site whom you can directly approach during the whole event with any Haskell-related question you have. This is a great opportunity to meet your fellow Haskellers in real life, find new contributors for your project, improve existing libraries and tools or even start new ones! We will have space for 300 attendees. Registration will open on 6th of December. You can find more information on our website [2]. We would also like to thank our sponsors Digital Asset [3] and HSR [4] for supporting this great event! Looking forward to see you there, the Zurich HaskellerZ meetup group [1]: https://www.goodreads.com/book/show/25587599-haskell-programming [2]: https://zurihac.info/ [3]: https://digitalasset.com/careers.html [4]: https://www.hsr.ch/ From karim.salah2048 at gmail.com Tue Oct 17 19:16:11 2017 From: karim.salah2048 at gmail.com (Karim Salah) Date: Tue, 17 Oct 2017 21:16:11 +0200 Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, November 2017 edition (33rd edition) Message-ID: Asteroids Name: Kareem salah (FCIH) status: stable, actively developed participants: mostafa hazem, khaled hesham, belal ibrahim ​ Asteroids is Haskell version of the known asteroids game which was developed with many programing languages as startup project the main aim of the game is to score the highest score by shooting the coming asteroids while avoiding them (just remember u have only three spaceships) the game is simulating the space physics so don't think it is so easy. the game following up the original game rules beside that we added a multi-player system to invite your friends to join your campaign. our team found it a good opportunity to develop a version using Haskell and by using the lazy programming techniques in our favor we were able to provide a stable fps a stable version of the game was released and it's free to download and play we are looking forward for active contributions in order to add versus system, rewarding system and progression system so, forward contributions related to code refinement or adding features is welcomed url : https://github.com/kareem2048/Asteroids -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot from 2017-10-17 20-28-33.png Type: image/png Size: 11725 bytes Desc: not available URL: From gershomb at gmail.com Wed Oct 18 07:11:34 2017 From: gershomb at gmail.com (Gershom B) Date: Wed, 18 Oct 2017 03:11:34 -0400 Subject: [Haskell-cafe] ANN: New Full Platform Build of Haskell Platform 8.2.1 for Mac In-Reply-To: References: Message-ID: New linux builds of the full platform are now posted as well, with the hashes on the website updated. --Gershom On Fri, Oct 6, 2017 at 2:14 AM, Gershom B wrote: > Thanks to some intrepid sleuthing by Albert Y. C. Lai, we realized > there was a serious problem in the full (not core) builds of HP for > Mac and Linux (not Windows). > > If you've seen lots of "unusable due to shadowed dependencies" errors > on packages that came with full 8.2.1 platform installs on those > systems, this is likely why. We should have tested better and caught > this, and I'm sorry for the trouble it has caused. > > I've released a new build of the full mac installer, and updated the > hash on the site. A new generic-linux build should follow soon. > > Regards, > Gershom > > P.s. For those interested, the technical details are at > https://github.com/haskell/haskell-platform/issues/285 -- in brief, > the platform had done builds using inplace conf files but deployed > using proper target package-conf files. This worked just fine until > the new abi-depends machinery was introduced for better computing > dependency mismatches (https://phabricator.haskell.org/D2846 is one > place to start reading about that). That new machinery then recognized > that different abis were generated for the inplace conf than the > target conf, and things went screwy. But the problem here isn't with > those changes -- it's with our inadequate testing that should have > caught when things went wrong and alerted us that we needed to step > back and fix things earlier, and the responsibility for that is all on > me. From c at functionx.org Wed Oct 18 15:59:58 2017 From: c at functionx.org (Christopher Lewis) Date: Wed, 18 Oct 2017 11:59:58 -0400 Subject: [Haskell-cafe] NYC Haskell Developer Position Message-ID: Karamaan Group, is an investment firm based in Manhattan. We are looking for an outstanding software developer to develop tools for financial analysis and knowledge management. Since we are investors and not traders, our focus is not on building trading systems, but on business and data analysis. We strongly value people who take pride in their work and have a craftsman’s dedication to building bespoke products. Our ideal candidate is an experienced software developer with a penchant for abstraction and analysis, a solid sense of organization, and an ability to communicate and persuade. While we are looking for a candidate who demonstrates an intense focus on quality, she also needs a master engineer’s intuition on how to make trade offs that are a necessary part of day-to-day software development. Candidates should have some formal training in a quantitative field and a keen interest in building robust and elegant software. This is a high-impact, high-visibility position where successful candidates will be entrusted with a lot of responsibility for products that have a direct effect on the P&L of the firm and influence on our workflow. The ideal candidate will have production experience with Haskell or another functional language, relational databases and relational data modeling, Python, and Java. Additionally, as this is a startup environment, the ideal candidate will be comfortable filling many different technology roles, and contributing to the success of the firm wherever they can, not just in agreement with their job description. Remote work is not an option for this position. Karamaan Group is an investment adviser and manager catering to family offices and institutional investors. We value innovative thinking, encourage an entrepreneurial atmosphere, and enjoy spirited discussions. Please send your CV and cover letter to recruitment at karamaan dot com. Please do not reply to the original poster. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Wed Oct 18 17:23:20 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Wed, 18 Oct 2017 22:53:20 +0530 Subject: [Haskell-cafe] Unused type-classes triggering a recompilation? Message-ID: Hi, We're trying to optimise the way lenses are built and imported in our project (there are 500+ of them!) . In the simplified version that I have presented below, whenever a new HasX class is added to the LensClasses module, both User & Main end up getting recompiled even though they have nothing to do with the newly added type-class. I've read and re-read "Recompilation Avoidance" [1], but haven't been able to figure out why this would be happening. PS: To work-around this issue we've had to give each HasX class an independent module of its own. We specifically import only those which are required (all of this is done via a code-gen tool). This has resulted in an explosion of modules and is probably causing slow-down of our build process [2] *LensClasses.hs:* {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} module LensClasses where import Control.Lens class HasName s a | s -> a where name :: Lens' s a class HasEmail s a | s -> a where email :: Lens' s a class HasAge s a | s -> a where age :: Lens' s a *User.hs (which defines a few lenses for the User record):* {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, TypeSynonymInstances, FlexibleInstances #-} module User ( module User , HasName(..) , HasEmail(..)) where import LensClasses(HasName(..), HasEmail(..), HasVariantName(..)) data User = User { _userName :: String , _userEmail :: String } deriving (Eq, Show) instance HasName User String where {-# INLINE name #-} name fctor (User name_ email_) = fmap (\dragon -> User dragon email_) (fctor name_) instance HasEmail User String where {-# INLINE email #-} email fctor (User name_ email_) = fmap (\dragon -> User name_ dragon) (fctor email_) *Main.hs (the final call site/s):* module Main where import Control.Lens import User main :: IO () main = do let u = User "saurabh" "saurabhnanda at gmail.com" putStrLn $ u ^. name [1] https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/RecompilationAvoidance [2] https://www.reddit.com/r/haskell/comments/76zljl/hotswapping_haskell_at_facebook_jon_coens/doi0s4q/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Oct 18 17:31:40 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 18 Oct 2017 13:31:40 -0400 Subject: [Haskell-cafe] Unused type-classes triggering a recompilation? In-Reply-To: References: Message-ID: On Wed, Oct 18, 2017 at 1:23 PM, Saurabh Nanda wrote: > We're trying to optimise the way lenses are built and imported in our > project (there are 500+ of them!) . In the simplified version that I have > presented below, whenever a new HasX class is added to the LensClasses > module, both User & Main end up getting recompiled even though they have > nothing to do with the newly added type-class. I've read and re-read > "Recompilation Avoidance" [1], but haven't been able to figure out why this > would be happening. > Because it is part of the external interface for dependencies of those modules and therefore triggers both an API change (which here has no effect) and an ABI change because internals of a module can leak out via .hi file exposure for cross-module inlining. There is no way to guard against that last, and avoiding it would usually be even more expensive than just treating the entire .hi as a dependency that changed (the dependency graph would *explode* if you had to track dependencies per possible inlining). And no, you do not want to defeat inlining, *especially* with lens. Performance will utterly tank. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Wed Oct 18 17:43:22 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Wed, 18 Oct 2017 23:13:22 +0530 Subject: [Haskell-cafe] Unused type-classes triggering a recompilation? In-Reply-To: References: Message-ID: > > Because it is part of the external interface for dependencies of those > modules and therefore triggers both an API change (which here has no > effect) and an ABI change because internals of a module can leak out via > .hi file exposure for cross-module inlining. There is no way to guard > against that last, and avoiding it would usually be even more expensive > than just treating the entire .hi as a dependency that changed (the > dependency graph would *explode* if you had to track dependencies per > possible inlining). > > And no, you do not want to defeat inlining, *especially* with lens. > Performance will utterly tank. > I probably have not understood what you're saying. In LensClasses.hs if I simply add a new HasAddress class without defining an instance anywhere in the app, it triggers a re-compile. Is this changing the API / ABI in any way? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Oct 18 17:55:04 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 18 Oct 2017 13:55:04 -0400 Subject: [Haskell-cafe] Unused type-classes triggering a recompilation? In-Reply-To: References: Message-ID: On Wed, Oct 18, 2017 at 1:43 PM, Saurabh Nanda wrote: > Because it is part of the external interface for dependencies of those >> modules and therefore triggers both an API change (which here has no >> effect) and an ABI change because internals of a module can leak out via >> .hi file exposure for cross-module inlining. There is no way to guard >> against that last, and avoiding it would usually be even more expensive >> than just treating the entire .hi as a dependency that changed (the >> dependency graph would *explode* if you had to track dependencies per >> possible inlining). >> >> And no, you do not want to defeat inlining, *especially* with lens. >> Performance will utterly tank. >> > > I probably have not understood what you're saying. In LensClasses.hs if I > simply add a new HasAddress class without defining an instance anywhere in > the app, it triggers a re-compile. Is this changing the API / ABI in any > way? > Yes, because when it is compiling the module containing that class, it can't know that some program years down the road won't define an instance for it, so it has to change the exposed interface. Beyond that, since we're limited to file-level dependency handling (because you can't recompile only the part of a source file that uses some dependency), compilers haven't much choice but to recompile more than is necessary --- which is why things work better when you split things into smaller files, but (as you also noted) now computing the dependency graph becomes the slow part because there are so many more dependencies to keep track of. I suspect what you really want is a whole-program compiler. ghc is designed for separate compilation, and this forces fundamental design choices in a different direction than whole-program compilation does. jhc was whole-program but development has halted and it was never complete enough to handle e.g. lens. This is not really ghc specific though, or haskell specific; show me any language or build system that can do dependency handling at a level smaller than a file. ghc does show it more clearly because of the cross-module inlining bit, because it means the dependency footprint is much larger than it looks --- but the performance without that inlining is abysmal. (Languages like Javascript *do* avoid it, by effectively generating all code 'on the fly' --- but that also imposes a fairly high overhead of its own; the larger a project gets, the more obvious that overhead is.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Wed Oct 18 18:19:31 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Wed, 18 Oct 2017 23:49:31 +0530 Subject: [Haskell-cafe] Unused type-classes triggering a recompilation? In-Reply-To: References: Message-ID: Thank you for explaining this. Unfortunately, this puts us between a rock and a hard place. If we don't break the project up into smaller modules, it keeps triggering a recompilation each time a record is added/edited (because the lenses change). If we break-up into smaller modules, the number of modules explode to ~500-700 thus causing a slowdown elsewhere in the compilation chain. -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Oct 18 19:14:46 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 18 Oct 2017 21:14:46 +0200 (CEST) Subject: [Haskell-cafe] =?utf-8?b?W0hhc2tlbGxdIEhhY2sg4oCcSW1wb3J0aWZ54oCd?= =?utf-8?q?_by_Serokell_During_=23Hacktoberfest!?= In-Reply-To: References: Message-ID: On Wed, 18 Oct 2017, Gints Dreimanis wrote: > All of us love to read explicit import lists (especially in an unknown > module), but we all hate to write and maintain them. You won't have many explicit import lists if you design the function names for qualified imports. From aditya.siram at gmail.com Wed Oct 18 23:14:27 2017 From: aditya.siram at gmail.com (aditya siram) Date: Wed, 18 Oct 2017 18:14:27 -0500 Subject: [Haskell-cafe] Stackage Haddocks extremely slow Message-ID: Hi all, I've noticed that lately Stackage's Haddock searches have been extremely slow; for example https://www.stackage.org/haddock/lts-9.9/base-4.9.1.0/Prelude.html#v:foldl took almost 8 seconds to pull up on my machine. Is anyone else seeing this? Thanks! -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Thu Oct 19 03:25:30 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Thu, 19 Oct 2017 08:55:30 +0530 Subject: [Haskell-cafe] Stackage Haddocks extremely slow In-Reply-To: References: Message-ID: I can confirm. Consistently slow. On 19-Oct-2017 4:46 AM, "aditya siram" wrote: > Hi all, > > I've noticed that lately Stackage's Haddock searches have been extremely > slow; for example https://www.stackage.org/haddock/lts-9.9/base-4.9.1.0/ > Prelude.html#v:foldl took almost 8 seconds to pull up on my machine. Is > anyone else seeing this? > > Thanks! > -deech > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Oct 19 06:46:20 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 19 Oct 2017 09:46:20 +0300 Subject: [Haskell-cafe] Stackage Haddocks extremely slow In-Reply-To: References: Message-ID: Thanks for the reports, likely connected to the move over to PostgreSQL recently. We'll look into it. On Thu, Oct 19, 2017 at 6:25 AM, Saurabh Nanda wrote: > I can confirm. Consistently slow. > > On 19-Oct-2017 4:46 AM, "aditya siram" wrote: > >> Hi all, >> >> I've noticed that lately Stackage's Haddock searches have been extremely >> slow; for example https://www.stackage.org/haddo >> ck/lts-9.9/base-4.9.1.0/Prelude.html#v:foldl took almost 8 seconds to >> pull up on my machine. Is anyone else seeing this? >> >> Thanks! >> -deech >> >> _______________________________________________ >> 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. >> > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Sun Oct 22 12:45:25 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Sun, 22 Oct 2017 12:45:25 +0000 Subject: [Haskell-cafe] Failing Travis CI Build Message-ID: <9f8b0e93-a468-e5a0-cb1e-08523be6a5c4@mixmax.com> Hi Everyone, I am trying to contribute to a smallHaskell project in order to break out of structured learning via books into some real-world code. Unfortunately, the pull request that I made (linked above) is failing the continuous integration check. You can see a partial log before. The entire logs can be found here. I thought that this would work because: 1. We are using the 8.20 resolver in our project. 2. The 8.20 resolver includes QuickCheck, hspec, and quickcheck-instances. 3. The dependencies are listed in the cabal file. Am I missing something obvious? Is the above not the way it works? Thank you for any help. Logs Reading available packages...Choosing modular solver.Resolving dependencies...Could not resolve dependencies:trying: twilio-0.2.0.0 (user goal)rejecting: twilio-0.2.0.0:!test (global constraint requires opposite flagselection)trying: twilio-0.2.0.0:*testnext goal: quickcheck-instances (dependency of twilio-0.2.0.0:*test)fail (unknown package: quickcheck-instances)Dependency tree exhaustively searched.Configuring twilio-0.2.0.0...cabal: At least the following dependencies are missing:QuickCheck ==2.*, hspec ==2.*, quickcheck-instances -any Not using Mixmax yet? Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sun Oct 22 15:22:11 2017 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sun, 22 Oct 2017 17:22:11 +0200 Subject: [Haskell-cafe] Failing Travis CI Build In-Reply-To: <9f8b0e93-a468-e5a0-cb1e-08523be6a5c4@mixmax.com> References: <9f8b0e93-a468-e5a0-cb1e-08523be6a5c4@mixmax.com> Message-ID: Hi Steven I guess you should add `--enable-tests --enable-benchmarks` to the `cabal install --dependencies-only` call, so that you install dependencies for the exact setup that you want to build. Cheers, Mikolaj On Sun, Oct 22, 2017 at 2:45 PM, Steven Leiva wrote: > Hi Everyone, > > I am trying to contribute to a small Haskell project > in order to break > out of structured learning via books into some real-world code. > > Unfortunately, the pull request that I made (linked above) is failing the > continuous integration check. You can see a partial log before. The entire > logs can be found here > > . > > I thought that this would work because: > > > 1. We are using the 8.20 resolver in our project. > 2. The 8.20 resolver includes QuickCheck, hspec, and > quickcheck-instances. > 3. The dependencies are listed in the cabal file. > > Am I missing something obvious? Is the above not the way it works? > > Thank you for any help. > > > > > Logs > > Reading available packages... > Choosing modular solver. > Resolving dependencies... > Could not resolve dependencies: > trying: twilio-0.2.0.0 (user goal) > rejecting: twilio-0.2.0.0:!test (global constraint requires opposite flag > selection) > trying: twilio-0.2.0.0:*test > next goal: quickcheck-instances (dependency of twilio-0.2.0.0:*test) > fail (unknown package: quickcheck-instances) > Dependency tree exhaustively searched. > Configuring twilio-0.2.0.0... > cabal: At least the following dependencies are missing: > QuickCheck ==2.*, hspec ==2.*, quickcheck-instances -any > > [image: Mixmax] > Not using Mixmax yet? > > > > Steven Leiva > 305.528.6038 > leiva.steven at gmail.com > http://www.linkedin.com/in/stevenleiva > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Sun Oct 22 21:30:26 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Sun, 22 Oct 2017 17:30:26 -0400 Subject: [Haskell-cafe] Failing Travis CI Build In-Reply-To: References: <9f8b0e93-a468-e5a0-cb1e-08523be6a5c4@mixmax.com> Message-ID: Hello Mikolaj, I've been scratching my head over this for a few days. You're suggestion fixed it. Thank you very much. -Steven On Oct 22, 2017 11:22 AM, "Mikolaj Konarski" wrote: > Hi Steven > > I guess you should add `--enable-tests --enable-benchmarks` > to the `cabal install --dependencies-only` call, > so that you install dependencies for the exact > setup that you want to build. > > Cheers, > Mikolaj > > > On Sun, Oct 22, 2017 at 2:45 PM, Steven Leiva > wrote: > >> Hi Everyone, >> >> I am trying to contribute to a small Haskell project >> in order to break >> out of structured learning via books into some real-world code. >> >> Unfortunately, the pull request that I made (linked above) is failing the >> continuous integration check. You can see a partial log before. The entire >> logs can be found here >> >> . >> >> I thought that this would work because: >> >> >> 1. We are using the 8.20 resolver in our project. >> 2. The 8.20 resolver includes QuickCheck, hspec, and >> quickcheck-instances. >> 3. The dependencies are listed in the cabal file. >> >> Am I missing something obvious? Is the above not the way it works? >> >> Thank you for any help. >> >> >> >> >> Logs >> >> Reading available packages... >> Choosing modular solver. >> Resolving dependencies... >> Could not resolve dependencies: >> trying: twilio-0.2.0.0 (user goal) >> rejecting: twilio-0.2.0.0:!test (global constraint requires opposite flag >> selection) >> trying: twilio-0.2.0.0:*test >> next goal: quickcheck-instances (dependency of twilio-0.2.0.0:*test) >> fail (unknown package: quickcheck-instances) >> Dependency tree exhaustively searched. >> Configuring twilio-0.2.0.0... >> cabal: At least the following dependencies are missing: >> QuickCheck ==2.*, hspec ==2.*, quickcheck-instances -any >> >> [image: Mixmax] >> Not using Mixmax yet? >> >> >> >> Steven Leiva >> 305.528.6038 <(305)%20528-6038> >> leiva.steven at gmail.com >> http://www.linkedin.com/in/stevenleiva >> >> _______________________________________________ >> 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. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikolaj at well-typed.com Sun Oct 22 21:58:43 2017 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Sun, 22 Oct 2017 23:58:43 +0200 Subject: [Haskell-cafe] Failing Travis CI Build In-Reply-To: References: <9f8b0e93-a468-e5a0-cb1e-08523be6a5c4@mixmax.com> Message-ID: > > I've been scratching my head over this for a few days. You're suggestion > fixed it. Thank you very much. > You are welcome. Good luck with your contributions. That's a very good form of learning, indeed. Cheers, Mikolaj > On Oct 22, 2017 11:22 AM, "Mikolaj Konarski" > wrote: > >> Hi Steven >> >> I guess you should add `--enable-tests --enable-benchmarks` >> to the `cabal install --dependencies-only` call, >> so that you install dependencies for the exact >> setup that you want to build. >> >> Cheers, >> Mikolaj >> >> >> On Sun, Oct 22, 2017 at 2:45 PM, Steven Leiva >> wrote: >> >>> Hi Everyone, >>> >>> I am trying to contribute to a small Haskell project >>> in order to >>> break out of structured learning via books into some real-world code. >>> >>> Unfortunately, the pull request that I made (linked above) is failing >>> the continuous integration check. You can see a partial log before. The >>> entire logs can be found here >>> >>> . >>> >>> I thought that this would work because: >>> >>> >>> 1. We are using the 8.20 resolver in our project. >>> 2. The 8.20 resolver includes QuickCheck, hspec, and >>> quickcheck-instances. >>> 3. The dependencies are listed in the cabal file. >>> >>> Am I missing something obvious? Is the above not the way it works? >>> >>> Thank you for any help. >>> >>> >>> >>> >>> Logs >>> >>> Reading available packages... >>> Choosing modular solver. >>> Resolving dependencies... >>> Could not resolve dependencies: >>> trying: twilio-0.2.0.0 (user goal) >>> rejecting: twilio-0.2.0.0:!test (global constraint requires opposite flag >>> selection) >>> trying: twilio-0.2.0.0:*test >>> next goal: quickcheck-instances (dependency of twilio-0.2.0.0:*test) >>> fail (unknown package: quickcheck-instances) >>> Dependency tree exhaustively searched. >>> Configuring twilio-0.2.0.0... >>> cabal: At least the following dependencies are missing: >>> QuickCheck ==2.*, hspec ==2.*, quickcheck-instances -any >>> >>> [image: Mixmax] >>> Not using Mixmax yet? >>> >>> >>> >>> Steven Leiva >>> 305.528.6038 <(305)%20528-6038> >>> leiva.steven at gmail.com >>> http://www.linkedin.com/in/stevenleiva >>> >>> _______________________________________________ >>> 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. >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Mon Oct 23 08:20:30 2017 From: benl at ouroborus.net (Ben Lippmeier) Date: Mon, 23 Oct 2017 19:20:30 +1100 Subject: [Haskell-cafe] [ANN] The Disciplined Disciple Compiler (DDC) v0.5.1 Message-ID: <5E5879FE-180A-4605-B353-C71C92BD66E6@ouroborus.net> # The Disciplined Disciple Compiler (DDC) v.0.5.1 The Disciple language is an experimental dialect of Haskell which investigates static typing and program transformation in the presence of computational effects. Version 0.5.1 is “working alpha” quality, meaning there is a complete system that can be hacked around with, but it’s not yet industrial strength. Homepage: http://disciple.ouroborus.net/ Github: https://github.com/DDCSF/ddc ## Features: * Haskell-like source language, so Haskell-like programs should work with minor modifications. * Modal region and effect system using ‘box’ and ‘run’ to suspend and force computations. * Higher rank polymorphism with bidirectional type inference. * Simple two space copying garbage collection. * Default call-by-value evaluation. * Typed external core language. ## New in This Release: * Copying garbage collection. We now do simple two space Cheney-scan garbage collection, and grow the heap as needed. We use LLVM shadow stack support to retrieve the GC roots. * Implicit parameters. We now support Agda-style implicit parameters, where arguments are construct at use-sites using whatever bindings are currently in scope. For example, we can perform Haskell-style ad-hoc overloading using implicit dictionaries: elem {Eq a} (k: a) (xx: List a): Bool = case xx of Nil -> False Cons x xs | x == k -> True | otherwise -> elem k xs * Floating point primitives. The addition of floating point primitives combined with proper storage management now lets us write more realistic example programs, like the ray tracer demo, which was also described on the blog [1]. * Travis continuous integration. Every push to the GitHub repo now gets tested by the Travis buildbot [2]. Branches can also be tested individually before being merged. * Support for LLVM versions 3.1 - 5.0 We query the version of the installed LLVM compiler and generate LLVM code with the required syntax. This process now works for versions 3.1 through to 5.0, which is the latest at the time of this release. * New home page with the start of a language specification. The home page now consists of the user manual generated from Sphinx / Restructured Text source. The manual includes grammars for source and core lanuages, as well as previous release notes. The bug tracker is still accessible via the development wiki. * Bug fixes for offside rule, compilation of nested pattern matching, string escapes, unsolved meta variables. Now with more bake. [1] http://disciple-devel.blogspot.com.au/2017/07/ray-tracer-demo.html [2] https://travis-ci.org/DDCSF/ddc [3] http://disciple.ouroborus.net/ ## Work In Progress We are moving to a new indexed binary format for interface files, as re-parsing interface files is currently a bottleneck. The file format is to be provided by the Shimmer project [4], which has been split out into a separate repository. [4] https://github.com/DDCSF/shimmer ## People The following people contributed to DDC since the last release: * Chris Hall - Travis continuous integration. * Amos Robinson - Build system fixes, start on machine fusion transform. * Ben Sinclair - Build system fixes. * Jacob Stanley - Copying garbage collection. * Ben Lippmeier - Copying garbage collection, implicit parameters, floating point, new home page. ## Previous Releases * 2016/09 DDC 0.4.3: Nested patterns and guards, simple type synonyms. * 2016/04 DDC 0.4.2: Compilation of higher order functions, run and box casts. * 2014/03 DDC 0.4.1: Added bi-directional type inference and region extension. * 2013/07 DDC 0.3.2: Added Tetra and Flow language fragments. ## More Information Home Page: http://disciple.ouroborus.net The GitHub site: http://github.com/DDCSF/ddc Development Wiki: http://trac.ouroborus.net/ddc Development Blog: http://disciple-devel.blogspot.com.au/ Mailing List: http://groups.google.com/group/disciple-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Mon Oct 23 08:49:24 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 23 Oct 2017 10:49:24 +0200 Subject: [Haskell-cafe] [ANN] Haskell ITA meetup in Rome, Italy (2017-11-18) Message-ID: <20171023084924.wrbzs247ycbig6xf@x60s.casa> Dear -cafe, the Italian Haskell Community (http://haskell-ita.it/) is happy to announce its autumn Haskell meetup! The event is going to be hosted in Rome, on November 18th. The meeting will be in Italian; we are going to form small groups/projects, to see Haskell in action and to share knowledge and opinions on functional programming. Everyone, experienced or not, is welcome, just make sure to have a laptop and a working Haskell environment! For a more detailed description of the event and to register, check: https://www.eventbrite.it/e/biglietti-haskell-day-roma-aperitech-38962491862 From fw at deneb.enyo.de Mon Oct 23 21:49:46 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 23 Oct 2017 23:49:46 +0200 Subject: [Haskell-cafe] Why is Haskell so slow (comparing to Java/Scala)? In-Reply-To: (=?utf-8?B?ItCh0YLQsNC90LjRgdC70LDQsiDQp9C10YDQvdC40YfQutC40L0iJ3M=?= message of "Wed, 20 Sep 2017 17:27:54 +0300") References: Message-ID: <8760b5ttz9.fsf@mid.deneb.enyo.de> * Станислав Черничкин: > I wrote similar program in Scala: > > for (_ <- 1 to 5) { > val start = System.currentTimeMillis() > val a = new Array[Long](1000000) > for (i <- 0 until 1000000) { > a(i) = 1L > } > val end = System.currentTimeMillis() > println(s"${end - start} ms") > } > > I skip neither boundary checks nor memory initialization, I also used > generic array here (suitable for any types of objects, not just for > primitive types), so I expected longer run time. But what I got was > shocking: > > 7 ms > 3 ms > 2 ms > 1 ms > 2 ms > > This program runs 20-40 times faster than Haskell after warm-up. 20-40 > times, Carl! Why is Haskell soo slooooow? How can it be? It is possible that Hotspot optimizes away most of the code, perhaps even the entire array allocation. Meaningful benchmarking is quite difficult due to such effects. Does the execution time even change if you increase the number of iterations (inner or outer)? From sumitraja at gmail.com Mon Oct 23 23:08:15 2017 From: sumitraja at gmail.com (Sumit Raja) Date: Tue, 24 Oct 2017 10:08:15 +1100 Subject: [Haskell-cafe] Fwd: Safe TCP accept loop In-Reply-To: <59e4995b.0947620a.72c1d.9b14@mx.google.com> References: <59e4995b.0947620a.72c1d.9b14@mx.google.com> Message-ID: Hi, I sent this to beginners but got no responses so I'm hoping someone here can help. I’ve looked at https://wiki.haskell.org/Concurrency_demos/Graceful_exit and used(2) Using throwTo without the use of block and unblock. It runs on 8.2.1 with my limited testing. I can’t find out much about what the > 7.x GHC replacement for block/unblock is other than mask. What does the unblock do in acceptConnections'? Does this method of handling an accept loop still need masking of async exceptions ? If so where does this need to be done? I've got a version with async running for my specific application (https://bitbucket.org/sumitraja/hvrr/src/6927216597a35a9a0d7f2e55cca83fa5b7279ee0/hvrr-comms/src/Network/VRR/Server/TCP/TCPAcceptLoop.hs) but I don't know if I need to unmask at any point so was hoping for some guidance. Thanks Sumit From jo at durchholz.org Mon Oct 23 23:09:56 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 24 Oct 2017 01:09:56 +0200 Subject: [Haskell-cafe] Why is Haskell so slow (comparing to Java/Scala)? In-Reply-To: <8760b5ttz9.fsf@mid.deneb.enyo.de> References: <8760b5ttz9.fsf@mid.deneb.enyo.de> Message-ID: <962d16f5-6143-cb2e-c4ba-024bb7ec081e@durchholz.org> Am 23.10.2017 um 23:49 schrieb Florian Weimer: > It is possible that Hotspot optimizes away most of the code, perhaps > even the entire array allocation. Meaningful benchmarking is quite > difficult due to such effects. > > Does the execution time even change if you increase the number of > iterations (inner or outer)? I tried that in Java, with this code: private static final int SIZE = 400_0000; private static final int ITERATIONS = 20; public static void main(String[] args) { for (int i = 1; i < ITERATIONS; i++) { long start = System.currentTimeMillis(); Long [] a = new Long[SIZE]; for (int j = 0; j < SIZE; j++) { a[j] = 1L; } long end = System.currentTimeMillis(); System.out.println((end - start) + " ms"); } } Fiddling with SIZE and ITERATIONS led me to the following conclusions: 1) The first two iterations are warm-up, afterwards the times are pretty constant (about 7-8 ms for SIZE=100_000). 2) Cranking ITERATIONS up gave semi-regular slow iterations. I blame GC. 3) Per-loop run time seems to be roughly linear with array size, that's a strong indicator that the assignments are not optimized away. (In fact having a running time of 1-2 ms is a strong indicator that the software is in fact blowing some real CPU cycles.) It is actually possible that the standard HotSpot JVM is faster than Haskell, for this type of task - i.e. just array manipulation with primitive values, and working set size small enough to make GC irrelevant. It's the kind of workload where HotSpot has all the information needed to fully optimize everything short of eliminating the loop altogether (which is usually not worth it for a mutable-language just-in-time compiler). Make things a bit more complicated and real-world, and this advantage will shrink considerably: Throw in a few classes, subclasses that override functions (Haskell equivalent would be unevaluated expressions in the list), iterate over a list instead of an array (which will actually make the Haskell program faster if the list spine can be optimized away), that kind of stuff. That said, HotSpot is a pretty tough opponent to beat. It has person-decates if not person-centuries of optimization under its belt after all. So does GHC, so maybe the comparison isn't so unfair after all, but saying "Haskell is slow" from a single microbenchmark simply does not hold any value. Still, it is possible that the JVM is indeed faster for some kinds of workload. If that workload is actually relevant, it might be a valid optimization potential. Just my 2 cents :-) Regards, Jo From omeragacan at gmail.com Tue Oct 24 05:43:24 2017 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 24 Oct 2017 08:43:24 +0300 Subject: [Haskell-cafe] Fwd: Safe TCP accept loop In-Reply-To: References: <59e4995b.0947620a.72c1d.9b14@mx.google.com> Message-ID: Hi Sumit, > Does this method of handling an accept loop still need masking of async > exceptions You need to mask async exceptions between `accept()` and cleanup action registration, because an exception in between these operations will cause the socket to leak. You can take a look at warp's accept loop: https://github.com/yesodweb/wai/blob/master/warp/Network/Wai/Handler/Warp/Run.hs#L211 Hope this helps, Ömer 2017-10-24 2:08 GMT+03:00 Sumit Raja : > Hi, > > I sent this to beginners but got no responses so I'm hoping someone > here can help. I’ve looked at > https://wiki.haskell.org/Concurrency_demos/Graceful_exit and used(2) > Using throwTo without the use of block and unblock. It runs on 8.2.1 > with my limited testing. I can’t find out much about what the > 7.x > GHC replacement for block/unblock is other than mask. What does the > unblock do in acceptConnections'? > > Does this method of handling an accept loop still need masking of > async exceptions ? If so where does this need to be done? > > I've got a version with async running for my specific application > (https://bitbucket.org/sumitraja/hvrr/src/6927216597a35a9a0d7f2e55cca83fa5b7279ee0/hvrr-comms/src/Network/VRR/Server/TCP/TCPAcceptLoop.hs) > but I don't know if I need to unmask at any point so was hoping for > some guidance. > > > Thanks > > > > Sumit > _______________________________________________ > 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. From mail at stefanwehr.de Tue Oct 24 08:16:29 2017 From: mail at stefanwehr.de (Stefan Wehr) Date: Tue, 24 Oct 2017 10:16:29 +0200 Subject: [Haskell-cafe] [ANN] Call for Contributions: BOB 2018 - Berlin, Feb 23, 2018 Message-ID: Call for Contributions BOB Conference 2018 "What happens when we use what's best for a change?" http://bobkonf.de/2018/en/cfp.html Berlin, February 23 Deadline: October 29, 2017 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We’re especially interested in experience reports. But this could also take other forms, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - an abstract of max. 1500 characters. - a short bio/cv - contact information (including at least email address) - a list of 3-5 concrete ideas of how your work can be applied in a developer’s daily life - additional material (websites, blogs, slides, videos of past presentations, ...) Submit here: https://docs.google.com/forms/d/e/1FAIpQLSdjgwulSMpaITJ6q6cK_ndrfR1FlEs_HQlZy04LnUKC-ArCaQ/viewform?usp=sf_link Organisation - direct questions to contact at bobkonf dot de - proposal deadline: October 29, 2017 - notification: November 13, 2017 - program: December 1, 2017 NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Details are here: http://bobkonf.de/2018/en/speaker-grants.html Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Program Committee ----------------- (more information here: http://bobkonf.de/2018/en/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg From jeroen at chordify.net Tue Oct 24 09:33:24 2017 From: jeroen at chordify.net (Jeroen Bransen) Date: Tue, 24 Oct 2017 11:33:24 +0200 Subject: [Haskell-cafe] Haskell CI with many repositories/packages Message-ID: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Hi cafe, Does anyone know of a good setup for doing continuous integration with a set of Haskell packages, each in its own repository? Just building everything upon every commit is not so hard, but to speed up building times I'd like to build and test only the minimal set of packages. In particular, at a commit for some package A, I would like to build and test A and all packages that depend on A. The problem is that most CI tools use some notion of 'build artefact', which Stack doesn't really seem to give me. Ideally building a package results in some object file, which can then be used by the other packages. When building failed, packages that depend on it can still use the last succesful build. I've tried to look up some Haskell projects, but most of them seem to use some ad hoc setup. Some pointers are appreciated, as we are using Gitlab a gitlab-runner specific option would be great, but I am also open to use Jenkins or other tools. And I guess my main struggle now is on the stack/Haskell side. Regards, Jeroen Bransen From adam at bergmark.nl Tue Oct 24 14:39:56 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 24 Oct 2017 14:39:56 +0000 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: I haven't felt the need to share build artifacts like this. Instead, e.g., if you cache your `.stack-work` and your master project does a git clone of sub projects and you put those paths in your stack.yaml then `stack build` should only rebuild the changes. You may be able to share parts of `.stack-work` as well but I haven't looked into that. HTH, Adam On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen wrote: > Hi cafe, > > Does anyone know of a good setup for doing continuous integration with a > set of Haskell packages, each in its own repository? Just building > everything upon every commit is not so hard, but to speed up building > times I'd like to build and test only the minimal set of packages. In > particular, at a commit for some package A, I would like to build and > test A and all packages that depend on A. > > The problem is that most CI tools use some notion of 'build artefact', > which Stack doesn't really seem to give me. Ideally building a package > results in some object file, which can then be used by the other > packages. When building failed, packages that depend on it can still use > the last succesful build. I've tried to look up some Haskell projects, > but most of them seem to use some ad hoc setup. > > Some pointers are appreciated, as we are using Gitlab a gitlab-runner > specific option would be great, but I am also open to use Jenkins or > other tools. And I guess my main struggle now is on the stack/Haskell side. > > Regards, > Jeroen Bransen > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Tue Oct 24 20:43:48 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 24 Oct 2017 21:43:48 +0100 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: It sounds like using Hydra (the Nix based CI system) would be suitable for your needs. The essential work flow would be to create a package set which contained all your packages and then create a job set which built that package set. What's more, if your developers are also using nix then it is trivial to setup a build cache which serves prebuilt packages to them. The manual provides a concise introduction - https://nixos.org/hydra/ Matt On Tue, Oct 24, 2017 at 10:33 AM, Jeroen Bransen wrote: > Hi cafe, > > Does anyone know of a good setup for doing continuous integration with a set > of Haskell packages, each in its own repository? Just building everything > upon every commit is not so hard, but to speed up building times I'd like to > build and test only the minimal set of packages. In particular, at a commit > for some package A, I would like to build and test A and all packages that > depend on A. > > The problem is that most CI tools use some notion of 'build artefact', which > Stack doesn't really seem to give me. Ideally building a package results in > some object file, which can then be used by the other packages. When > building failed, packages that depend on it can still use the last succesful > build. I've tried to look up some Haskell projects, but most of them seem to > use some ad hoc setup. > > Some pointers are appreciated, as we are using Gitlab a gitlab-runner > specific option would be great, but I am also open to use Jenkins or other > tools. And I guess my main struggle now is on the stack/Haskell side. > > Regards, > Jeroen Bransen > _______________________________________________ > 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. From alexander.kjeldaas at gmail.com Tue Oct 24 21:30:20 2017 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Tue, 24 Oct 2017 23:30:20 +0200 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: The following might count as a trick. It checks that all .stack-work directories are mentioned in the .gitlab-ci.yml file. A nicer approach than the ugly grep is to use jq-on-yaml, but this works for me. The goal is just to fail CI if a new module is added without caching it. # Check that all stack work directories are cached - diff -u <( find . -name .stack-work | grep -v '.stack-work.*.stack-work' | grep -v '.stack/' | grep -v node_modules | cut -c3- | sort) <( grep .stack-work .gitlab-ci.yml | egrep -v 'find .|for a|rm -rf|^\s*#.*|grep' | tr -d '"' | awk '{print $2}' | cut -d/ -f5- | sort) Alexander On Tue, Oct 24, 2017 at 10:43 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > It sounds like using Hydra (the Nix based CI system) would be suitable > for your needs. > > The essential work flow would be to create a package set which > contained all your packages and then create a job set which built that > package set. > > What's more, if your developers are also using nix then it is trivial > to setup a build cache which serves prebuilt packages to them. > > The manual provides a concise introduction - https://nixos.org/hydra/ > > Matt > > On Tue, Oct 24, 2017 at 10:33 AM, Jeroen Bransen > wrote: > > Hi cafe, > > > > Does anyone know of a good setup for doing continuous integration with a > set > > of Haskell packages, each in its own repository? Just building everything > > upon every commit is not so hard, but to speed up building times I'd > like to > > build and test only the minimal set of packages. In particular, at a > commit > > for some package A, I would like to build and test A and all packages > that > > depend on A. > > > > The problem is that most CI tools use some notion of 'build artefact', > which > > Stack doesn't really seem to give me. Ideally building a package results > in > > some object file, which can then be used by the other packages. When > > building failed, packages that depend on it can still use the last > succesful > > build. I've tried to look up some Haskell projects, but most of them > seem to > > use some ad hoc setup. > > > > Some pointers are appreciated, as we are using Gitlab a gitlab-runner > > specific option would be great, but I am also open to use Jenkins or > other > > tools. And I guess my main struggle now is on the stack/Haskell side. > > > > Regards, > > Jeroen Bransen > > _______________________________________________ > > 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. > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.waksbaum at gmail.com Tue Oct 24 22:43:47 2017 From: jake.waksbaum at gmail.com (Jake Waksbaum) Date: Tue, 24 Oct 2017 18:43:47 -0400 Subject: [Haskell-cafe] Automatically using boxed or unboxed vectors Message-ID: <96E2A5A4-0225-4D47-9416-316412D27D73@gmail.com> I am trying to create a data type that is an vector of values, but internally uses an unboxed vector when possible and a boxed array otherwise. If this already exists, let me know. For example, any easily unboxed type is stored in an unboxed array, but also any type that is a product type of only easily unboxed types like (Int, Int) is stored in multiple unboxed arrays. I don’t think there is a smart way of doing this for sum types, so those are stored in boxed arrays. I’m trying to create a typeclass class VectorElement a where data Vector a replicate :: Int -> a -> Vector a length :: Vector a -> Int to represent things that can be stored in Vectors. I can then implement it for specific types that I know can be stored in unboxed vectors: instance VectorElement Int where newtype Vector Int = VectorInt (U.Vector Int) deriving Show replicate len x = VectorInt $ U.replicate len x length (VectorInt v) = U.length v I also want to automatically derive instances of this class for other types using the Generic typeclass. Ideally these instances would be the most efficient possible, so that for example the instance for (Int, Int) used two unboxed arrays but the instance for Maybe Int uses a boxed array. To that end I created another typeclass and wrote instances for the Generic data constructors: class VectorElementG (r :: * -> *) where data VectorG r replicateG :: Int -> r a -> VectorG r lengthG :: VectorG r -> Int instance VectorElementG V1 where data VectorG V1 replicateG = undefined lengthG = undefined instance VectorElementG U1 where newtype VectorG U1 = VectorGUnit Int replicateG i U1 = VectorGUnit i lengthG (VectorGUnit i) = i instance VectorElement a => VectorElementG (K1 i a) where newtype VectorG (K1 i a) = VectorGK (Vector a) replicateG i (K1 x) = VectorGK $ replicate i x lengthG (VectorGK v) = length v instance (VectorElementG r1, VectorElementG r2) => VectorElementG (r1 :*: r2) where data VectorG (r1 :*: r2) = VectorGProd (VectorG r1) (VectorG r2) replicateG i (a :*: b) = VectorGProd (replicateG i a) (replicateG i b) lengthG (VectorGProd v _) = lengthG v instance VectorElement ((r1 :+: r2) p) where newtype Vector ((r1 :+: r2) p) = VectorSum (V.Vector ((r1 :+: r2) p)) replicate i x = VectorSum $ V.replicate i x length (VectorSum v) = V.length v instance VectorElementG f => VectorElementG (M1 i c f) where newtype VectorG (M1 i c f) = VectorGMeta (VectorG f) replicateG i (M1 f) = VectorGMeta $ replicateG i f lengthG (VectorGMeta v) = lengthG v I’m not sure if these are correct, especially the one for :+:. I want basically base cases to be any type that already has an instance of VectorElement or a sum type which is automatically boxed, and the recursive case to basically just use parallel vectors for product types. I think this sort of worked insofar as it allowed me to write an instance for tuples: instance (VectorElement a, VectorElement b) => VectorElement (a,b) where newtype Vector (a, b) = VectorTuple (VectorG (Rep (a, b))) replicate i x = VectorTuple $ replicateG i (from x) length (VectorTuple v) = lengthG v Ideally, however, the compiler would automatically derive this instance using the Generic instance. Is there a way to do that also? I would welcome any thoughts on this entire idea and approach. Thanks, Jake Waksbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumitraja at gmail.com Wed Oct 25 05:52:33 2017 From: sumitraja at gmail.com (Sumit Raja) Date: Wed, 25 Oct 2017 16:52:33 +1100 Subject: [Haskell-cafe] Fwd: Safe TCP accept loop In-Reply-To: References: <59e4995b.0947620a.72c1d.9b14@mx.google.com> Message-ID: Hi Ömer > You need to mask async exceptions between `accept()` and cleanup action > registration, because an exception in between these operations will cause the > socket to leak. > > You can take a look at warp's accept loop: > > https://github.com/yesodweb/wai/blob/master/warp/Network/Wai/Handler/Warp/Run.hs#L211 > Trying to map steps for the code you've pointed me to in bad pseudo code: finally (mask >> acceptLoop serverSocket) (close serverSocket) acceptLoop = unmask sock <- accept serverSock mask forkIO $ do mask finally (unmask >> process sock) (close sock) acceptLoop Is this correct? Thanks Sumit From omeragacan at gmail.com Wed Oct 25 06:30:03 2017 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Wed, 25 Oct 2017 09:30:03 +0300 Subject: [Haskell-cafe] Fwd: Safe TCP accept loop In-Reply-To: References: <59e4995b.0947620a.72c1d.9b14@mx.google.com> Message-ID: Your pseudo code doesn't look right although I couldn't completely understand it. You need something like this: {-# LANGUAGE ScopedTypeVariables #-} import Network.Socket import Control.Concurrent import Control.Exception acceptLoop :: Socket -> IO () acceptLoop sock = mask_ loop where loop = do -- only safe point in the loop for exceptions allowInterrupt (connected_sock, _) <- accept sock -- use forkIOWithUnmask: we want the thread to be interruptable no matter -- what the inherited masking state is _thr_id <- forkIOWithUnmask (handle_conn connected_sock) loop handle_conn connected_sock unmask = -- register cleanup action, run the handler in interruptable state to be -- able to kill the thread. catch (unmask (handler connected_sock)) (\(_exc :: SomeException) -> close connected_sock) handler connected_sock = -- fill here return () Ömer 2017-10-25 8:52 GMT+03:00 Sumit Raja : > Hi Ömer > >> You need to mask async exceptions between `accept()` and cleanup action >> registration, because an exception in between these operations will cause the >> socket to leak. >> >> You can take a look at warp's accept loop: >> >> https://github.com/yesodweb/wai/blob/master/warp/Network/Wai/Handler/Warp/Run.hs#L211 >> > > Trying to map steps for the code you've pointed me to in bad pseudo code: > > finally (mask >> acceptLoop serverSocket) (close serverSocket) > > acceptLoop = > unmask > sock <- accept serverSock > mask > forkIO $ do > mask > finally (unmask >> process sock) (close sock) > acceptLoop > > Is this correct? > > Thanks > Sumit From alan.zimm at gmail.com Wed Oct 25 11:47:52 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 25 Oct 2017 13:47:52 +0200 Subject: [Haskell-cafe] Call for Haskell.org Committee Nominations Message-ID: Dear Haskellers, It is time to put out a call for new nominations (typically but not necessarily self-nominations) to the haskell.org committee. We have three members of our committee due for retirement -- Ryan Trinkle, John Wiegley and Alan Zimmerman. To nominate yourself, please send an email to committee at haskell.org by December 1, 2017. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. The Haskell.org committee serves as a board of directors for Haskell.org, a 501(c)3 nonprofit which oversees technical and financial resources related to Haskell community infrastructure. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The role is about setting policy, providing direction/guidance for Haskell.org infrastructure, planning for the long term, and being fiscally responsible with the Haskell.org funds (and donations). As overseers for policy regarding the open source side of Haskell, committee members must also be able to set aside personal or business related bias and make decisions with the good of the open source Haskell community in mind. We seek a broad representation from different segments of the Haskell world -- including but not limited to those focused on education, those focused on industrial applications, those with background in organizing users-groups, and those focused directly on our technical infrastructure. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org, or contact one of us individually. Regards, Alan Zimmerman -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpmestan at gmail.com Thu Oct 26 07:27:55 2017 From: alpmestan at gmail.com (Alp Mestanogullari) Date: Thu, 26 Oct 2017 09:27:55 +0200 Subject: [Haskell-cafe] Automatically using boxed or unboxed vectors In-Reply-To: <96E2A5A4-0225-4D47-9416-316412D27D73@gmail.com> References: <96E2A5A4-0225-4D47-9416-316412D27D73@gmail.com> Message-ID: Hello Jake, Many libraries implement this "array of structures -> structure of arrays" type of transformation, including for example the 'accelerate' library. I'm however only aware of one that does it for good old vectors: https://hackage.haskell.org/package/hybrid-vectors I don't think it implements any Generic-deriving mechanism for making this work on user-specified types without any effort. This could be a pretty nice addition though :) On Wed, Oct 25, 2017 at 12:43 AM, Jake Waksbaum wrote: > I am trying to create a data type that is an vector of values, but > internally uses an unboxed vector when possible and a boxed array > otherwise. If this already exists, let me know. For example, any easily > unboxed type is stored in an unboxed array, but also any type that is a > product type of only easily unboxed types like (Int, Int) is stored in > multiple unboxed arrays. I don’t think there is a smart way of doing this > for sum types, so those are stored in boxed arrays. > > I’m trying to create a typeclass > > class VectorElement a where > data Vector a > replicate :: Int -> a -> Vector a > length :: Vector a -> Int > > to represent things that can be stored in Vectors. I can then implement it > for specific types that I know can be stored in unboxed vectors: > > instance VectorElement Int where > newtype Vector Int = VectorInt (U.Vector Int) > deriving Show > replicate len x = VectorInt $ U.replicate len x > length (VectorInt v) = U.length v > > I also want to automatically derive instances of this class for other > types using the Generic typeclass. Ideally these instances would be the > most efficient possible, so that for example the instance for (Int, Int) > used two unboxed arrays but the instance for Maybe Int uses a boxed array. > To that end I created another typeclass and wrote instances for the Generic > data constructors: > > class VectorElementG (r :: * -> *) where > data VectorG r > replicateG :: Int -> r a -> VectorG r > lengthG :: VectorG r -> Int > > instance VectorElementG V1 where > data VectorG V1 > replicateG = undefined > lengthG = undefined > > instance VectorElementG U1 where > newtype VectorG U1 = VectorGUnit Int > replicateG i U1 = VectorGUnit i > lengthG (VectorGUnit i) = i > > instance VectorElement a => VectorElementG (K1 i a) where > newtype VectorG (K1 i a) = VectorGK (Vector a) > replicateG i (K1 x) = VectorGK $ replicate i x > lengthG (VectorGK v) = length v > > instance (VectorElementG r1, VectorElementG r2) => VectorElementG (r1 :*: > r2) where > data VectorG (r1 :*: r2) = VectorGProd (VectorG r1) (VectorG r2) > replicateG i (a :*: b) = VectorGProd (replicateG i a) (replicateG i b) > lengthG (VectorGProd v _) = lengthG v > > instance VectorElement ((r1 :+: r2) p) where > newtype Vector ((r1 :+: r2) p) = VectorSum (V.Vector ((r1 :+: r2) p)) > replicate i x = VectorSum $ V.replicate i x > length (VectorSum v) = V.length v > > instance VectorElementG f => VectorElementG (M1 i c f) where > newtype VectorG (M1 i c f) = VectorGMeta (VectorG f) > replicateG i (M1 f) = VectorGMeta $ replicateG i f > lengthG (VectorGMeta v) = lengthG v > > > I’m not sure if these are correct, especially the one for :+:. I want > basically base cases to be any type that already has an instance of > VectorElement or a sum type which is automatically boxed, and the recursive > case to basically just use parallel vectors for product types. > > I think this sort of worked insofar as it allowed me to write an instance > for tuples: > > instance (VectorElement a, VectorElement b) => VectorElement (a,b) where > newtype Vector (a, b) = VectorTuple (VectorG (Rep (a, b))) > replicate i x = VectorTuple $ replicateG i (from x) > length (VectorTuple v) = lengthG v > > Ideally, however, the compiler would automatically derive this instance > using the Generic instance. Is there a way to do that also? > > I would welcome any thoughts on this entire idea and approach. > > Thanks, > Jake Waksbaum > > _______________________________________________ > 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. > -- Alp Mestanogullari -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Thu Oct 26 10:45:37 2017 From: eleventynine at gmail.com (Mike Ledger) Date: Thu, 26 Oct 2017 21:45:37 +1100 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. Message-ID: Hi Haskell-Cafe, I've been working on and off on a HTML templating library that is slightly novel for a few months. Here's the good parts: * it's faster than lucid and blaze * it has a valid monad instance * it has another valid monad instance, that is slightly different! * it paramaterises templates by the data they require * the HTML5 combinators don't rely on any highly overloaded/overlapping typeclasses; type errors in nice-html templates tend to be nice monomorphic type mismatches To achieve this, it has a distinct compilation phase (at runtime) for templates. This means the actual rendering function does very little beyond concatenate Text and escape dynamic input. It also severely restricts usage to the built-in combinators available -- at least, for dynamic data -- and can make writing a nice-html template difficult, though littering _ throughout type signatures helps. Check it out! Benchmark results, a README, and an example: https://github.com/TransportEngineering/nice-html Hackage: https://hackage.haskell.org/package/nice-html The only thing on the roadmap right now is to have some nice :-) way to assign JavaScript event handlers to Markup. This is something that I really appreciate when using React.js, so my eventual aim is for nice-html to be like a (more) server-side version of React. Right now, you can keep track of element ids with `Text.Html.Writer.note`, but it's neither a very good nor very useful interface. Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Thu Oct 26 12:43:39 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Thu, 26 Oct 2017 12:43:39 +0000 Subject: [Haskell-cafe] Adding a DB Connection Pool to a Web Application In-Reply-To: References: Message-ID: <3ba8f70d-800e-9860-b4f9-458dd1b84ec7@mixmax.com> Hi Everyone, I am trying to set up a simple web application, but with all the trappings of a production app. (This is strictly for learning purposes). At the moment, I am trying to get a database pool up and running that the rest of the application can use. You can see my current progress at this repository. You may want to look at only the code in the back-end folder, as there is a whole front-end application. So, again, my goal is to get a database pool up and running. At the moment, if I try to build the executable target, I get the following error: Error /Users/stevenleiva/Repos/todo/back-end/app/Main.hs:10:13: error: • Couldn't match type ‘persistent-2.7.0:Database.Persist.Class.PersistStore.BaseBackend backend0’ with ‘Database.Persist.Sql.Types.Internal.SqlBackend’ arising from a use of ‘createPostgresqlPool’ The type variable ‘backend0’ is ambiguous • In a stmt of a 'do' block: pool <- createPostgresqlPool connStr 1 In the expression: do { pool <- createPostgresqlPool connStr 1; startApp } In an equation for ‘main’: main = do { pool <- createPostgresqlPool connStr 1; startApp } Not using Mixmax yet? I tried helping out the compiler by adding pool :: Pool Connection, after importing those type constructors / constants. At that point, I got a different error: Error 2 /Users/stevenleiva/Repos/todo/back-end/app/Main.hs:11:32: error: • No instance for (monad-logger-0.3.25.1:Control.Monad.Logger.MonadLogger IO) arising from a use of ‘createPostgresqlPool’ • In a stmt of a 'do' block: pool :: Pool Connection <- createPostgresqlPool connStr 1 In the expression: do { pool :: Pool Connection <- createPostgresqlPool connStr 1; startApp } In an equation for ‘main’: main = do { pool :: Pool Connection <- createPostgresqlPool connStr 1; startApp } Not using Mixmax yet? I understand that createPostgresqlPool eventually gives me a value of type m (Pool Connection), where there are some constraints on m. I also understand that at the moment I am getting back a value IO (Pool Connection), and that IO does not have an instance of MonadLogger. >From here, I am at a bit of a lose on how to proceed. I thought implementing an instance of MonadLogger for IO that would simply typecheck (and not log), but that would lead to an orphaned instance, correct? What's the easiest next step to make forward progress here? P.S. I am aware that there are a lot of advanced (for me anyway) Haskell that can be done via monad transformers, natural transformations, etc., in order to wire up a DB with Servant, but I am happy with the "next simplest step" until I learn some of those concepts better. (Then Haskell makes refactoring a breeze!). Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Thu Oct 26 12:51:04 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Thu, 26 Oct 2017 18:21:04 +0530 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. In-Reply-To: References: Message-ID: Thank you for putting comparisons and benchmarks, upfront. Do you mind explaining the invalid monad instance of Lucid and how it would impact a library user? Also, I'm assuming one shouldn't call the `compile` function each time a page needs to be rendered, right? Should one put the results of the `compile` function in a top-level Map and use those to get the speed gains? Side comment, the use of `dynamic` makes it look similar to reflex `dyn*` API. -- Saurabh. On Thu, Oct 26, 2017 at 4:15 PM, Mike Ledger wrote: > Hi Haskell-Cafe, > > I've been working on and off on a HTML templating library that is slightly > novel for a few months. > > Here's the good parts: > * it's faster than lucid and blaze > * it has a valid monad instance > * it has another valid monad instance, that is slightly different! > * it paramaterises templates by the data they require > * the HTML5 combinators don't rely on any highly overloaded/overlapping > typeclasses; type errors in nice-html templates tend to be nice monomorphic > type mismatches > > To achieve this, it has a distinct compilation phase (at runtime) for > templates. This means the actual rendering function does very little beyond > concatenate Text and escape dynamic input. It also severely restricts usage > to the built-in combinators available -- at least, for dynamic data -- and > can make writing a nice-html template difficult, though littering _ > throughout type signatures helps. > > Check it out! > > Benchmark results, a README, and an example: https://github.com/ > TransportEngineering/nice-html > Hackage: https://hackage.haskell.org/package/nice-html > > The only thing on the roadmap right now is to have some nice :-) way to > assign JavaScript event handlers to Markup. This is something that I really > appreciate when using React.js, so my eventual aim is for nice-html to be > like a (more) server-side version of React. Right now, you can keep track > of element ids with `Text.Html.Writer.note`, but it's neither a very good > nor very useful interface. > > Cheers, > Mike > > _______________________________________________ > 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. > -- http://www.saurabhnanda.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Thu Oct 26 13:33:34 2017 From: will.yager at gmail.com (Will Yager) Date: Thu, 26 Oct 2017 09:33:34 -0400 Subject: [Haskell-cafe] Adding a DB Connection Pool to a Web Application In-Reply-To: <3ba8f70d-800e-9860-b4f9-458dd1b84ec7@mixmax.com> References: <3ba8f70d-800e-9860-b4f9-458dd1b84ec7@mixmax.com> Message-ID: You want e.g. https://hackage.haskell.org/package/monad-logger-0.3.25.1/docs/Control-Monad-Logger.html#v:runStderrLoggingT You can mentally replace “m” with “IO”. It takes some monadic action that requires logging (like setting up a database pool) and provides a concrete implementation of how logging should be done (like printing messages to stdout), thus discharging the MonadLogger constraint. See “MTL style”. I think MonadLogger is as good an introduction to monad transformers as any, since it’s fairly straightforward. Most of the instances are like the reader monad, where they just pass around some function that takes the log details and does something with them. > On Oct 26, 2017, at 8:43 AM, Steven Leiva wrote: > > > I thought implementing an instance of MonadLogger for IO that would simply typecheck (and not log), but that would lead to an orphaned instance, correct? What's the easiest next step to make forward progress here? > > P.S. I am aware that there are a lot of advanced (for me anyway) Haskell that can be done via monad transformers, natural transformations, etc., in order to wire up a DB with Servant, but I am happy with the "next simplest step" until I learn some of those concepts better. (Then Haskell makes refactoring a breeze!). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Thu Oct 26 13:54:33 2017 From: eleventynine at gmail.com (Mike Ledger) Date: Fri, 27 Oct 2017 00:54:33 +1100 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. In-Reply-To: References: Message-ID: >Do you mind explaining the invalid monad instance of Lucid and how it would impact a library user? To my knowledge lucid uses a monad instance that follow the monad laws (what I meant by "valid") fine. It's blaze that's (somewhat) infamous for having an invalid monad instance. It used to be the case that (>>=) in blaze called 'error' -- the Monad instance was to just use (>>) = mappend. Looking now, the implementation has changed and my knowledge was out-of-date. I think it still violates the monad laws, but I don't know if as a user of blaze you'd ever be able to actually observe this, if that makes any sense. For some fun discussions on this see: - https://stackoverflow.com/questions/6399648/what-happens-to-you-if-you-break-the-monad-laws - https://www.reddit.com/r/haskell/comments/16iakr/what_happens_when_a_monad_violates_monadic_laws/ How invalid monads *can* impact users is better explored in the SO question. >Also, I'm assuming one shouldn't call the `compile` function each time a page needs to be rendered, right? Should one put the results of the `compile` function in a top-level Map and use those to get the speed gains? The idea is to only compile a template once, ever. If you need to compile a template every time a page is rendered (though I can't actually think of a case where you would), you should probably just skip the middle-man, and use lucid (or blaze). It's not horribly slow, but you'd miss out on the benefits of nice-html by doing this. Cheers On Thu, Oct 26, 2017 at 11:51 PM, Saurabh Nanda wrote: > Thank you for putting comparisons and benchmarks, upfront. > > Do you mind explaining the invalid monad instance of Lucid and how it > would impact a library user? > > Also, I'm assuming one shouldn't call the `compile` function each time a > page needs to be rendered, right? Should one put the results of the > `compile` function in a top-level Map and use those to get the speed gains? > > Side comment, the use of `dynamic` makes it look similar to reflex `dyn*` > API. > > -- Saurabh. > > On Thu, Oct 26, 2017 at 4:15 PM, Mike Ledger > wrote: > >> Hi Haskell-Cafe, >> >> I've been working on and off on a HTML templating library that is >> slightly novel for a few months. >> >> Here's the good parts: >> * it's faster than lucid and blaze >> * it has a valid monad instance >> * it has another valid monad instance, that is slightly different! >> * it paramaterises templates by the data they require >> * the HTML5 combinators don't rely on any highly overloaded/overlapping >> typeclasses; type errors in nice-html templates tend to be nice monomorphic >> type mismatches >> >> To achieve this, it has a distinct compilation phase (at runtime) for >> templates. This means the actual rendering function does very little beyond >> concatenate Text and escape dynamic input. It also severely restricts usage >> to the built-in combinators available -- at least, for dynamic data -- and >> can make writing a nice-html template difficult, though littering _ >> throughout type signatures helps. >> >> Check it out! >> >> Benchmark results, a README, and an example: >> https://github.com/TransportEngineering/nice-html >> Hackage: https://hackage.haskell.org/package/nice-html >> >> The only thing on the roadmap right now is to have some nice :-) way to >> assign JavaScript event handlers to Markup. This is something that I really >> appreciate when using React.js, so my eventual aim is for nice-html to be >> like a (more) server-side version of React. Right now, you can keep track >> of element ids with `Text.Html.Writer.note`, but it's neither a very good >> nor very useful interface. >> >> Cheers, >> Mike >> >> _______________________________________________ >> 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. >> > > > > -- > http://www.saurabhnanda.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Thu Oct 26 14:53:45 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 26 Oct 2017 17:53:45 +0300 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. In-Reply-To: References: Message-ID: <332b911a-5898-15e1-8d12-27717ca148b2@iki.fi> Please, if you think blaze-markup violates the Monad laws, then report a counterexample so it will get fixed. The changelog for 0.8.0.0 [1] advertises: Make `MarkupM` finally adhere to the Monad laws http://hackage.haskell.org/package/blaze-markup-0.8.0.0/changelog Cheers, Oleg. On 26.10.2017 16:54, Mike Ledger wrote: > >Do you mind explaining the invalid monad instance of Lucid and how it > would impact a library user? > To my knowledge lucid uses a monad instance that follow the monad laws > (what I meant by "valid") fine. > > It's blaze that's (somewhat) infamous for having an invalid monad > instance. It used to be the case that (>>=) in blaze called 'error' -- > the Monad instance was to just use (>>) = mappend. Looking now, the > implementation has changed and my knowledge was out-of-date. I think > it still violates the monad laws, but I don't know if as a user of > blaze you'd ever be able to actually observe this, if that makes any > sense. > > For some fun discussions on this see: > - > https://stackoverflow.com/questions/6399648/what-happens-to-you-if-you-break-the-monad-laws > - > https://www.reddit.com/r/haskell/comments/16iakr/what_happens_when_a_monad_violates_monadic_laws/ > > How invalid monads /can/ impact users is better explored in the SO > question. > > >Also, I'm assuming one shouldn't call the `compile` function each > time a page needs to be rendered, right? Should one put the results of > the `compile` function in a top-level Map and use those to get the > speed gains? > The idea is to only compile a template once, ever. If you need to > compile a template every time a page is rendered (though I can't > actually think of a case where you would), you should probably just > skip the middle-man, and use lucid (or blaze). It's not horribly slow, > but you'd miss out on the benefits of nice-html by doing this. > > Cheers > > On Thu, Oct 26, 2017 at 11:51 PM, Saurabh Nanda > > wrote: > > Thank you for putting comparisons and benchmarks, upfront. > > Do you mind explaining the invalid monad instance of Lucid and how > it would impact a library user? > > Also, I'm assuming one shouldn't call the `compile` function each > time a page needs to be rendered, right? Should one put the > results of the `compile` function in a top-level Map and use those > to get the speed gains? > > Side comment, the use of `dynamic` makes it look similar to reflex > `dyn*` API. > > -- Saurabh. > > On Thu, Oct 26, 2017 at 4:15 PM, Mike Ledger > > wrote: > > Hi Haskell-Cafe, > > I've been working on and off on a HTML templating library that > is slightly novel for a few months.  > > Here's the good parts: > * it's faster than lucid and blaze > * it has a valid monad instance > * it has another valid monad instance, that is slightly different! > * it paramaterises templates by the data they require > * the HTML5 combinators don't rely on any highly > overloaded/overlapping typeclasses; type errors in nice-html > templates tend to be nice monomorphic type mismatches > > To achieve this, it has a distinct compilation phase (at > runtime) for templates. This means the actual rendering > function does very little beyond concatenate Text and escape > dynamic input. It also severely restricts usage to the > built-in combinators available -- at least, for dynamic data > -- and can make writing a nice-html template difficult, though > littering _ throughout type signatures helps. > > Check it out! > > Benchmark results, a README, and an example: > https://github.com/TransportEngineering/nice-html > > Hackage: https://hackage.haskell.org/package/nice-html > > > The only thing on the roadmap right now is to have some nice > :-) way to assign JavaScript event handlers to Markup. This is > something that I really appreciate when using React.js, so my > eventual aim is for nice-html to be like a (more) server-side > version of React. Right now, you can keep track of element ids > with `Text.Html.Writer.note`, but it's neither a very good nor > very useful interface. > > Cheers, > Mike > > _______________________________________________ > 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. > > > > > -- > http://www.saurabhnanda.com > > > > > _______________________________________________ > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From chronowski.tomasz at gmail.com Thu Oct 26 15:34:56 2017 From: chronowski.tomasz at gmail.com (Tomasz Chronowski) Date: Thu, 26 Oct 2017 17:34:56 +0200 Subject: [Haskell-cafe] Multi-param typeclass as superclass of Single-param typeclasses Message-ID: This is my first post here, so Hello everyone! In haskell it is possible to express a constraint "if 'a' and 'b' are instance of 'AB' then 'a' is instance of 'A' and 'b' is instance of 'B'": class (A a, B b) => AB a b ... Is it possible to express the converse - "if 'a' is instance of 'A' and 'b' is instance of 'B' then 'a' and 'b' are instance of 'AB'"? I want to create a list of shapes that can be tested for intersection. I think that possibility of expressing such constraints would allow to doing this in a "Object Oriented" way: data Circle = Circle { ... } data Square = Square { ... } class Shape a class Intersect a b where intersect :: a -> b -> Bool -- pseudo haskell - "If 'a' is instance of 'Shape' and 'b' is instance of 'Shape' then 'a' and 'b' are instance of 'Intersect'" -- maybe some type hackery allows to express this? constraint Shape a, Shape b => Intersect a b instance Shape Circle instance Shape Square instance Intersect Circle Circle ... instance Intersect Circle Square ... ... data ShapeBox = forall a. Shape a => ShapeBox a foo = let x:y:_ = [ShapeBox Circle { ... }, ShapeBox Square { ... }, ...] in intersect x y -- this should work because we know for sure that there is an instance of Intersect for type of 'x' and type of 'y' Is such idea already described somewhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Thu Oct 26 15:42:13 2017 From: eleventynine at gmail.com (Mike Ledger) Date: Fri, 27 Oct 2017 02:42:13 +1100 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. In-Reply-To: <332b911a-5898-15e1-8d12-27717ca148b2@iki.fi> References: <332b911a-5898-15e1-8d12-27717ca148b2@iki.fi> Message-ID: >The changelog for 0.8.0.0 [1] advertises: Make `MarkupM` finally adhere >to the Monad laws Nice. I searched the issue tracker on GitHub but ought to have just looked at the changelog. >Please, if you think blaze-markup violates the Monad laws, then report a >counterexample so it will get fixed. Not really. Hence the caveat. But just to clarify, my thinking* was this: return a >>= f = Empty a >>= f = Append (Empty a) (f (markupValue (Empty a))) = Append (Empty a) (f a) ≠ f a *BUT *you can only observe this by importing Blaze.Text.Internal and pattern matching on MarkupM. Using renderMarkup you can't observe it. So long as a user can't observe the difference (or is at least discouraged by a scary-looking .Internal suffix), it's just an implementation detail that the data constructors don't exactly match. Cheers, Mike *: using = and ≠ to mean "exactly the same as", like a derived Eq instance, rather than e.g. https://github.com/jaspervdj/blaze-markup/blob/master/tests/Text/Blaze/Tests.hs#L179 which compares different Markup renderings. On Fri, Oct 27, 2017 at 1:53 AM, Oleg Grenrus wrote: > Please, if you think blaze-markup violates the Monad laws, then report a > counterexample so it will get fixed. > > The changelog for 0.8.0.0 [1] advertises: Make `MarkupM` finally adhere > to the Monad laws > > http://hackage.haskell.org/package/blaze-markup-0.8.0.0/changelog > > Cheers, Oleg. > > > On 26.10.2017 16:54, Mike Ledger wrote: > > >Do you mind explaining the invalid monad instance of Lucid and how it > > would impact a library user? > > To my knowledge lucid uses a monad instance that follow the monad laws > > (what I meant by "valid") fine. > > > > It's blaze that's (somewhat) infamous for having an invalid monad > > instance. It used to be the case that (>>=) in blaze called 'error' -- > > the Monad instance was to just use (>>) = mappend. Looking now, the > > implementation has changed and my knowledge was out-of-date. I think > > it still violates the monad laws, but I don't know if as a user of > > blaze you'd ever be able to actually observe this, if that makes any > > sense. > > > > For some fun discussions on this see: > > - > > https://stackoverflow.com/questions/6399648/what- > happens-to-you-if-you-break-the-monad-laws > > - > > https://www.reddit.com/r/haskell/comments/16iakr/what_ > happens_when_a_monad_violates_monadic_laws/ > > > > How invalid monads /can/ impact users is better explored in the SO > > question. > > > > >Also, I'm assuming one shouldn't call the `compile` function each > > time a page needs to be rendered, right? Should one put the results of > > the `compile` function in a top-level Map and use those to get the > > speed gains? > > The idea is to only compile a template once, ever. If you need to > > compile a template every time a page is rendered (though I can't > > actually think of a case where you would), you should probably just > > skip the middle-man, and use lucid (or blaze). It's not horribly slow, > > but you'd miss out on the benefits of nice-html by doing this. > > > > Cheers > > > > On Thu, Oct 26, 2017 at 11:51 PM, Saurabh Nanda > > > wrote: > > > > Thank you for putting comparisons and benchmarks, upfront. > > > > Do you mind explaining the invalid monad instance of Lucid and how > > it would impact a library user? > > > > Also, I'm assuming one shouldn't call the `compile` function each > > time a page needs to be rendered, right? Should one put the > > results of the `compile` function in a top-level Map and use those > > to get the speed gains? > > > > Side comment, the use of `dynamic` makes it look similar to reflex > > `dyn*` API. > > > > -- Saurabh. > > > > On Thu, Oct 26, 2017 at 4:15 PM, Mike Ledger > > > wrote: > > > > Hi Haskell-Cafe, > > > > I've been working on and off on a HTML templating library that > > is slightly novel for a few months. > > > > Here's the good parts: > > * it's faster than lucid and blaze > > * it has a valid monad instance > > * it has another valid monad instance, that is slightly > different! > > * it paramaterises templates by the data they require > > * the HTML5 combinators don't rely on any highly > > overloaded/overlapping typeclasses; type errors in nice-html > > templates tend to be nice monomorphic type mismatches > > > > To achieve this, it has a distinct compilation phase (at > > runtime) for templates. This means the actual rendering > > function does very little beyond concatenate Text and escape > > dynamic input. It also severely restricts usage to the > > built-in combinators available -- at least, for dynamic data > > -- and can make writing a nice-html template difficult, though > > littering _ throughout type signatures helps. > > > > Check it out! > > > > Benchmark results, a README, and an example: > > https://github.com/TransportEngineering/nice-html > > > > Hackage: https://hackage.haskell.org/package/nice-html > > > > > > The only thing on the roadmap right now is to have some nice > > :-) way to assign JavaScript event handlers to Markup. This is > > something that I really appreciate when using React.js, so my > > eventual aim is for nice-html to be like a (more) server-side > > version of React. Right now, you can keep track of element ids > > with `Text.Html.Writer.note`, but it's neither a very good nor > > very useful interface. > > > > Cheers, > > Mike > > > > _______________________________________________ > > 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. > > > > > > > > > > -- > > http://www.saurabhnanda.com > > > > > > > > > > _______________________________________________ > > 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.peter.doyle at gmail.com Thu Oct 26 17:09:48 2017 From: benjamin.peter.doyle at gmail.com (Ben Doyle) Date: Thu, 26 Oct 2017 17:09:48 +0000 Subject: [Haskell-cafe] Multi-param typeclass as superclass of Single-param typeclasses In-Reply-To: References: Message-ID: Welcome! You can certainly express the constraint you want. But you can't do what you're trying to do with ShapeBox. Let's take those two in reverse order. Before I start, though, an obligatory warning (with the assumption that you're new to Haskell, as well as this list): object orientation is usually not the best way to go in Haskell. I don't mean to shame you for the question; it's a good learning exercise. But in most practical cases plain old data and functions will serve you better than a bunch of ad-hoc typeclasses. So. We have an existential type, ShapeBox, that stores a Shape but hides what Shape it is. And it seems that you'd like to be able write something like: bar :: ShapeBox -> ShapeBox -> Bool bar (ShapeBox x) (ShapeBox y) = intersect x y The trouble is that the instance of intersect we call depends on the actual types of x and y, and we don't know those types (because we've hidden them on purpose). If x and y are both Circles we need to use the Intersect Circle Circle instance. If instead y is a Square we must use the Intersect Circle Square instance, which in principle could do something entirely different. But there's hope. The way to declare the constraint you're after is to put it on the instance declaration: instance (Shape a, Shape b) => Intersect a b where intersect x y = ... That says precisely that whenever a and b are shapes, you can intersect them. The catch is that you must write this instance using only the Shape-ness of x and y (which is all you know about them). So you won't be able to have one way to intersect squares and circles, and another for triangles and hexagons; you need to abstract all the knowledge that lets you intersect into the Shape class. The difference is between telling the compiler, "I promise I'll go and write a suitable instance for each pair of Shapes, really" (which Haskell won't allow), and saying "here's how to intersect any two shapes whatsoever." You may want to check out the diagrams package, which does something similar with the class HasEnvelope. Hope that helps, Ben On Thu, Oct 26, 2017 at 11:37 AM Tomasz Chronowski < chronowski.tomasz at gmail.com> wrote: > This is my first post here, so Hello everyone! > > In haskell it is possible to express a constraint "if 'a' and 'b' are > instance of 'AB' then 'a' is instance of 'A' and 'b' is instance of 'B'": > > class (A a, B b) => AB a b ... > > Is it possible to express the converse - "if 'a' is instance of 'A' and > 'b' is instance of 'B' then 'a' and 'b' are instance of 'AB'"? > > I want to create a list of shapes that can be tested for intersection. I > think that possibility of expressing such constraints would allow to doing > this in a "Object Oriented" way: > > data Circle = Circle { ... } > data Square = Square { ... } > > class Shape a > > class Intersect a b where > intersect :: a -> b -> Bool > > -- pseudo haskell - "If 'a' is instance of 'Shape' and 'b' is instance of > 'Shape' then 'a' and 'b' are instance of 'Intersect'" > -- maybe some type hackery allows to express this? > constraint Shape a, Shape b => Intersect a b > > instance Shape Circle > instance Shape Square > > instance Intersect Circle Circle ... > instance Intersect Circle Square ... > ... > > data ShapeBox = forall a. Shape a => ShapeBox a > > foo = let x:y:_ = [ShapeBox Circle { ... }, ShapeBox Square { ... }, ...] > in intersect x y -- this should work because we know for sure that > there is an instance of Intersect for type of 'x' and type of 'y' > > Is such idea already described somewhere? > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Fri Oct 27 01:37:29 2017 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Thu, 26 Oct 2017 18:37:29 -0700 Subject: [Haskell-cafe] Call for Participation: ICFP 2017 Message-ID: <59f28dd98491c_59703fcb06059be4754e5@landin.local.mail> CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2018 23rd ACM SIGPLAN International Conference on Functional Programming September 23-29, 2018 St. Louis, Missouri, United States http://conf.researchr.org/home/icfp-2018 The 23rd ACM SIGPLAN International Conference on Functional Programming will be held in St. Louis, Missouri, United States on September 23-29, 2018. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2018 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 23 (the day before ICFP) and September 27-29 (the three days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 20, 2017 Notification of acceptance: December 18, 2017 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2017 workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com by November 20, 2017. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 18, 2017, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2018-files/icfp18-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2018 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Christophe Scholliers (University of Ghent) Workshop Co-Chair: David Christiansen (Indiana University) General Chair: Robby Findler (Northwestern University) Program Chair: Matthew Flatt (University of Utah) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com From icfp.publicity at googlemail.com Fri Oct 27 01:40:31 2017 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Thu, 26 Oct 2017 18:40:31 -0700 Subject: [Haskell-cafe] Call for Workshop Proposals: ICFP 2018 Message-ID: <59f28e8f860d3_59753fc3c5457be452126@landin.local.mail> [ Please disregard previous version sent with the wrong subject line. ] CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2018 23rd ACM SIGPLAN International Conference on Functional Programming September 23-29, 2018 St. Louis, Missouri, United States http://conf.researchr.org/home/icfp-2018 The 23rd ACM SIGPLAN International Conference on Functional Programming will be held in St. Louis, Missouri, United States on September 23-29, 2018. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2018 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 23 (the day before ICFP) and September 27-29 (the three days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 20, 2017 Notification of acceptance: December 18, 2017 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2017 workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com by November 20, 2017. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 18, 2017, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2018-files/icfp18-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2018 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Christophe Scholliers (University of Ghent) Workshop Co-Chair: David Christiansen (Indiana University) General Chair: Robby Findler (Northwestern University) Program Chair: Matthew Flatt (University of Utah) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com From aquagnu at gmail.com Fri Oct 27 07:39:50 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 27 Oct 2017 10:39:50 +0300 Subject: [Haskell-cafe] Multi-param typeclass as superclass of Single-param typeclasses In-Reply-To: References: Message-ID: <20171027103950.0532aee3@Pavel> May be type families can help here? There was good article about Pokemons and type families which seems to be close to such task IMHO... > Welcome! You can certainly express the constraint you want. But you > can't do what you're trying to do with ShapeBox. > > Let's take those two in reverse order. Before I start, though, an > obligatory warning (with the assumption that you're new to Haskell, > as well as this list): object orientation is usually not the best way > to go in Haskell. I don't mean to shame you for the question; it's a > good learning exercise. But in most practical cases plain old data > and functions will serve you better than a bunch of ad-hoc > typeclasses. > > So. We have an existential type, ShapeBox, that stores a Shape but > hides what Shape it is. And it seems that you'd like to be able write > something like: > > bar :: ShapeBox -> ShapeBox -> Bool > bar (ShapeBox x) (ShapeBox y) = intersect x y > > The trouble is that the instance of intersect we call depends on the > actual types of x and y, and we don't know those types (because we've > hidden them on purpose). If x and y are both Circles we need to use > the Intersect Circle Circle instance. If instead y is a Square we > must use the Intersect Circle Square instance, which in principle > could do something entirely different. > > But there's hope. The way to declare the constraint you're after is > to put it on the instance declaration: > > instance (Shape a, Shape b) => Intersect a b where > intersect x y = ... > > That says precisely that whenever a and b are shapes, you can > intersect them. The catch is that you must write this instance using > only the Shape-ness of x and y (which is all you know about them). So > you won't be able to have one way to intersect squares and circles, > and another for triangles and hexagons; you need to abstract all the > knowledge that lets you intersect into the Shape class. > > The difference is between telling the compiler, "I promise I'll go and > write a suitable instance for each pair of Shapes, really" (which > Haskell won't allow), and saying "here's how to intersect any two > shapes whatsoever." > > You may want to check out the diagrams package, which does something > similar with the class HasEnvelope. > > Hope that helps, > > Ben > > On Thu, Oct 26, 2017 at 11:37 AM Tomasz Chronowski < > chronowski.tomasz at gmail.com> wrote: > > > This is my first post here, so Hello everyone! > > > > In haskell it is possible to express a constraint "if 'a' and 'b' > > are instance of 'AB' then 'a' is instance of 'A' and 'b' is > > instance of 'B'": > > > > class (A a, B b) => AB a b ... > > > > Is it possible to express the converse - "if 'a' is instance of 'A' > > and 'b' is instance of 'B' then 'a' and 'b' are instance of 'AB'"? > > > > I want to create a list of shapes that can be tested for > > intersection. I think that possibility of expressing such > > constraints would allow to doing this in a "Object Oriented" way: > > > > data Circle = Circle { ... } > > data Square = Square { ... } > > > > class Shape a > > > > class Intersect a b where > > intersect :: a -> b -> Bool > > > > -- pseudo haskell - "If 'a' is instance of 'Shape' and 'b' is > > instance of 'Shape' then 'a' and 'b' are instance of 'Intersect'" > > -- maybe some type hackery allows to express this? > > constraint Shape a, Shape b => Intersect a b > > > > instance Shape Circle > > instance Shape Square > > > > instance Intersect Circle Circle ... > > instance Intersect Circle Square ... > > ... > > > > data ShapeBox = forall a. Shape a => ShapeBox a > > > > foo = let x:y:_ = [ShapeBox Circle { ... }, ShapeBox Square > > { ... }, ...] in intersect x y -- this should work because we know > > for sure that there is an instance of Intersect for type of 'x' and > > type of 'y' > > > > Is such idea already described somewhere? > > _______________________________________________ > > 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. From jeroen at chordify.net Fri Oct 27 09:44:58 2017 From: jeroen at chordify.net (Jeroen Bransen) Date: Fri, 27 Oct 2017 11:44:58 +0200 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: That is similar to what I am doing now, but I don't think this solves my problem. When I have a package A depending on B, I make a mistake in B such that it doesn't compile, then commit something correct to A, the build for A will also fail because of this error in B. I would like to let A be based on the last succesful build of B, but with shared `.stack-work` I don't think that's going to work. Regards, Jeroen Bransen Op 24-10-2017 om 16:39 schreef Adam Bergmark: > I haven't felt the need to share build artifacts like this. Instead, > e.g., if you cache your `.stack-work` and your master project does a > git clone of sub projects and you put those paths in your stack.yaml > then `stack build` should only rebuild the changes. You may be able to > share parts of `.stack-work` as well but I haven't looked into that. > > HTH, > Adam > > > On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen > wrote: > > Hi cafe, > > Does anyone know of a good setup for doing continuous integration > with a > set of Haskell packages, each in its own repository? Just building > everything upon every commit is not so hard, but to speed up building > times I'd like to build and test only the minimal set of packages. In > particular, at a commit for some package A, I would like to build and > test A and all packages that depend on A. > > The problem is that most CI tools use some notion of 'build artefact', > which Stack doesn't really seem to give me. Ideally building a package > results in some object file, which can then be used by the other > packages. When building failed, packages that depend on it can > still use > the last succesful build. I've tried to look up some Haskell projects, > but most of them seem to use some ad hoc setup. > > Some pointers are appreciated, as we are using Gitlab a gitlab-runner > specific option would be great, but I am also open to use Jenkins or > other tools. And I guess my main struggle now is on the > stack/Haskell side. > > Regards, > Jeroen Bransen > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at chordify.net Fri Oct 27 09:45:06 2017 From: jeroen at chordify.net (Jeroen Bransen) Date: Fri, 27 Oct 2017 11:45:06 +0200 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: That is similar to what I am doing now, but I don't think this solves my problem. When I have a package A depending on B, I make a mistake in B such that it doesn't compile, then commit something correct to A, the build for A will also fail because of this error in B. I would like to let A be based on the last succesful build of B, but with shared `.stack-work` I don't think that's going to work. Regards, Jeroen Bransen Op 24-10-2017 om 16:39 schreef Adam Bergmark: > I haven't felt the need to share build artifacts like this. Instead, > e.g., if you cache your `.stack-work` and your master project does a > git clone of sub projects and you put those paths in your stack.yaml > then `stack build` should only rebuild the changes. You may be able to > share parts of `.stack-work` as well but I haven't looked into that. > > HTH, > Adam > > > On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen > wrote: > > Hi cafe, > > Does anyone know of a good setup for doing continuous integration > with a > set of Haskell packages, each in its own repository? Just building > everything upon every commit is not so hard, but to speed up building > times I'd like to build and test only the minimal set of packages. In > particular, at a commit for some package A, I would like to build and > test A and all packages that depend on A. > > The problem is that most CI tools use some notion of 'build artefact', > which Stack doesn't really seem to give me. Ideally building a package > results in some object file, which can then be used by the other > packages. When building failed, packages that depend on it can > still use > the last succesful build. I've tried to look up some Haskell projects, > but most of them seem to use some ad hoc setup. > > Some pointers are appreciated, as we are using Gitlab a gitlab-runner > specific option would be great, but I am also open to use Jenkins or > other tools. And I guess my main struggle now is on the > stack/Haskell side. > > Regards, > Jeroen Bransen > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeroen at chordify.net Fri Oct 27 09:49:23 2017 From: jeroen at chordify.net (Jeroen Bransen) Date: Fri, 27 Oct 2017 11:49:23 +0200 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: This is a very interesting suggestion. We are not using Nix, so the whole setup would change, but it is something we can consider for the buildserver (and maybe even other machines). If I understand correctly the packages are then not built anymore with Stack, but rather with Nix specific build scripts. Everything else follows then naturally because of the nice nature of Nix. I'll definitely look into this, but a solution using Stack would be nice and much easier to set up currently. Regards, Jeroen Bransen Op 24-10-2017 om 22:43 schreef Matthew Pickering: > It sounds like using Hydra (the Nix based CI system) would be suitable > for your needs. > > The essential work flow would be to create a package set which > contained all your packages and then create a job set which built that > package set. > > What's more, if your developers are also using nix then it is trivial > to setup a build cache which serves prebuilt packages to them. > > The manual provides a concise introduction - https://nixos.org/hydra/ > > Matt > > On Tue, Oct 24, 2017 at 10:33 AM, Jeroen Bransen wrote: >> Hi cafe, >> >> Does anyone know of a good setup for doing continuous integration with a set >> of Haskell packages, each in its own repository? Just building everything >> upon every commit is not so hard, but to speed up building times I'd like to >> build and test only the minimal set of packages. In particular, at a commit >> for some package A, I would like to build and test A and all packages that >> depend on A. >> >> The problem is that most CI tools use some notion of 'build artefact', which >> Stack doesn't really seem to give me. Ideally building a package results in >> some object file, which can then be used by the other packages. When >> building failed, packages that depend on it can still use the last succesful >> build. I've tried to look up some Haskell projects, but most of them seem to >> use some ad hoc setup. >> >> Some pointers are appreciated, as we are using Gitlab a gitlab-runner >> specific option would be great, but I am also open to use Jenkins or other >> tools. And I guess my main struggle now is on the stack/Haskell side. >> >> Regards, >> Jeroen Bransen >> _______________________________________________ >> 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. From adam at bergmark.nl Fri Oct 27 12:42:25 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 27 Oct 2017 12:42:25 +0000 Subject: [Haskell-cafe] Haskell CI with many repositories/packages In-Reply-To: References: <34c854db-e52a-117b-a0fe-b2254e1d1ef9@chordify.net> Message-ID: But you could check whether sharing the .stack-work would even be a noticeable improvement. Unless your projects change often and take a lot of time to build (excluding dependencies) then I don't think it would. On Fri, 27 Oct 2017 at 11:45 Jeroen Bransen wrote: > That is similar to what I am doing now, but I don't think this solves my > problem. When I have a package A depending on B, I make a mistake in B such > that it doesn't compile, then commit something correct to A, the build for > A will also fail because of this error in B. I would like to let A be based > on the last succesful build of B, but with shared `.stack-work` I don't > think that's going to work. > > Regards, > Jeroen Bransen > > Op 24-10-2017 om 16:39 schreef Adam Bergmark: > > I haven't felt the need to share build artifacts like this. Instead, e.g., > if you cache your `.stack-work` and your master project does a git clone of > sub projects and you put those paths in your stack.yaml then `stack build` > should only rebuild the changes. You may be able to share parts of > `.stack-work` as well but I haven't looked into that. > > HTH, > Adam > > > On Tue, 24 Oct 2017 at 11:35 Jeroen Bransen wrote: > >> Hi cafe, >> >> Does anyone know of a good setup for doing continuous integration with a >> set of Haskell packages, each in its own repository? Just building >> everything upon every commit is not so hard, but to speed up building >> times I'd like to build and test only the minimal set of packages. In >> particular, at a commit for some package A, I would like to build and >> test A and all packages that depend on A. >> >> The problem is that most CI tools use some notion of 'build artefact', >> which Stack doesn't really seem to give me. Ideally building a package >> results in some object file, which can then be used by the other >> packages. When building failed, packages that depend on it can still use >> the last succesful build. I've tried to look up some Haskell projects, >> but most of them seem to use some ad hoc setup. >> >> Some pointers are appreciated, as we are using Gitlab a gitlab-runner >> specific option would be great, but I am also open to use Jenkins or >> other tools. And I guess my main struggle now is on the stack/Haskell >> side. >> >> Regards, >> Jeroen Bransen >> _______________________________________________ >> 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Fri Oct 27 13:16:03 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Fri, 27 Oct 2017 13:16:03 +0000 Subject: [Haskell-cafe] Adding a DB Connection Pool to a Web Application In-Reply-To: References: <3ba8f70d-800e-9860-b4f9-458dd1b84ec7@mixmax.com> Message-ID: <5b3cac5c-2f9b-7a94-a79d-61b7c4a725d1@mixmax.com> Hi will - I wanted to thank you for your reply. It seems like with runStderrLoggingT, I'd have to start learning about monad transformers. I know that this is something that I have to learn eventually; I'm 100% convinced of that, but for now I am going with an orphaned instance of MonadLogger IO. As soon as I wire up the database, I'll start on monad transformers. I've been told that Stephen Diehl is a good resource for it. Thank you very much. On Thu, Oct 26, 2017 9:33 AM, Will Yager will.yager at gmail.com wrote: You want e.g. https://hackage.haskell.org/package/monad-logger-0.3.25.1/docs/Control-Monad-Logger.html#v:runStderrLoggingT You can mentally replace “m” with “IO”. It takes some monadic action that requires logging (like setting up a database pool) and provides a concrete implementation of how logging should be done (like printing messages to stdout), thus discharging the MonadLogger constraint. See “MTL style”. I think MonadLogger is as good an introduction to monad transformers as any, since it’s fairly straightforward. Most of the instances are like the reader monad, where they just pass around some function that takes the log details and does something with them. On Oct 26, 2017, at 8:43 AM, Steven Leiva wrote: I thought implementing an instance of MonadLogger for IO that would simply typecheck (and not log), but that would lead to an orphaned instance, correct? What's the easiest next step to make forward progress here? P.S. I am aware that there are a lot of advanced (for me anyway) Haskell that can be done via monad transformers, natural transformations, etc., in order to wire up a DB with Servant, but I am happy with the "next simplest step" until I learn some of those concepts better. (Then Haskell makes refactoring a breeze!). Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Sat Oct 28 16:23:23 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sat, 28 Oct 2017 18:23:23 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2017-10-30 @ 19:30 Message-ID: <874lqji6mc.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on **Monday, October 30** at Augustiner-Gaststätte Rumpler (Baumstraße 21) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html Please note the changed date! Everybody is welcome. cu, -- Christian Neukirchen http://chneukirchen.org From louis.pan at gmail.com Sun Oct 29 02:18:20 2017 From: louis.pan at gmail.com (Louis Pan) Date: Sun, 29 Oct 2017 13:18:20 +1100 Subject: [Haskell-cafe] ANN: parameterized, indexed monads with a single "parameter" type variable Message-ID: Hi Haskell-Cafe, I've been experimenting with indexed/parameterized monads with a single "parameter" type variable. The difference from my variation from Conor McBride's IMonad (which also uses one "parameter") is that the "parameter" doesn't have postcondition semanatics. (FYI, a good intro to indexed monads is https://stackoverflow.com/questions/28690448/what-is-indexed-monad) Instead, in the instance of PApplicative, you have to specify the rule of how to combine the "parameter" `t` and `u` into the final parameter `u`. That way, I can create "parameterized" versions of Semigroup, Monoid, as well as Applicative, Alternative, Monad. It also allows for create different flavours of "parameterized" kinds for ReaderT. For example, I've created OverlappingWhichReader, DistinctWhichReader, and ManyReader newtype wrappers around ReaderT. OverlappingWhichReader and DistinctWhichReader can combine reader that read `Which '[Int, Bool]` (polymorphic variant, analogous to 'Either Int Bool') with another reader that reader `Which '[Bool, String]` into a reader that can read `Which '[Int, Bool, String]` ManyReader can combine reader that read `Many '[Int, Bool]` (heterogenous record, analogous to tuple (Int, Bool)) with another reader that reader `Many '[Bool, String]` into a reader that can read `Many '[Int, Bool, String]` See https://github.com/louispan/parameterized/blob/master/src/Parameterized/Control/Monad/Trans/Reader.hs https://github.com/louispan/parameterized/blob/master/test/Parameterized/Control/Monad/Trans/Reader/ReaderSpec.hs ----- The single "parameter" still allows for the traditional changing state type for StateT. For example, I've created ChangingState newtype wrappers around StateT, which changes the state parameter. I've also created ManyState, which can combine StateT that modifies `Many '[Int, Bool]` with another StateT that modifes `Many '[Bool, String]` into a StateT that can modify `Many '[Int, Bool, String]` See https://github.com/louispan/parameterized/blob/master/src/Parameterized/Control/Monad/Trans/State/Strict.hs https://github.com/louispan/parameterized/blob/master/test/Parameterized/Control/Monad/Trans/State/Strict/StateSpec.hs --- I'd would appreciate if I could get any feedback on this approach. Cheers, Louis -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Sun Oct 29 23:52:31 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Sun, 29 Oct 2017 23:52:31 +0000 Subject: [Haskell-cafe] newtype and access control Message-ID: <5112d445-3572-a6e8-429a-9b8cd003dfce@mixmax.com> Hello everyone, I am watching a talk on YouTube calledWrangling Monad Transformer Stacks. The talk has the following code: code{-# LANGUAGE GeneralizedNewtypeDeriving -#} module DBTrans where newtype WithTrans a = WithTrans (WithDBConn a) deriving (Functor, Applicative, Monad) inDBTrans :: WithTrans a -> WithConn a inDBTrans = ... NOT USING MIXMAX YET? The speaker mentions that by using a newtype, we can perform "access control". The functioninDBTrans is "aware" that the type constructorWithTrans is simply a wrapper forWithDBConn, and that functions outside of the module are not privy to that information. Out of necessity, the speaker has to assume a certain level of Haskell knowledge that I don't have, because I am confused as to what language principles would allow forinDBTrans to be used for access control. I understand that a newtype declaration does create a new type from a "type safey" point of view; that a newtype declaration is required to have a single data constructor with a single (not named) field; and that, once the type-checking is done, the compiler can strip out the newtype wrapper and leave the underlying type (informally speaking, of course), but that still doesn't get me toinDBTrans can do access control. Thank you for any help! Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Oct 29 23:58:40 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 29 Oct 2017 19:58:40 -0400 Subject: [Haskell-cafe] newtype and access control In-Reply-To: <5112d445-3572-a6e8-429a-9b8cd003dfce@mixmax.com> References: <5112d445-3572-a6e8-429a-9b8cd003dfce@mixmax.com> Message-ID: On Sun, Oct 29, 2017 at 7:52 PM, Steven Leiva wrote: > Out of necessity, the speaker has to assume a certain level of Haskell > knowledge that I don't have, because I am confused as to what language > principles would allow for *inDBTrans* to be used for access control. > > As presented, that doesn't seem to be true. If the module exported only the type constructor, then it would be impossible for other modules to pattern match it and access the wrapped value. But the module has no export list, so it exports everything including the data constructor and modules can pattern match to unwrap it; the only other way to get that kind of isolation is for the wrapped data type to not be in scope, but that also doesn't seem to be the case. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Mon Oct 30 01:09:50 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Sun, 29 Oct 2017 21:09:50 -0400 Subject: [Haskell-cafe] newtype and access control In-Reply-To: References: <5112d445-3572-a6e8-429a-9b8cd003dfce@mixmax.com> Message-ID: Hi Brandon, I think that exporting the data constructor was a simple oversight. I can definitely see how, if you don't export the data constructors, other modules can't pattern match on the newtype value and therefore can't "get at" the WithDBConn a value. Thank you! On Oct 29, 2017 7:58 PM, "Brandon Allbery" wrote: > On Sun, Oct 29, 2017 at 7:52 PM, Steven Leiva > wrote: > >> Out of necessity, the speaker has to assume a certain level of Haskell >> knowledge that I don't have, because I am confused as to what language >> principles would allow for *inDBTrans* to be used for access control. >> >> > As presented, that doesn't seem to be true. If the module exported only > the type constructor, then it would be impossible for other modules to > pattern match it and access the wrapped value. But the module has no export > list, so it exports everything including the data constructor and modules > can pattern match to unwrap it; the only other way to get that kind of > isolation is for the wrapped data type to not be in scope, but that also > doesn't seem to be the case. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Tue Oct 31 01:49:54 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Tue, 31 Oct 2017 01:49:54 +0000 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect Message-ID: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Hi Everyone, I am reading the 2nd edition of Graham Hutton's Programming in Haskell. I'm not reading the entire book, just the parts of Haskell that I am still iffy on. Anyway, in Chapter 12, Section 3, Hutton introduces monads. He start off with the following code: first module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Inteval (Val n) = neval (Div el er) = eval el `div` eval er Not using Mixmax yet? And then he points out that the second clause of eval will raise an error if eval er evaluates to 0. One solution is that, instead of using the div function, we use a safeDiv:: Int -> Int -> Maybe Int function, which evaluate to Nothing if the divisor is 0. This means that expr's type changes from eval :: Eval -> Int to eval :: Eval -> Maybe Int, and this means that implementing eval becomes very verbose: second module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Maybe Inteval (Val n) = Just neval (Div el er) = case eval el of Nothing -> Nothing Just y -> case eval er of Nothing -> Nothing Just x -> y `safeDiv` xsafeDiv :: Int -> Int -> Maybe IntsafeDiv x y | y == 0 = Nothing | otherwise = Just (x `div` y) Not using Mixmax yet? In order to make eval more concise, we can try the applicative style, where the second clause of the eval function becomes pure safeDiv <*> eval el <*> eval er. Of course, that doesn't work because pure safeDiv has the type Int -> Int -> Maybe Int, and what we need is a function of type Int -> Int -> Int. Anyways, this is all setup / context to what Hutton says next: The conclusion is that the function eval does not fit the pattern of effectful programming that is capture by applicative functors. The applicative style restricts us to applying pure functions to effectful arguments: eval does not fit this pattern because the function safeDiv that is used to process the resulting values is not a pure function, but may itself fail. I am confused by Hutton's use of the word effectful and by his description of safeDiv as "not a pure function". I tried skimming the other sections of the book to see if he provided a definition of this somewhere, but if he did, I couldn't find it. So my question is, in what way does Hutton mean for the reader to understand the words effect / effectful, and why does he describe the function safeDiv as not a pure function? Thank you! Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Tue Oct 31 01:51:12 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Tue, 31 Oct 2017 01:51:12 +0000 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect In-Reply-To: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> References: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Message-ID: Sorry - for correctness's sake, I meant to say that pure safeDiv :: Maybe (Int -> Int -> Maybe Int). On Mon, Oct 30, 2017 9:49 PM, Steven Leiva leiva.steven at gmail.com wrote: Hi Everyone, I am reading the 2nd edition of Graham Hutton's Programming in Haskell. I'm not reading the entire book, just the parts of Haskell that I am still iffy on. Anyway, in Chapter 12, Section 3, Hutton introduces monads. He start off with the following code: first module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Inteval (Val n) = neval (Div el er) = eval el `div` eval er Not using Mixmax yet? And then he points out that the second clause of eval will raise an error if eval er evaluates to 0. One solution is that, instead of using the div function, we use a safeDiv:: Int -> Int -> Maybe Int function, which evaluate to Nothing if the divisor is 0. This means that expr's type changes from eval :: Eval -> Int to eval :: Eval -> Maybe Int, and this means that implementing eval becomes very verbose: second module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Maybe Inteval (Val n) = Just neval (Div el er) = case eval el of Nothing -> Nothing Just y -> case eval er of Nothing -> Nothing Just x -> y `safeDiv` xsafeDiv :: Int -> Int -> Maybe IntsafeDiv x y | y == 0 = Nothing | otherwise = Just (x `div` y) Not using Mixmax yet? In order to make eval more concise, we can try the applicative style, where the second clause of the eval function becomes pure safeDiv <*> eval el <*> eval er. Of course, that doesn't work because pure safeDiv has the type Int -> Int -> Maybe Int, and what we need is a function of type Int -> Int -> Int. Anyways, this is all setup / context to what Hutton says next: The conclusion is that the function eval does not fit the pattern of effectful programming that is capture by applicative functors. The applicative style restricts us to applying pure functions to effectful arguments: eval does not fit this pattern because the function safeDiv that is used to process the resulting values is not a pure function, but may itself fail. I am confused by Hutton's use of the word effectful and by his description of safeDiv as "not a pure function". I tried skimming the other sections of the book to see if he provided a definition of this somewhere, but if he did, I couldn't find it. So my question is, in what way does Hutton mean for the reader to understand the words effect / effectful, and why does he describe the function safeDiv as not a pure function? Thank you! Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Oct 31 02:02:34 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 30 Oct 2017 22:02:34 -0400 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect In-Reply-To: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> References: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Message-ID: In this specific case it is actually pure, because Maybe is pure, but in the general case it behaves with respect to Applicative (and Monad, which this appears to be leading up to) as effectful. In this context, an effect is just whatever behavior is captured by the Applicative/Monad. "purity" is a bit overloaded: - purity with respect to an effect of some unspecified kind, as here; - purity with respect to IO which encapsulates behavior not contained specifically within your program, the most common meaning in Haskell; - purity with respect to cross-thread effects in IO/STM; - purity with respect to mutability in ST; .... On Mon, Oct 30, 2017 at 9:49 PM, Steven Leiva wrote: > Hi Everyone, > > I am reading the 2nd edition of Graham Hutton's Programming in Haskell. > I'm not reading the entire book, just the parts of Haskell that I am still > iffy on. > > Anyway, in Chapter 12, Section 3, Hutton introduces monads. > > He start off with the following code: > > first > > module Expr where > data Expr = Val Int | Div Expr Expr > eval :: Expr -> Int > eval (Val n) = n > eval (Div el er) = eval el `div` eval er > > [image: Mixmax] > Not using Mixmax yet? > > > > And then he points out that the second clause of *eval* will raise an > error if *eval er* evaluates to 0. > > One solution is that, instead of using the *div* function, we use a > *safeDiv* *:: Int -> Int -> Maybe Int* function, which evaluate to > *Nothing* if the divisor is 0. This means that *expr*'s type changes from *eval > :: Eval -> Int* to *eval :: Eval -> Maybe Int*, and this means that > implementing *eval* becomes very verbose: > > > second > > module Expr where > data Expr = Val Int | Div Expr Expr > eval :: Expr -> Maybe Int > eval (Val n) = Just n > eval (Div el er) = case eval el of > Nothing -> Nothing > Just y -> case eval er of > Nothing -> Nothing > Just x -> y `safeDiv` x > safeDiv :: Int -> Int -> Maybe Int > safeDiv x y > | y == 0 = Nothing > | otherwise = Just (x `div` y) > > [image: Mixmax] > Not using Mixmax yet? > > > > In order to make *eval* more concise, we can try the applicative style, > where the second clause of the *eval* function becomes *pure safeDiv <*> > eval el <*> eval er*. Of course, that doesn't work because *pure safeDiv* has > the type *Int -> Int -> Maybe Int*, and what we need is a function of > type *Int -> Int -> Int*. > > Anyways, this is all setup / context to what Hutton says next: > > *The conclusion is that the function eval does not fit the pattern of > effectful programming that is capture by applicative functors. The > applicative style restricts us to applying pure functions to effectful > arguments: eval does not fit this pattern because the function safeDiv that > is used to process the resulting values is not a pure function, but may > itself fail. * > > I am confused by Hutton's use of the word effectful and by his description > of safeDiv as "not a pure function". I tried skimming the other sections of > the book to see if he provided a definition of this somewhere, but if he > did, I couldn't find it. So my question is, in what way does Hutton mean > for the reader to understand the words effect / effectful, and why does he > describe the function safeDiv as not a pure function? > > Thank you! > > Steven Leiva > 305.528.6038 <(305)%20528-6038> > leiva.steven at gmail.com > http://www.linkedin.com/in/stevenleiva > > _______________________________________________ > 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. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Tue Oct 31 02:11:38 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Tue, 31 Oct 2017 02:11:38 +0000 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect In-Reply-To: References: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Message-ID: Hello Again Brandon, Thank you for the explanation. I'll have to mull it over a bit to let it sink in. I am finding the overloading of purity to be easier to grasp than the meaning of effect. I think the reason for that is precisely because it depends on the context (generally speaking) in which it is being used. For example, in the case of Maybe, the effect is possible failure. In the case of lists, the effect is non-determinism, etc. On Mon, Oct 30, 2017 10:02 PM, Brandon Allbery allbery.b at gmail.com wrote: In this specific case it is actually pure, because Maybe is pure, but in the general case it behaves with respect to Applicative (and Monad, which this appears to be leading up to) as effectful. In this context, an effect is just whatever behavior is captured by the Applicative/Monad. "purity" is a bit overloaded: - purity with respect to an effect of some unspecified kind, as here; - purity with respect to IO which encapsulates behavior not contained specifically within your program, the most common meaning in Haskell; - purity with respect to cross-thread effects in IO/STM; - purity with respect to mutability in ST; .... On Mon, Oct 30, 2017 at 9:49 PM, Steven Leiva wrote: Hi Everyone, I am reading the 2nd edition of Graham Hutton's Programming in Haskell. I'm not reading the entire book, just the parts of Haskell that I am still iffy on. Anyway, in Chapter 12, Section 3, Hutton introduces monads. He start off with the following code: first module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Inteval (Val n) = neval (Div el er) = eval el `div` eval er Not using Mixmax yet? And then he points out that the second clause of eval will raise an error if eval er evaluates to 0. One solution is that, instead of using the div function, we use a safeDiv:: Int -> Int -> Maybe Int function, which evaluate to Nothing if the divisor is 0. This means that expr's type changes from eval :: Eval -> Int to eval :: Eval -> Maybe Int, and this means that implementing eval becomes very verbose: second module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Maybe Inteval (Val n) = Just neval (Div el er) = case eval el of Nothing -> Nothing Just y -> case eval er of Nothing -> Nothing Just x -> y `safeDiv` xsafeDiv :: Int -> Int -> Maybe IntsafeDiv x y | y == 0 = Nothing | otherwise = Just (x `div` y) Not using Mixmax yet? In order to make eval more concise, we can try the applicative style, where the second clause of the eval function becomes pure safeDiv <*> eval el <*> eval er. Of course, that doesn't work because pure safeDiv has the type Int -> Int -> Maybe Int, and what we need is a function of type Int -> Int -> Int. Anyways, this is all setup / context to what Hutton says next: The conclusion is that the function eval does not fit the pattern of effectful programming that is capture by applicative functors. The applicative style restricts us to applying pure functions to effectful arguments: eval does not fit this pattern because the function safeDiv that is used to process the resulting values is not a pure function, but may itself fail. I am confused by Hutton's use of the word effectful and by his description of safeDiv as "not a pure function". I tried skimming the other sections of the book to see if he provided a definition of this somewhere, but if he did, I couldn't find it. So my question is, in what way does Hutton mean for the reader to understand the words effect / effectful, and why does he describe the function safeDiv as not a pure function? Thank you! Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva _______________________________________________ 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. -- brandon s allbery kf8nh                               sine nomine associates allbery.b at gmail.comballbery@sinenomine.netunix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Tue Oct 31 03:08:47 2017 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 30 Oct 2017 20:08:47 -0700 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect In-Reply-To: References: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Message-ID: The meaning of "pure", and the meaning of "effect" are closely intertwined, because essentially, "pure" (in this usage) means "not having any effects", and "effect" means "the part of the function result that isn't pure". If what you have in your mind is a function `div :: Int -> Int -> Int`, and instead have to settle for `div :: Int -> Int -> Maybe Int`, they you could consider the first the type it should have "if it were pure", and call the Maybe type "an effect". The words are relative to your starting assumption of what type div should have, though. As you mention, you could also quite reasonably admit that `Maybe Int` is a perfectly good type on its own, and consider `safeDiv` to be a pure function with this type as a codomain. You can even pull the same trick with more powerful effects. The type `IO Int` is a (more or less) defined type, and its values are ACTIONS that your computer could take, which if they don't fail return an Int. From this perspective, even a function like `readFile :: FilePath -> IO ByteString` is a "pure" function, which maps file paths to actions. But if you consider it as a map from file paths to bytestrings, then it is effectful. Again, these words are defined relative to what you consider the result to be. (I'm ignoring, here, some questions about what the correct semantics for IO types even is...) If you want a more formal (but less intuitive) way to think about this, then you can turn to category theory. In category theory, a monad (say, F) is an endofunctor in some category -- for us, typically the category of Haskell types and functions. But F also defines a SECOND category, called the Kleisli category of F: the set of types here the same, but a "Kleisli arrow" between two objects A and B is a function A -> F B in the base category. Notice that any Kleisli arrow IS an arrow in the base category, so in that sense you could claim that it's "pure". But IF you choose to think about it as an arrow from A to B, THEN you must be talking about the Kleisli category, and it has an effect captured by F. If that wasn't what you were looking for, though, feel free to ignore it. On Mon, Oct 30, 2017 at 7:11 PM, Steven Leiva wrote: > Hello Again Brandon, > > Thank you for the explanation. I'll have to mull it over a bit to let it > sink in. I am finding the overloading of purity to be easier to grasp than > the meaning of effect. I think the reason for that is precisely because it > depends on the context (generally speaking) in which it is being used. For > example, in the case of Maybe, the effect is possible failure. In the case > of lists, the effect is non-determinism, etc. > > > > On Mon, Oct 30, 2017 10:02 PM, Brandon Allbery allbery.b at gmail.com wrote: > >> In this specific case it is actually pure, because Maybe is pure, but in >> the general case it behaves with respect to Applicative (and Monad, which >> this appears to be leading up to) as effectful. In this context, an effect >> is just whatever behavior is captured by the Applicative/Monad. >> >> "purity" is a bit overloaded: >> >> - purity with respect to an effect of some unspecified kind, as here; >> >> - purity with respect to IO which encapsulates behavior not contained >> specifically within your program, the most common meaning in Haskell; >> >> - purity with respect to cross-thread effects in IO/STM; >> >> - purity with respect to mutability in ST; >> >> .... >> >> >> On Mon, Oct 30, 2017 at 9:49 PM, Steven Leiva >> wrote: >> >> Hi Everyone, >> >> I am reading the 2nd edition of Graham Hutton's Programming in Haskell. >> I'm not reading the entire book, just the parts of Haskell that I am still >> iffy on. >> >> Anyway, in Chapter 12, Section 3, Hutton introduces monads. >> >> He start off with the following code: >> >> first >> >> module Expr where >> data Expr = Val Int | Div Expr Expr >> eval :: Expr -> Int >> eval (Val n) = n >> eval (Div el er) = eval el `div` eval er >> >> [image: Mixmax] >> Not using Mixmax yet? >> >> >> >> And then he points out that the second clause of *eval* will raise an >> error if *eval er* evaluates to 0. >> >> One solution is that, instead of using the *div* function, we use a >> *safeDiv* *:: Int -> Int -> Maybe Int* function, which evaluate to >> *Nothing* if the divisor is 0. This means that *expr*'s type changes >> from *eval :: Eval -> Int* to *eval :: Eval -> Maybe Int*, and this >> means that implementing *eval* becomes very verbose: >> >> >> second >> >> module Expr where >> data Expr = Val Int | Div Expr Expr >> eval :: Expr -> Maybe Int >> eval (Val n) = Just n >> eval (Div el er) = case eval el of >> Nothing -> Nothing >> Just y -> case eval er of >> Nothing -> Nothing >> Just x -> y `safeDiv` x >> safeDiv :: Int -> Int -> Maybe Int >> safeDiv x y >> | y == 0 = Nothing >> | otherwise = Just (x `div` y) >> >> [image: Mixmax] >> Not using Mixmax yet? >> >> >> >> In order to make *eval* more concise, we can try the applicative style, >> where the second clause of the *eval* function becomes *pure safeDiv <*> >> eval el <*> eval er*. Of course, that doesn't work because *pure safeDiv* has >> the type *Int -> Int -> Maybe Int*, and what we need is a function of >> type *Int -> Int -> Int*. >> >> Anyways, this is all setup / context to what Hutton says next: >> >> *The conclusion is that the function eval does not fit the pattern of >> effectful programming that is capture by applicative functors. The >> applicative style restricts us to applying pure functions to effectful >> arguments: eval does not fit this pattern because the function safeDiv that >> is used to process the resulting values is not a pure function, but may >> itself fail. * >> >> I am confused by Hutton's use of the word effectful and by his >> description of safeDiv as "not a pure function". I tried skimming the other >> sections of the book to see if he provided a definition of this somewhere, >> but if he did, I couldn't find it. So my question is, in what way does >> Hutton mean for the reader to understand the words effect / effectful, and >> why does he describe the function safeDiv as not a pure function? >> >> Thank you! >> >> Steven Leiva >> 305.528.6038 <(305)%20528-6038> >> leiva.steven at gmail.com >> http://www.linkedin.com/in/stevenleiva >> >> _______________________________________________ >> 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. >> >> >> >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > > Steven Leiva > 305.528.6038 <(305)%20528-6038> > leiva.steven at gmail.com > http://www.linkedin.com/in/stevenleiva > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Tue Oct 31 03:15:44 2017 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Mon, 30 Oct 2017 20:15:44 -0700 Subject: [Haskell-cafe] Call for Sponsorships: ICFP 2018 Message-ID: <59f7eae05ae36_6d3c3fc7de057be4438e5@landin.local.mail> ICFP 2018 The 23rd ACM SIGPLAN International Conference on Functional Programming https://icfp18.sigplan.org Call for Sponsorships Web version of this call for sponsorships: https://icfp18.sigplan.org/attending/supporting-icfp ## Why Sponsor ICFP 2018? ICFP is the premier conference on functional programming languages, covering all aspects of theory, implementation, and application. Every year, we bring together over 500 world-leading researchers, practitioners, and students to discuss the latest findings, collaborate on new ideas, and meet new people. By sponsoring ICFP, your organization can demonstrate its commitment to supporting high quality research and to developing the next generation of functional programming experts. Most of our sponsorship funds are used to help students from around the world afford to attend the conference and get the most out of their experience. We believe that this commitment will pay dividends for our students, our sponsors, and the public for years to come. If you're interested in becoming a sponsor, we'd love to hear from you: get in touch with our sponsorship team at sponsorship-2018 at icfpconference.org ## Sponsorship Opportunities and Benefits ### Bronze - $750 * Your logo on the ICFP 2018 website * Your name listed in the proceedings ### Silver - $3,000 * All of the benefits of Bronze sponsorship * One complimentary 3-day ICFP registration * A table at the industrial reception * Your logo in the proceedings * Your logo on publicity materials such as banners and posters ### Gold - $6,000 * All of the benefits of Silver sponsorship * One additional complimentary 3-day ICFP registration (2 in total) * A named supporter of the industrial reception * An opportunity to include branded merchandise in participants' swag bag ### Platinum - $10,000 * All the benefits of Gold sponsorship * One additional complimentary 3-day ICFP registration (3 in total) * A named supporter of ICFP 2018 * An opportunity to speak to the audience at the industrial reception * A table/booth-like space in the coffee break areas ## Additional Sponsorship Opportunities We offer some additional sponsorship options to sponsors at the silver level or above. ### Lanyard Sponsor - $4,000 You provide the lanyards that every attendee will wear around their neck. ### Video Sponsor - $4,000 ICFP makes videos available for free to non-attendees following the conference. As a video sponsor, you support the recording and release of these videos. In exchange, your logo will be displayed as part of every ICFP video. ### Banner - $1,000 Post a free-standing banner (up to 2m high and 1m wide, provided by you) on the ICFP main stage throughout the conference. From leiva.steven at gmail.com Tue Oct 31 14:47:09 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Tue, 31 Oct 2017 14:47:09 +0000 Subject: [Haskell-cafe] What Does Graham Hutton Mean by Effect In-Reply-To: References: <14468db2-8c15-c6aa-7bba-3bfb621d53d3@mixmax.com> Message-ID: <0411bd8e-5240-8455-3c8c-5938b82b4a18@mixmax.com> Thank you Chris. The idea that "effect" and "pure" are relative to something, as you mentioned, helped this click for me. On Mon, Oct 30, 2017 11:08 PM, Chris Smith cdsmith at gmail.com wrote: The meaning of "pure", and the meaning of "effect" are closely intertwined, because essentially, "pure" (in this usage) means "not having any effects", and "effect" means "the part of the function result that isn't pure".  If what you have in your mind is a function `div :: Int -> Int -> Int`, and instead have to settle for `div :: Int -> Int -> Maybe Int`, they you could consider the first the type it should have "if it were pure", and call the Maybe type "an effect".  The words are relative to your starting assumption of what type div should have, though.  As you mention, you could also quite reasonably admit that `Maybe Int` is a perfectly good type on its own, and consider `safeDiv` to be a pure function with this type as a codomain. You can even pull the same trick with more powerful effects.  The type `IO Int` is a (more or less) defined type, and its values are ACTIONS that your computer could take, which if they don't fail return an Int.  From this perspective, even a function like `readFile :: FilePath -> IO ByteString` is a "pure" function, which maps file paths to actions.  But if you consider it as a map from file paths to bytestrings, then it is effectful.  Again, these words are defined relative to what you consider the result to be.  (I'm ignoring, here, some questions about what the correct semantics for IO types even is...) If you want a more formal (but less intuitive) way to think about this, then you can turn to category theory.  In category theory, a monad (say, F) is an endofunctor in some category -- for us, typically the category of Haskell types and functions.  But F also defines a SECOND category, called the Kleisli category of F: the set of types here the same, but a "Kleisli arrow" between two objects A and B is a function A -> F B in the base category.  Notice that any Kleisli arrow IS an arrow in the base category, so in that sense you could claim that it's "pure".  But IF you choose to think about it as an arrow from A to B, THEN you must be talking about the Kleisli category, and it has an effect captured by F.  If that wasn't what you were looking for, though, feel free to ignore it. On Mon, Oct 30, 2017 at 7:11 PM, Steven Leiva wrote: Hello Again Brandon, Thank you for the explanation. I'll have to mull it over a bit to let it sink in. I am finding the overloading of purity to be easier to grasp than the meaning of effect. I think the reason for that is precisely because it depends on the context (generally speaking) in which it is being used. For example, in the case of Maybe, the effect is possible failure. In the case of lists, the effect is non-determinism, etc. On Mon, Oct 30, 2017 10:02 PM, Brandon Allbery allbery.b at gmail.com wrote: In this specific case it is actually pure, because Maybe is pure, but in the general case it behaves with respect to Applicative (and Monad, which this appears to be leading up to) as effectful. In this context, an effect is just whatever behavior is captured by the Applicative/Monad. "purity" is a bit overloaded: - purity with respect to an effect of some unspecified kind, as here; - purity with respect to IO which encapsulates behavior not contained specifically within your program, the most common meaning in Haskell; - purity with respect to cross-thread effects in IO/STM; - purity with respect to mutability in ST; .... On Mon, Oct 30, 2017 at 9:49 PM, Steven Leiva wrote: Hi Everyone, I am reading the 2nd edition of Graham Hutton's Programming in Haskell. I'm not reading the entire book, just the parts of Haskell that I am still iffy on. Anyway, in Chapter 12, Section 3, Hutton introduces monads. He start off with the following code: first module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Inteval (Val n) = neval (Div el er) = eval el `div` eval er Not using Mixmax yet? And then he points out that the second clause of eval will raise an error if eval er evaluates to 0. One solution is that, instead of using the div function, we use a safeDiv:: Int -> Int -> Maybe Int function, which evaluate to Nothing if the divisor is 0. This means that expr's type changes from eval :: Eval -> Int to eval :: Eval -> Maybe Int, and this means that implementing eval becomes very verbose: second module Expr wheredata Expr = Val Int | Div Expr Expreval :: Expr -> Maybe Inteval (Val n) = Just neval (Div el er) = case eval el of Nothing -> Nothing Just y -> case eval er of Nothing -> Nothing Just x -> y `safeDiv` xsafeDiv :: Int -> Int -> Maybe IntsafeDiv x y | y == 0 = Nothing | otherwise = Just (x `div` y) Not using Mixmax yet? In order to make eval more concise, we can try the applicative style, where the second clause of the eval function becomes pure safeDiv <*> eval el <*> eval er. Of course, that doesn't work because pure safeDiv has the type Int -> Int -> Maybe Int, and what we need is a function of type Int -> Int -> Int. Anyways, this is all setup / context to what Hutton says next: The conclusion is that the function eval does not fit the pattern of effectful programming that is capture by applicative functors. The applicative style restricts us to applying pure functions to effectful arguments: eval does not fit this pattern because the function safeDiv that is used to process the resulting values is not a pure function, but may itself fail. I am confused by Hutton's use of the word effectful and by his description of safeDiv as "not a pure function". I tried skimming the other sections of the book to see if he provided a definition of this somewhere, but if he did, I couldn't find it. So my question is, in what way does Hutton mean for the reader to understand the words effect / effectful, and why does he describe the function safeDiv as not a pure function? Thank you! Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva _______________________________________________ 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. -- brandon s allbery kf8nh                               sine nomine associates allbery.b at gmail.comballbery@sinenomine.netunix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva _______________________________________________ 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. Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Oct 31 18:15:24 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 31 Oct 2017 14:15:24 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 Message-ID: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> Hello everyone, The GHC team is very pleased to announce the second candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc2/ This is the second and hopefully last of two release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Oct 31 18:15:24 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 31 Oct 2017 14:15:24 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 3 Message-ID: <87h8u31b9x.fsf@ben-laptop.smart-cactus.org> Hello everyone, The GHC team is very pleased to announce the third candidate of the 8.2.2 release of the Glasgow Haskell Compiler. Source and binary distributions are available at https://downloads.haskell.org/~ghc/8.2.2-rc3/ This is the third and last of three release candidates leading up the final 8.2.2 release. This release fixes approximately fifty bugs present in 8.2.1. These most notably include, * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) See [1] for the full list. Release candidate three contains only two patches not present in -rc2 but fixes a packaging issue which lead to unintentional downgrading the process and Cabal libraries. As always, please report any issues you encounter. Happy testing, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.2.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: