From gershomb at gmail.com Sun Apr 1 04:56:39 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 1 Apr 2018 00:56:39 -0400 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development Message-ID: Fellow Haskellers, Recently there has been much work into creating a better and more professional GHC development process, including in the form of DevOps infrastructure, scheduled releases and governance, etc. But much remains to be done. There continues to be concern about the lack of use of industry-standard tools. For example, GHC development is tied to Phabricator, which is a custom product originally developed for in-house use by an obscure startup. GHC development is documented on a wiki still -- ancient technology, not appropriate for 2018. Wiki syntax for documentation needs to be replaced by the only modern standard -- github flavored markdown. Trac itself is ancient technology, dating to 2003, well before anybody knew how to program real software. It provides no support for all the most important aspects of software development -- Kanban boards, sprint management, or even burndown charts. What is necessary is an integrated solution that holistically addresses all aspects of development, fostering a DevOps culture, embracing cloud-first, agile-first, test-first, disrupt-first principles, and with an ironclad SLA. Rather than homegrown solutions, we need a GHC development process that utilizes tools and procedures already familiar to regular developers. Cross-sectional feature comparison analysis yields a clear front-runner -- Visual Studio Team Services. VSTS is a recognized Leader in the Gartner Magic Quadrant for Enterprise Agile Planning tools. It lets us migrate from custom git hosting to a more reliable source control system -- Team Foundation Version Control. By enforcing the locking of checked-out files, we can prevent the sorts of overlap between different patches that occur in the current distributed version management system, and coordinate tightly between developers, enabling and fostering T-shaped skills. Team Build also lets us migrate from antiquated makefiles to modern, industry-standard technology -- XML descriptions of build processes that integrate automatically with tracking of PBIs (product backlog items), and one-button release management. In terms of documentation, rather than deal with the subtleties of different markdown implementations and the confusing world of restructured text, we can utilize the full power of Word, including SharePoint integration as well as Office 365 capabilities, and integration with Microsoft Teams, the chat-based workspace for collaboration. This enables much more effective cross-team collaboration with product and marketing divisions. One of the most exciting features of VSTS is powerful extensibility, with APIs offered in both major programming paradigms in use today -- JVM and .NET. The core organizational principle for full application lifecycle management is a single data construct -- the "work item" which documentation informs us "represents a thing," which can be anything that "a user can imagine." The power of work items comes through their extensible XML representation. Work items are combined into a Process Template, with such powerful Process Templates available as Agile, Scrum, and CMMI. VSTS will also allow us to analyze GHC Developer team performance with an integrated reporting data warehouse that uses a cube. Pricing for up to 100 users is $750 a month. Individual developers can also purchase subscriptions to Visual Studio Professional for $45 a month. I suggest we start directing resources towards a transition. I imagine all work to accomplish this could be done within a year, and by next April 1, the GHC development process will be almost unrecognizable from that today. Regards, Gershom From amindfv at gmail.com Sun Apr 1 05:28:01 2018 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 1 Apr 2018 01:28:01 -0400 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Overall this is a great proposal; glad we're finally modernizing! Still, it's got a pretty steep price tag - maybe we can offset costs with an I.C.O.? ("GHC Coin"?) > El 1 abr 2018, a las 00:56, Gershom B escribió: > > Fellow Haskellers, > > Recently there has been much work into creating a better and more > professional GHC development process, including in the form of DevOps > infrastructure, scheduled releases and governance, etc. But much > remains to be done. There continues to be concern about the lack of > use of industry-standard tools. For example, GHC development is tied > to Phabricator, which is a custom product originally developed for > in-house use by an obscure startup. GHC development is documented on a > wiki still -- ancient technology, not appropriate for 2018. Wiki > syntax for documentation needs to be replaced by the only modern > standard -- github flavored markdown. Trac itself is ancient > technology, dating to 2003, well before anybody knew how to program > real software. It provides no support for all the most important > aspects of software development -- Kanban boards, sprint management, > or even burndown charts. > > What is necessary is an integrated solution that holistically > addresses all aspects of development, fostering a DevOps culture, > embracing cloud-first, agile-first, test-first, disrupt-first > principles, and with an > ironclad SLA. Rather than homegrown solutions, we need a GHC > development process that utilizes tools and procedures already > familiar to regular developers. Cross-sectional feature comparison > analysis yields a clear front-runner -- Visual Studio Team Services. > > VSTS is a recognized Leader in the Gartner Magic Quadrant for > Enterprise Agile Planning tools. It lets us migrate from custom git > hosting to a more reliable source control system -- Team Foundation > Version Control. By enforcing the locking of checked-out files, we can > prevent the sorts of overlap between different patches that occur in > the current distributed version management system, and coordinate > tightly between developers, enabling and fostering T-shaped skills. > Team Build also lets us migrate from antiquated makefiles to modern, > industry-standard technology -- XML descriptions of build processes > that integrate automatically with tracking of PBIs (product backlog > items), and one-button release management. > > In terms of documentation, rather than deal with the subtleties of > different markdown implementations and the confusing world of > restructured text, we can utilize the full power of Word, including > SharePoint integration as well as Office 365 capabilities, and integration > with Microsoft Teams, the chat-based workspace for collaboration. This > enables much more effective cross-team collaboration with product and > marketing divisions. > > One of the most exciting features of VSTS is powerful extensibility, > with APIs offered in both major programming paradigms in use today -- > JVM and .NET. The core organizational principle for full application > lifecycle management is a single data construct -- the "work item" > which documentation informs us "represents a thing," which can be > anything that "a user can imagine." The power of work items comes > through their extensible XML representation. Work items are combined > into a Process Template, with such powerful Process Templates > available as Agile, Scrum, and CMMI. VSTS will also allow us to > analyze GHC Developer team performance with an integrated reporting > data warehouse that uses a cube. > > Pricing for up to 100 users is $750 a month. Individual developers can > also purchase subscriptions to Visual Studio Professional for $45 a > month. I suggest we start directing resources towards a transition. I > imagine all work to accomplish this could be done within a year, and > by next April 1, the GHC development process will be almost > unrecognizable from that today. > > Regards, > Gershom > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From kane at kane.cx Sun Apr 1 05:33:53 2018 From: kane at kane.cx (David Kraeutmann) Date: Sun, 01 Apr 2018 05:33:53 +0000 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: Leveraging the blockchain to compile GHC is a great idea! Unfortunately the proof-of-work algorithm is still just wasted cycles. On Sun, 1 Apr 2018, 07:28 , wrote: > Overall this is a great proposal; glad we're finally modernizing! Still, > it's got a pretty steep price tag - maybe we can offset costs with an > I.C.O.? ("GHC Coin"?) > > > > El 1 abr 2018, a las 00:56, Gershom B escribió: > > > > Fellow Haskellers, > > > > Recently there has been much work into creating a better and more > > professional GHC development process, including in the form of DevOps > > infrastructure, scheduled releases and governance, etc. But much > > remains to be done. There continues to be concern about the lack of > > use of industry-standard tools. For example, GHC development is tied > > to Phabricator, which is a custom product originally developed for > > in-house use by an obscure startup. GHC development is documented on a > > wiki still -- ancient technology, not appropriate for 2018. Wiki > > syntax for documentation needs to be replaced by the only modern > > standard -- github flavored markdown. Trac itself is ancient > > technology, dating to 2003, well before anybody knew how to program > > real software. It provides no support for all the most important > > aspects of software development -- Kanban boards, sprint management, > > or even burndown charts. > > > > What is necessary is an integrated solution that holistically > > addresses all aspects of development, fostering a DevOps culture, > > embracing cloud-first, agile-first, test-first, disrupt-first > > principles, and with an > > ironclad SLA. Rather than homegrown solutions, we need a GHC > > development process that utilizes tools and procedures already > > familiar to regular developers. Cross-sectional feature comparison > > analysis yields a clear front-runner -- Visual Studio Team Services. > > > > VSTS is a recognized Leader in the Gartner Magic Quadrant for > > Enterprise Agile Planning tools. It lets us migrate from custom git > > hosting to a more reliable source control system -- Team Foundation > > Version Control. By enforcing the locking of checked-out files, we can > > prevent the sorts of overlap between different patches that occur in > > the current distributed version management system, and coordinate > > tightly between developers, enabling and fostering T-shaped skills. > > Team Build also lets us migrate from antiquated makefiles to modern, > > industry-standard technology -- XML descriptions of build processes > > that integrate automatically with tracking of PBIs (product backlog > > items), and one-button release management. > > > > In terms of documentation, rather than deal with the subtleties of > > different markdown implementations and the confusing world of > > restructured text, we can utilize the full power of Word, including > > SharePoint integration as well as Office 365 capabilities, and > integration > > with Microsoft Teams, the chat-based workspace for collaboration. This > > enables much more effective cross-team collaboration with product and > > marketing divisions. > > > > One of the most exciting features of VSTS is powerful extensibility, > > with APIs offered in both major programming paradigms in use today -- > > JVM and .NET. The core organizational principle for full application > > lifecycle management is a single data construct -- the "work item" > > which documentation informs us "represents a thing," which can be > > anything that "a user can imagine." The power of work items comes > > through their extensible XML representation. Work items are combined > > into a Process Template, with such powerful Process Templates > > available as Agile, Scrum, and CMMI. VSTS will also allow us to > > analyze GHC Developer team performance with an integrated reporting > > data warehouse that uses a cube. > > > > Pricing for up to 100 users is $750 a month. Individual developers can > > also purchase subscriptions to Visual Studio Professional for $45 a > > month. I suggest we start directing resources towards a transition. I > > imagine all work to accomplish this could be done within a year, and > > by next April 1, the GHC development process will be almost > > unrecognizable from that today. > > > > Regards, > > Gershom > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > 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 capn.freako at gmail.com Sun Apr 1 14:28:17 2018 From: capn.freako at gmail.com (David Banas) Date: Sun, 1 Apr 2018 07:28:17 -0700 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development Message-ID: What a lovely idea! Might I suggest that, in making this change, we also adopt certain elements from both: - the Cult of Relevance, and - complex drama based managerial hierarchy, so as not to miss out on the wonderful benefits of those two features of modern hive mind development. So glad we’re finally ready to be brave in this new World, -db From itz at very.loosely.org Sun Apr 1 14:39:04 2018 From: itz at very.loosely.org (Ian Zimmerman) Date: Sun, 1 Apr 2018 07:39:04 -0700 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development In-Reply-To: References: Message-ID: <20180401143904.z73vtygiruq4qv4t@matica.foolinux.mooo.com> On 2018-04-01 00:56, Gershom B wrote: > by next April 1, the GHC development process will be almost > unrecognizable from that today. LOL -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com. From doug at cs.dartmouth.edu Sun Apr 1 15:15:12 2018 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sun, 01 Apr 2018 11:15:12 -0400 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development Message-ID: <201804011515.w31FFCdB125432@tahoe.cs.Dartmouth.EDU> Gershom, An emergent team-building solution (with or without an enabling blockchain protection ring) is all very well, but is it monadic? Doug From mail at nh2.me Sun Apr 1 15:16:34 2018 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Sun, 1 Apr 2018 17:16:34 +0200 Subject: [Haskell-cafe] Haskell mailing list etiquette Message-ID: Dear mailing list participants, I recently discovered a document that contains, neatly enumerated, all the rules that we as a community follow today when discussing Haskell topics. Please direct Haskell newcomers to it as early as possible, so that they can learn our mode of working upfront, and don't have to discover it bit by bit. For everybody's convenience, I here are the key points: * When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible. * Bring up irrelevant issues as frequently as possible. * Ask endless questions or engage in long correspondence about such orders. Quibble over them when you can. * Haggle over precise wordings of communications, minutes, resolutions. * Refer back to matters decided upon at the last meeting and attempt to re-open the question of the advisability of that decision. * Advocate "caution". Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on. * Be worried about the propriety of any decision - raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon. You can find the full list of rules here (refer to page 28): https://www.cia.gov/news-information/featured-story-archive/2012-featured-story-archive/CleanedUOSSSimpleSabotage_sm.pdf Best, Niklas From spam at scientician.net Sun Apr 1 17:24:55 2018 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 1 Apr 2018 19:24:55 +0200 Subject: [Haskell-cafe] Haskell mailing list etiquette In-Reply-To: References: Message-ID: On 2018-04-01 17:16, Niklas Hambüchen wrote: [--snip--] > For everybody's convenience, I here are the key points: > > * When possible, refer all matters to committees, for "further study and > consideration." Attempt to make the committees as large as possible. > > * Bring up irrelevant issues as frequently as possible. > Yes, but what about the children? > * Ask endless questions or engage in long correspondence about such > orders. Quibble over them when you can. > Well, my story begins in nineteen dickety-two... > * Haggle over precise wordings of communications, minutes, resolutions. > That last comma should be "and". > * Refer back to matters decided upon at the last meeting and attempt to > re-open the question of the advisability of that decision. > I don't we ever decided upon that rule. Can someone re-check the archives? > * Advocate "caution". Be "reasonable" and urge your fellow-conferees to > be "reasonable" and avoid haste which might result in embarrassments or > difficulties later on. > No real isssue with this, but I feel it might be a bit rash. > * Be worried about the propriety of any decision - raise the question of > whether such action as is contemplated lies within the jurisdiction of > the group or whether it might conflict with the policy of some higher > echelon. > I definite agree that we need guidelines in this area and I propose that we form a committe to evaluate this proposal and further counter-proposals that may arise. I'm thinking something along the lines of the Literature Prize winner at https://www.improbable.com/ig/winners/#ig2012 Regards, From ben at well-typed.com Sun Apr 1 21:05:29 2018 From: ben at well-typed.com (Ben Gamari) Date: Sun, 01 Apr 2018 17:05:29 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available Message-ID: <87in9afxij.fsf@smart-cactus.org> Hello everyone, The GHC team is proud to announce the first release candidate of 8.4.2. the source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.4.2-rc1 This release follows so closely to 8.4.1 due to a number last-minute bug-fixes that didn't quite make it into 8.4.1. This includes fixes for: * #14705, the interpreter being broken on some systems * #14779, where the compiler produces invalid code when used with -g * #14891, where a selection of GHC testsuite cases fail on OS X * #5129, where the simplifier would incorrectly reorder evaluation in under some conditions. Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. Happy testing Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From gershomb at gmail.com Mon Apr 2 00:53:48 2018 From: gershomb at gmail.com (Gershom B) Date: Sun, 1 Apr 2018 20:53:48 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: <87in9afxij.fsf@smart-cactus.org> References: <87in9afxij.fsf@smart-cactus.org> Message-ID: Thanks for the announcement, Ben. Since cabal-install 2.2 was just released, we were planning a new Haskell Platform release Any Day Now (tm). But given the impending 8.4.2 release, I think we will hold off until it lands. Cheers, Gershom On April 1, 2018 at 5:07:35 PM, Ben Gamari (ben at well-typed.com) wrote: Hello everyone, The GHC team is proud to announce the first release candidate of 8.4.2. the source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.4.2-rc1 This release follows so closely to 8.4.1 due to a number last-minute bug-fixes that didn't quite make it into 8.4.1. This includes fixes for: * #14705, the interpreter being broken on some systems * #14779, where the compiler produces invalid code when used with -g * #14891, where a selection of GHC testsuite cases fail on OS X * #5129, where the simplifier would incorrectly reorder evaluation in under some conditions. Since this is a relatively small bugfix release we are bypassing the alpha releases and moving right to the release candidate stage. If all goes well the final release will be cut next week. Happy testing Cheers, - Ben _______________________________________________ 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 tanuki at gmail.com Mon Apr 2 03:28:12 2018 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Mon, 02 Apr 2018 03:28:12 +0000 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development In-Reply-To: <201804011515.w31FFCdB125432@tahoe.cs.Dartmouth.EDU> References: <201804011515.w31FFCdB125432@tahoe.cs.Dartmouth.EDU> Message-ID: This is a timely and welcome proposal, as my agile startup intends to deploy Haskell to production within the month! The small price of migrating to a VS-centric workflow is well worth it; in my view, we must embrace success at all cost. On Sun, Apr 1, 2018, 8:16 AM Doug McIlroy wrote: > Gershom, > > An emergent team-building solution (with or without an enabling blockchain > protection ring) is all very well, but is it monadic? > > Doug > _______________________________________________ > 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 mgajda at mimuw.edu.pl Mon Apr 2 06:17:26 2018 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Mon, 02 Apr 2018 06:17:26 +0000 Subject: [Haskell-cafe] json-autotype 1.1.2, and type-providers initiative Message-ID: Hi, I am pleased to announce new version of json-autotype. Highlights of the version: 1. GHC 8.4 support. 2. Preliminary support for Elm output (with more Haskell-family languages coming) 3. Peter Simons has joined the team as official maintainer. 4. Ask us anything on Gitter: https://gitter.im/dataHaskell/json-autotype Json-Autotype team, and Data Haskell Frames team is also pleased to announce `type-providers` initiative that aims to provide standard API for type providers for Haskell family of languages. (Please join us on Gitter: https://gitter.im/dataHaskell/type-providers and https://gitter.im/dataHaskell/DataFrames) -- Cheers Michal J. Gajda -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at gonimo.com Mon Apr 2 14:18:51 2018 From: robert at gonimo.com (Robert Klotzner) Date: Mon, 2 Apr 2018 16:18:51 +0200 Subject: [Haskell-cafe] Architecture for reflex based applications Message-ID: Hi there! I did a little write up about structuring reflex applications, which seems to work out really well for me. Check it out here: https://github.com/gonimo/gonimo/blob/master/front/doc/Gonimo-Architecture.md I would love to hear your thoughts! Best regards, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ben at well-typed.com Mon Apr 2 22:15:04 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 02 Apr 2018 18:15:04 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2-rc1 now available In-Reply-To: References: <87in9afxij.fsf@smart-cactus.org> Message-ID: <87370dfe71.fsf@smart-cactus.org> Gershom B writes: > Thanks for the announcement, Ben. Since cabal-install 2.2 was just > released, we were planning a new Haskell Platform release Any Day Now > (tm). But given the impending 8.4.2 release, I think we will hold off > until it lands. > Yes, I think that is probably best; 8.4.1 is just broken enough that I would prefer if we would avoid pushing it out any more widely than necessary. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From capn.freako at gmail.com Tue Apr 3 02:16:16 2018 From: capn.freako at gmail.com (David Banas) Date: Mon, 2 Apr 2018 19:16:16 -0700 Subject: [Haskell-cafe] vector-sized: (//) Finites to Ints? Message-ID: <20995CBF-0BD2-4DD4-BDC9-010C569E017D@gmail.com> When did the vector-sized (//) operator change from expecting Finites to expecting Ints? From timotomandl at gmail.com Tue Apr 3 03:36:35 2018 From: timotomandl at gmail.com (Timotej Tomandl) Date: Tue, 3 Apr 2018 04:36:35 +0100 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? Message-ID: Hello, So we need rank-2 type in runST :: (forall s. ST s a) -> a, to prevent s from appearing in a. I have been thinking about this for a bit, but I failed to come up with a practical situation, where rank-3 types are necessary for safety of some abstraction. The rank-3 example in here and any other I found, look very synthetic, i.e. limiting computation to id: https://ocharles.org.uk/blog/guest-posts/2014-12-18-rank-n-types.html and compared to the runST example of limiting a scope of a type variable for purposes of safety looks unnatural. Could anyone please point me to a practical example of rank-3 polymorphism, where it is necessary for safety of an abstraction, if it exists? I suspect there is a situation, where rank-3 is necessary for maintaining abstration exists, but I can't think of any. Any ideas about such situations and even better situations where this is used on hackage? Timotej Tomandl -------------- next part -------------- An HTML attachment was scrubbed... URL: From timotomandl at gmail.com Tue Apr 3 06:54:20 2018 From: timotomandl at gmail.com (Timotej Tomandl) Date: Tue, 3 Apr 2018 07:54:20 +0100 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: Message-ID: Ok, I thought about it a bit more and realized mask in Control.Exception is the one where rank-3 is necessary, which is the example I was looking for. Sorry for the spam. On Tue, Apr 3, 2018 at 4:36 AM, Timotej Tomandl wrote: > Hello, > > So we need rank-2 type in runST :: (forall s. ST > > s a) -> a, to prevent s from appearing in a. > > I have been thinking about this for a bit, but I failed to come up with a > practical situation, where rank-3 types are necessary for safety of some > abstraction. > > The rank-3 example in here and any other I found, look very synthetic, > i.e. limiting computation to id: > https://ocharles.org.uk/blog/guest-posts/2014-12-18-rank-n-types.html > and compared to the runST example of limiting a scope of a type variable > for purposes of safety looks unnatural. > Could anyone please point me to a practical example of rank-3 > polymorphism, where it is necessary for safety of an abstraction, if it > exists? > > I suspect there is a situation, where rank-3 is necessary for maintaining > abstration exists, but I can't think of any. > Any ideas about such situations and even better situations where this is > used on hackage? > > Timotej Tomandl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Tue Apr 3 07:11:04 2018 From: publicityifl at gmail.com (Jurriaan Hage) Date: Tue, 3 Apr 2018 09:11:04 +0200 Subject: [Haskell-cafe] 2nd CfP: IFL 2018 (30th Symposium on Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the second call for papers for IFL 2018. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2018 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speakers * Adam Chlipala, Massachusetts Institute of Technology CSAIL * Arjun Guha, University of Massachusetts Amherst ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 25, 2018 Submission of draft papers: July 17, 2018 Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargueraud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coruna, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL is organized by the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slucas at dsic.upv.es Tue Apr 3 07:02:38 2018 From: slucas at dsic.upv.es (Salvador Lucas) Date: Tue, 3 Apr 2018 09:02:38 +0200 Subject: [Haskell-cafe] WST 2018 - 2nd Call for Papers (submission: April 15, 2018) Message-ID: ==========================================================================                           WST 2018 - Call for Papers                    16th International Workshop on Termination                     July 18-19, 2017, Oxford, United Kingdom                           http://wst2018.webs.upv.es/ ========================================================================== The Workshop on Termination (WST) traditionally brings together, in an informal setting, researchers interested in all aspects of termination, whether this interest be practical or theoretical, primary or derived. The workshop also provides a ground for cross-fertilization of ideas from the different communities interested in termination (e.g., working on computational mechanisms, programming languages, software engineering, constraint solving, etc.). The friendly atmosphere enables fruitful exchanges leading to joint research and subsequent publications. The workshop is held as part of the 2018 Federated Logic Conference (FLoC 2018)           http://www.floc2018.org/ IMPORTANT DATES:  * submission deadline:  April 15, 2018  * notification:         May 15, 2018  * final version due:    May 31, 2018  * workshop:             July 18-19, 2018 TOPICS: The 16th International Workshop on Termination welcomes contributions on all aspects of termination. In particular, papers investigating applications of termination (for example in complexity analysis, program analysis and transformation, theorem proving, program correctness, modeling computational systems, etc.) are very welcome. Topics of interest include (but are not limited to):  * abstraction methods in termination analysis  * certification of termination and complexity proofs  * challenging termination problems  * comparison and classification of termination methods  * complexity analysis in any domain  * implementation of termination methods  * non-termination analysis and loop detection  * normalization and infinitary normalization  * operational termination of logic-based systems  * ordinal notation and subrecursive hierarchies  * SAT, SMT, and constraint solving for (non-)termination analysis  * scalability and modularity of termination methods  * termination analysis in any domain (lambda calculus, declarative    programming, rewriting, transition systems, etc.)  * well-founded relations and well-quasi-orders COMPETITION: Since 2003, the catalytic effect of WST to stimulate new research on termination has been enhanced by the celebration of the Termination Competition and its continuously developing problem databases containing thousands of programs as challenges for termination analysis in different categories, see    http://termination-portal.org/wiki/Termination_Competition In 2018, the Termination Competition will run in parallel with FLoC 2018. More details will be provided in a dedicated announcement on the competition. PROGRAM COMMITTEE:     Cristina Borralleras - U. de Vic     Ugo Dal Lago - U. degli Studi di Bologna     Carsten Fuhs - Birkbeck, U. of London     Samir Genaim - U. Complutense de Madrid     Juergen Giesl - RWTH Aachen     Raul Gutiérrez - U. Politecnica de València     Keiichirou Kusakari - Gifu University     Salvador Lucas (chair) - U. Politecnica de Valencia     Fred Mesnard - U. de La Reunion     Aart Middeldorp - U. of Innsbruck     Albert Rubio - U. Politecnica de Catalunya     Rene Thiemann - U. of Innsbruck     Caterina Urban - ETH Zürich INVITED SPEAKERS:     tba SUBMISSION: Submissions are short papers/extended abstracts which should not exceed 5 pages. There will be no formal reviewing. In particular, we welcome short versions of recently published articles and papers submitted elsewhere. The program committee checks relevance and provides additional feedback for each submission. The accepted papers will be made available electronically before the workshop. Papers should be submitted electronically via the submission page:     https://easychair.org/conferences/?conf=wst2018 Please, use LaTeX and the LIPIcs style file     http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz to prepare your submission. From jo at durchholz.org Tue Apr 3 08:04:16 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 3 Apr 2018 10:04:16 +0200 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: Message-ID: <4759904d-9a9d-f995-24f0-ed38f74830d7@durchholz.org> Am 03.04.2018 um 08:54 schrieb Timotej Tomandl: > Ok, I thought about it a bit more and realized mask in Control.Exception > is the one where rank-3 is necessary, which is the example I was looking > for. Given your newly acquired insights, do you expect that there will be ultimately a valid example for higher ranks? Is there a theoretical limit? Or a practical one? E.g. it might be too awkward to mentally handle higher-rank polymorphism - or maybe there's no real mental difference when dealing with higher-ranked polymorphism, I don't know because I didn't have to deal with that yet, so I'm curious. > Sorry for the spam. Actually it was interesting. Regards, Jo From rpglover64 at gmail.com Tue Apr 3 15:10:56 2018 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Tue, 03 Apr 2018 15:10:56 +0000 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: <4759904d-9a9d-f995-24f0-ed38f74830d7@durchholz.org> References: <4759904d-9a9d-f995-24f0-ed38f74830d7@durchholz.org> Message-ID: There's an easy to read paper by Okasaki titled "Even higher-order functions for parsing or Why would anyone ever want to use a sixth-order function?". Unfortunatly I can't find a link to a non-paywalled version. It shows how parser combinators themselves use rank-3 types and how defining a monad instance requires rank-6. On Tue, Apr 3, 2018 at 1:05 AM Joachim Durchholz wrote: > Am 03.04.2018 um 08:54 schrieb Timotej Tomandl: > > Ok, I thought about it a bit more and realized mask in Control.Exception > > is the one where rank-3 is necessary, which is the example I was looking > > for. > > Given your newly acquired insights, do you expect that there will be > ultimately a valid example for higher ranks? > Is there a theoretical limit? > Or a practical one? E.g. it might be too awkward to mentally handle > higher-rank polymorphism - or maybe there's no real mental difference > when dealing with higher-ranked polymorphism, I don't know because I > didn't have to deal with that yet, so I'm curious. > > > Sorry for the spam. > > Actually it was interesting. > > Regards, > Jo > _______________________________________________ > 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 hesselink at gmail.com Tue Apr 3 16:30:12 2018 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 3 Apr 2018 18:30:12 +0200 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: <4759904d-9a9d-f995-24f0-ed38f74830d7@durchholz.org> Message-ID: The paper is here [1]. However, this is a sixth order function but not rank-6 polymorphism (rank 6 type) IIUC. Erik [1] https://www.westpoint.edu/eecs/SiteAssets/SitePages/ Faculty%20Publication%20Documents/Okasaki/jfp98sixth.pdf On 3 April 2018 at 17:10, Alex Rozenshteyn wrote: > There's an easy to read paper by Okasaki titled "Even higher-order > functions for parsing or Why would anyone ever want to use a sixth-order > function?". Unfortunatly I can't find a link to a non-paywalled version. It > shows how parser combinators themselves use rank-3 types and how defining a > monad instance requires rank-6. > > > On Tue, Apr 3, 2018 at 1:05 AM Joachim Durchholz wrote: > >> Am 03.04.2018 um 08:54 schrieb Timotej Tomandl: >> > Ok, I thought about it a bit more and realized mask in Control.Exception >> > is the one where rank-3 is necessary, which is the example I was looking >> > for. >> >> Given your newly acquired insights, do you expect that there will be >> ultimately a valid example for higher ranks? >> Is there a theoretical limit? >> Or a practical one? E.g. it might be too awkward to mentally handle >> higher-rank polymorphism - or maybe there's no real mental difference >> when dealing with higher-ranked polymorphism, I don't know because I >> didn't have to deal with that yet, so I'm curious. >> >> > Sorry for the spam. >> >> Actually it was interesting. >> >> Regards, >> Jo >> _______________________________________________ >> 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 rpglover64 at gmail.com Tue Apr 3 16:49:30 2018 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Tue, 03 Apr 2018 16:49:30 +0000 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: <4759904d-9a9d-f995-24f0-ed38f74830d7@durchholz.org> Message-ID: Ah. My misrecollection. In that case, the highest rank example I can find is in "Practical type inference for arbitrary-rank types", and it's rank-3. On Tue, Apr 3, 2018, 09:30 Erik Hesselink wrote: > The paper is here [1]. However, this is a sixth order function but not > rank-6 polymorphism (rank 6 type) IIUC. > > Erik > > [1] > https://www.westpoint.edu/eecs/SiteAssets/SitePages/Faculty%20Publication%20Documents/Okasaki/jfp98sixth.pdf > > On 3 April 2018 at 17:10, Alex Rozenshteyn wrote: > >> There's an easy to read paper by Okasaki titled "Even higher-order >> functions for parsing or Why would anyone ever want to use a sixth-order >> function?". Unfortunatly I can't find a link to a non-paywalled version. It >> shows how parser combinators themselves use rank-3 types and how defining a >> monad instance requires rank-6. >> >> >> On Tue, Apr 3, 2018 at 1:05 AM Joachim Durchholz >> wrote: >> >>> Am 03.04.2018 um 08:54 schrieb Timotej Tomandl: >>> > Ok, I thought about it a bit more and realized mask in >>> Control.Exception >>> > is the one where rank-3 is necessary, which is the example I was >>> looking >>> > for. >>> >>> Given your newly acquired insights, do you expect that there will be >>> ultimately a valid example for higher ranks? >>> Is there a theoretical limit? >>> Or a practical one? E.g. it might be too awkward to mentally handle >>> higher-rank polymorphism - or maybe there's no real mental difference >>> when dealing with higher-ranked polymorphism, I don't know because I >>> didn't have to deal with that yet, so I'm curious. >>> >>> > Sorry for the spam. >>> >>> Actually it was interesting. >>> >>> Regards, >>> Jo >>> _______________________________________________ >>> 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 gab at cin.ufpe.br Tue Apr 3 23:12:18 2018 From: gab at cin.ufpe.br (Gabriela Araujo Britto) Date: Tue, 3 Apr 2018 20:12:18 -0300 Subject: [Haskell-cafe] Database of real faults Message-ID: Hi, I'd like to know if there exists a database of reproducible real faults in Haskell software, along the lines of defects4j (https://github.com/rjust/ defects4j/), or a related initiative. My intention is to use this for research in mutation testing. Thank you, Gabriela -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Apr 4 03:35:35 2018 From: david.feuer at gmail.com (David Feuer) Date: Wed, 04 Apr 2018 03:35:35 +0000 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: Message-ID: Take a look at this PR: https://github.com/haskell/primitive/pull/109/files The heterogeneous array creation functions I propose take rank-2 traversal functions as arguments and are therefore rank-3. In this case, the reason is a bit boring: the package in question can't depend on either (any?) of the packages offering rank-2 versions of Traversable. On Tue, Apr 3, 2018, 6:37 AM Timotej Tomandl wrote: > Hello, > > So we need rank-2 type in runST :: (forall s. ST > > s a) -> a, to prevent s from appearing in a. > > I have been thinking about this for a bit, but I failed to come up with a > practical situation, where rank-3 types are necessary for safety of some > abstraction. > > The rank-3 example in here and any other I found, look very synthetic, > i.e. limiting computation to id: > https://ocharles.org.uk/blog/guest-posts/2014-12-18-rank-n-types.html > and compared to the runST example of limiting a scope of a type variable > for purposes of safety looks unnatural. > Could anyone please point me to a practical example of rank-3 > polymorphism, where it is necessary for safety of an abstraction, if it > exists? > > I suspect there is a situation, where rank-3 is necessary for maintaining > abstration exists, but I can't think of any. > Any ideas about such situations and even better situations where this is > used on hackage? > > Timotej Tomandl > _______________________________________________ > 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 ekmett at gmail.com Wed Apr 4 05:38:24 2018 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 4 Apr 2018 01:38:24 -0400 Subject: [Haskell-cafe] Where are rank-3 types necessary in practice for maintaining abstraction? In-Reply-To: References: Message-ID: The proper type for callCC would be rank-3. The current form is an under-approximation that only allows you to choose to use the continuation at one type. Going higher rank (usefully) is still pretty straight-forward. There is the Mendler-style encoding of functors that gets used every once in a while in recursion-schemes work. It adds a rank to get rid of a Functor constraint. This is basically replacing a functor f with (forall b. (a -> b) -> f b), which is the same as the Yoneda f a newtype. For more information, see some of the lovely examples in https://www.ioc.ee/~tarmo/papers/msfp08.pdf like update :: (forall c’. (forall y’. (y’ -> c’) -> (y’ -> Mu f) -> f y’ -> c’) -> y -> c’) -> (Mu f -> c) -> (forall c’. (forall y’. (y’ -> c) -> (y’ -> c’) -> f y’ -> c’) -> y -> c’) -Edward On Mon, Apr 2, 2018 at 11:36 PM, Timotej Tomandl wrote: > Hello, > > So we need rank-2 type in runST :: (forall s. ST > > s a) -> a, to prevent s from appearing in a. > > I have been thinking about this for a bit, but I failed to come up with a > practical situation, where rank-3 types are necessary for safety of some > abstraction. > > The rank-3 example in here and any other I found, look very synthetic, > i.e. limiting computation to id: > https://ocharles.org.uk/blog/guest-posts/2014-12-18-rank-n-types.html > and compared to the runST example of limiting a scope of a type variable > for purposes of safety looks unnatural. > Could anyone please point me to a practical example of rank-3 > polymorphism, where it is necessary for safety of an abstraction, if it > exists? > > I suspect there is a situation, where rank-3 is necessary for maintaining > abstration exists, but I can't think of any. > Any ideas about such situations and even better situations where this is > used on hackage? > > Timotej Tomandl > > _______________________________________________ > 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 brucker at spamfence.net Wed Apr 4 13:59:00 2018 From: brucker at spamfence.net (Achim D. Brucker) Date: Wed, 4 Apr 2018 14:59:00 +0100 Subject: [Haskell-cafe] ThEdu'18: Second Call for Extended Abstracts & Demonstrations Message-ID: <20180404135900.pvov326sxs2aksaj@kandagawa.home.brucker.ch> (Apologies for duplicates) 2nd Call for Extended Abstracts & Demonstrations ************************************************************************** ThEdu'18 Theorem proving components for Educational software 18 July 2018 http://www.uc.pt/en/congressos/thedu/thedu18 ************************************************************************** affiliated to IJCAR 2018 July 14-17, 2018 Oxford, United Kingdom http://www.ijcar2018.org/ (part of FLoC 2018) ************************************************************************** THedu'18 Scope: Computer Theorem Proving is becoming a paradigm as well as a technological base for a new generation of educational software in science, technology, engineering and mathematics. The workshop brings together experts in automated deduction with experts in education in order to further clarify the shape of the new software generation and to discuss existing systems. Invited Talk Julien Narboux, University of Strasbourg, France Important Dates * Extended Abstracts: 15th April 2018 * Author Notification: 15th May 2018 * Workshop Day: 18 July 2018 Topics of interest include: * methods of automated deduction applied to checking students' input; * methods of automated deduction applied to prove post-conditions for particular problem solutions; * combinations of deduction and computation enabling systems to propose next steps; * automated provers specific for dynamic geometry systems; * proof and proving in mathematics education. Submission We welcome submission of extended abstracts and demonstration proposals presenting original unpublished work which is not been submitted for publication elsewhere. All accepted extended abstracts and demonstrations will be presented at the workshop. The extended abstracts will be made available online. Extended abstracts and demonstration proposals should be submitted via easychair, https://easychair.org/conferences/?conf=thedu18 formatted according to http://www.easychair.org/publications/easychair.zip Extended abstracts and demonstration proposals should be approximately 5 pages in length and are to be submitted in PDF format. At least one author of each accepted extended abstract/demonstration proposal is expected to attend THedu'18 and presents his/her extended abstract/demonstration. Program Committee Francisco Botana, University of Vigo at Pontevedra, Spain Roman Hašek, University of South Bohemia, Czech Republic Filip Maric, University of Belgrade, Serbia Walther Neuper, Graz University of Technology, Austria (co-chair) Pavel Pech, University of South Bohemia, Czech Republic Pedro Quaresma, University of Coimbra, Portugal (co-chair) Vanda Santos, CISUC, Portugal Wolfgang Schreiner, Johannes Kepler University, Austria Burkhart Wolff, University Paris-Sud, France Proceedings The extended abstracts and system descriptions will be available in ThEdu'18 Web-page. After presentation at the conference, selected authors will be invited to submit a substantially revised version, extended to 14--20 pages, for publication by the Electronic Proceedings in Theoretical Computer Science (EPTCS). -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From guillaumh at gmail.com Wed Apr 4 14:56:40 2018 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Wed, 4 Apr 2018 11:56:40 -0300 Subject: [Haskell-cafe] [ANN] Darcs 2.14.0 release Message-ID: Hi all, The Darcs team is pleased to announce the release of Darcs 2.14.0! Darcs is a free, open source revision control system. It is: * Distributed: Every user has access to the full command set, removing boundaries between server and client or committer and non-committers. * Interactive: Darcs is easy to learn and efficient to use because it asks you questions in response to simple commands, giving you choices in your work flow. You can choose to record one change in a file, while ignoring another. As you update from upstream, you can review each patch name, even the full "diff" for interesting patches. * Smart: Originally developed by physicist David Roundy, darcs is based on a unique algebra of patches. Learn more about Darcs on http://darcs.net . # Supported GHC and Cabal versions Darcs 2.14 can be compiled with GHC 8.0, 8.2 and 8.4, and supports Cabal versions from 1.24. # Windows issues Darcs 2.14 received many updates in its support of encoding. However, it may still contain bugs, especially under Windows, a platform for which we have fewer known users. Please let us know if you encounter weird behaviour under Windows. # What's new # ## User Interface ## - fix encoding business, make DARCS_DONT_ESCAPE_8BIT=1 default (Ben Franksen, Ganesh Sittampalam) - show explicit dependencies in `darcs log -s` (Gian Piero Carrubba) - improve bash/zsh completion (Ben, Gian Piero) - no longer print an error message when ctrlc'ing pager (Guillaume Hoffmann) - `darcs help markdown` mentions all files in `_darcs/prefs/` (Guillaume) - add patch index status to `show repo` command (Ben) ## New features ## - per-file conflict marking (Ben) - make it possible to use DARCS_SCP=rsync (Ben) - add --not-in-remote option to unrecord command (Ben) ## Performance ## - plug memory leak and improve efficiency in annotate (Ben) - save unneeded FL/RL reverses in SelectChanges module (Ben) - optimize token replace code and --look-for-replaces (Ben) - no longer show conflicting files on `whatsnew -s`, will reintrodue this feature when it is done efficiently (Guillaume) ## Developer-related ## - separate display and storage of patches (Ben) - support GHC 8.2 and GHC 8.4 (Ganesh) - many refactorings in Darcs.Repository modules and API (Ben, Guillaume) - no longer track build dependencies in Setup.hs, nor use alpha, beta, rc names (Guillaume) - refactor `pull --reorder-patches` (Ben) - refactor SelectChanges (Ben) - remove Patchy typeclass and redundant constaints where possible (Guillaume) - fix build with cabal new-build (Francesco Ariis) - unit and quickcheck tests for inventories (Ben) - throw out all access to bytestring internals from Darcs.Util.ByteString (Ben) - refactor, simplify, and document hunk application (Ben) - drop support of old cache location and SHA1-hashed repos (Guillaume) - rely on GHC's own stack traces for bug reporting (Guillaume) ## Issues resolved in Darcs 2.14 ## - fix mail encoding with '.' or '=' as last character (Timo von Holtz) - issue2526: whatsnew -l --boring should list boring files (Ben) - issue2208: replace detects existing force hunks in working (Ben) - issue2512: author name is written to repository after multiple-choice prompt (Stephan-A. Posselt) - issue2359: convert --export mishandles Unicode filenames (Ben) - issue2545: prevent argument smuggling in SSH repository URLs (Gian Piero) - issue2581: fix rebase pull --reorder (Ben) - issue2575: fix unrevert with rebase (Ben) - issue2579: allow darcs send to work even if no MTA is installed - issue2555: include explicit dependencies in the output of `log -v` (Gian Piero) - issue2569: decoding multibyte characters (Ben) - issue2563: create remote repo in correct format in ssh tests (Ben) - issue2565: create _darcs dir after searching for an existing one (Ben) - issue2567: darcs whatsnew --unified (Ben) - issue2566: avoid renaming across file systems (Ben) - issue2564: delete wrong and irrelevant propConcatPS (Guillaume) - issue2559: remove trailing empty lines in patch header edition (Guillaume) - issue2536: mask out internal matchers in `show files` routing logic (Gian Piero) From travis at anduril.com Thu Apr 5 05:01:58 2018 From: travis at anduril.com (Travis Whitaker) Date: Wed, 4 Apr 2018 22:01:58 -0700 Subject: [Haskell-cafe] [Haskell, FP] Anduril Industries is Hiring Message-ID: Anduril Industries (https://www.anduril.com) is hiring. TL;DR: Come write Haskell, Rust, and Nix (and some C++ when necessary) to make autonomous robots and drones go! We're a team of software and hardware engineers from various backgrounds (game development, computer graphics, financial technology, government intelligence, biotechnology) working to improve the state of defense technology. Our strategy involves focusing on product development instead of traditional governmental processes. By funding product development ourselves instead of relying on government funds, we're able to create more focused products faster and with significantly fewer resources. By leveraging hardware and techniques that have only recently become feasible to deploy at scale (e.g. GPGPU computing), we can significantly advance the state of the defense technology market. We're searching for generally competent, mathematically inclined software engineers, and we're especially interested in those with experience in computer vision (first principles techniques and machine learning), sensor fusion, detection and tracking, and statistical parameter estimation. Our team is increasingly applying functional programming and related technologies; we run Haskell and Rust code in production and use Nix to achieve reproducible build environments and keep deployment, CI, and cross-compilation sane. If you like functional programming, interfacing with hardware, and solving problems in detection, tracking, and autonomous vehicle control (land and air), drop me a line at travis at anduril.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Apr 5 05:33:28 2018 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 5 Apr 2018 15:33:28 +1000 Subject: [Haskell-cafe] [Haskell] [Haskell, FP] Anduril Industries is Hiring In-Reply-To: References: Message-ID: Hi Travis, It would be helpful if you said a) where this was and b) if remote work is possible. On 5 April 2018 at 15:01, Travis Whitaker wrote: > Anduril Industries (https://www.anduril.com) is hiring. TL;DR: Come write > Haskell, Rust, and Nix (and some C++ when necessary) to make autonomous > robots and drones go! > > We're a team of software and hardware engineers from various backgrounds > (game development, computer graphics, financial technology, government > intelligence, biotechnology) working to improve the state of defense > technology. Our strategy involves focusing on product development instead of > traditional governmental processes. By funding product development ourselves > instead of relying on government funds, we're able to create more focused > products faster and with significantly fewer resources. By leveraging > hardware and techniques that have only recently become feasible to deploy at > scale (e.g. GPGPU computing), we can significantly advance the state of the > defense technology market. > > We're searching for generally competent, mathematically inclined software > engineers, and we're especially interested in those with experience in > computer vision (first principles techniques and machine learning), sensor > fusion, detection and tracking, and statistical parameter estimation. Our > team is increasingly applying functional programming and related > technologies; we run Haskell and Rust code in production and use Nix to > achieve reproducible build environments and keep deployment, CI, and > cross-compilation sane. > > If you like functional programming, interfacing with hardware, and solving > problems in detection, tracking, and autonomous vehicle control (land and > air), drop me a line at travis at anduril.com > > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From zocca.marco at gmail.com Thu Apr 5 10:17:37 2018 From: zocca.marco at gmail.com (Marco Zocca) Date: Thu, 5 Apr 2018 12:17:37 +0200 Subject: [Haskell-cafe] DataHaskell User Survey Message-ID: Dear all, the community around datahaskell.org has been slowly but steadily growing since its inception in 2016, and with it the diversity of its members. Its mission is to provide a home for data science and numerical computation students and practitioners who would like to use Haskell in their work and explorations. In order to best represent and serve the community, we'd like to know it in the first place, which is why we have prepared this little questionnaire (10 questions, which should take around 5 minutes to complete): https://www.surveymonkey.com/r/3FBBJWR No personal data are required and the results will only be published in aggregate form at a later stage. The raw data will only be stored and used for producing the aggregate report, after which it will be deleted. Thank you in advance for your time; Best, Marco Zocca github.com/ocramz hackage.haskell.org/user/ocramz From carter.schonwald at gmail.com Thu Apr 5 16:24:34 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 5 Apr 2018 12:24:34 -0400 Subject: [Haskell-cafe] Proposal: Professionalizing GHC Development In-Reply-To: <201804011515.w31FFCdB125432@tahoe.cs.Dartmouth.EDU> References: <201804011515.w31FFCdB125432@tahoe.cs.Dartmouth.EDU> Message-ID: categorically so! :) On Sun, Apr 1, 2018 at 11:15 AM, Doug McIlroy wrote: > Gershom, > > An emergent team-building solution (with or without an enabling blockchain > protection ring) is all very well, but is it monadic? > > Doug > _______________________________________________ > 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 dennis.raddle at gmail.com Thu Apr 5 18:06:56 2018 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 5 Apr 2018 11:06:56 -0700 Subject: [Haskell-cafe] downgrading GHC version on a Mac Message-ID: I'm on a MacBook Pro. I'm not very familiar with software installation. Up until now I've been using Stack for GHC work, and it seems to take care of having the right version of GHC. Now I'm going to use GHCJS, and I need to have a system GHC installed (I believe). At some point in the past I installed the Haskell Platform for Mac, and I have GHC 8.01. But I want to downgrade that to 7.10 so that I don't have to worry about compatibility with GHCJS. How do I go about uninstalling GHC 8 and installing 7.10 in its place? Can I use Homebrew? D -------------- next part -------------- An HTML attachment was scrubbed... URL: From parsonsmatt at gmail.com Thu Apr 5 18:13:57 2018 From: parsonsmatt at gmail.com (Matt) Date: Thu, 5 Apr 2018 12:13:57 -0600 Subject: [Haskell-cafe] downgrading GHC version on a Mac In-Reply-To: References: Message-ID: I do not have a system GHC installed. For tools that need it (eg cabal), I have an alias `stack-shell` that does `stack exec --no-ghc-package-path zsh`. You can use that, with a given resolver (that corresponds to the GHC version you want) to have a shell open with the GHC you want to use available "globally." I find that this keeps things clean and easy to understand. Matt Parsons On Thu, Apr 5, 2018 at 12:06 PM, Dennis Raddle wrote: > I'm on a MacBook Pro. I'm not very familiar with software installation. > > Up until now I've been using Stack for GHC work, and it seems to take care > of having the right version of GHC. > > Now I'm going to use GHCJS, and I need to have a system GHC installed (I > believe). At some point in the past I installed the Haskell Platform for > Mac, and I have GHC 8.01. But I want to downgrade that to 7.10 so that I > don't have to worry about compatibility with GHCJS. > > How do I go about uninstalling GHC 8 and installing 7.10 in its place? Can > I use Homebrew? > > D > > _______________________________________________ > 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 dennis.raddle at gmail.com Thu Apr 5 19:41:38 2018 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 5 Apr 2018 12:41:38 -0700 Subject: [Haskell-cafe] downgrading GHC version on a Mac In-Reply-To: References: Message-ID: Sorry, I don't follow what you're saying. What does 'stack-shell' do? How do I make or choose a resolver? And is this going to work with GHCJS? Seems simpler to go along with what GHCJS expects, as there may be a number of auxiliary programs to GHCJS that expect the same thing. D On Thu, Apr 5, 2018 at 11:13 AM, Matt wrote: > I do not have a system GHC installed. For tools that need it (eg cabal), I > have an alias `stack-shell` that does `stack exec --no-ghc-package-path > zsh`. You can use that, with a given resolver (that corresponds to the GHC > version you want) to have a shell open with the GHC you want to use > available "globally." I find that this keeps things clean and easy to > understand. > > Matt Parsons > > On Thu, Apr 5, 2018 at 12:06 PM, Dennis Raddle > wrote: > >> I'm on a MacBook Pro. I'm not very familiar with software installation. >> >> Up until now I've been using Stack for GHC work, and it seems to take >> care of having the right version of GHC. >> >> Now I'm going to use GHCJS, and I need to have a system GHC installed (I >> believe). At some point in the past I installed the Haskell Platform for >> Mac, and I have GHC 8.01. But I want to downgrade that to 7.10 so that I >> don't have to worry about compatibility with GHCJS. >> >> How do I go about uninstalling GHC 8 and installing 7.10 in its place? >> Can I use Homebrew? >> >> D >> >> _______________________________________________ >> 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 nectarien at gmail.com Fri Apr 6 08:09:01 2018 From: nectarien at gmail.com (Peter Dedecker) Date: Fri, 6 Apr 2018 10:09:01 +0200 Subject: [Haskell-cafe] Windows: how to perform cleanup actions when the console window closes Message-ID: Hello all, I have a console (command-line) Haskell application that communicates with some hardware equipment. The equipment needs to be initialized when my program starts, and needs to be cleanly shut down when the program ends. This is the basic structure of the program: main = readAvailableEquipment >>= \descs -> withEquipment descs $ \availableEquipment -> <<< more initialization then an infinite loop as a sockets-based server, communicating with the hardware via availableEquipment >>> withEquipment is defined as withEquipment descs action = bracket (initializeEquipment descs) closeEquipment action Basically I want closeEquipment to be executed when the program shuts down. The program is stopped by the user closing the console window (hitting the upper right 'X' in the Windows title bar). I would expect that the 'closeEquipment' action is performed since it is in the cleanup part of the 'bracket', but my testing suggests that these actions never execute. Incidentally, stopping the program via Ctrl-C doesn't work. I have tested this with GHC 8.2.2 installed via Stack (LTS 11.3). This is on Windows 10. Summary question and TLDR: how do I reliably perform cleanup actions in a Windows console program that is closed by the user by clicking the 'X' symbol in the window title bar? Thanks! Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Apr 6 08:46:09 2018 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 6 Apr 2018 10:46:09 +0200 Subject: [Haskell-cafe] Windows: how to perform cleanup actions when the console window closes In-Reply-To: References: Message-ID: <86db47fe-ede2-e440-d02d-9a80357d5784@durchholz.org> Am 06.04.2018 um 10:09 schrieb Peter Dedecker: > Summary question and TLDR: how do I reliably perform cleanup actions in > a Windows console program that is closed by the user by clicking the 'X' > symbol in the window title bar? You need to intercept the various events that may cause a console windows to be closed; this is done via the Windows API call SetConsoleCtrlHandler . https://stackoverflow.com/a/30843219/6944068 gives an overview, API doc is at https://docs.microsoft.com/en-us/windows/console/setconsolectrlhandler (you want to register a HandlerRoutine). The default handler simply calls ExitProcess, bypassing all shutdown activity of the runtime. That's why C++ guys complain that destructors are not called. I don't know how to register a Haskell function as a Windows callback, that will have to be answered by somebody else. HTH Jo From liam.wall+haskell at gmail.com Fri Apr 6 08:48:40 2018 From: liam.wall+haskell at gmail.com (Liam Wall) Date: Fri, 6 Apr 2018 09:48:40 +0100 Subject: [Haskell-cafe] downgrading GHC version on a Mac In-Reply-To: References: Message-ID: Hi, I'm not Matt, but maybe can help anyway... `stack exec zsh` just runs zsh with some modified environment variables. In particular, it'll change PATH so that ghc, gchi, runhaskell etc all resolve to a stack local installation, not the system installation. You can can substitute bash or whatever shell you use for zsh. There's also a command line option for selecting the resolver. E.g. this example is copied directly form my terminal: [~]% which ghc /usr/bin/ghc [~]% ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 [~]% stack exec --resolver lts-6.25 --no-ghc-package-path zsh [~]% which ghc /home/liam/.stack/programs/x86_64-linux/ghc-tinfo6-nopie-7.10.3/bin/ghc [~]% ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 [~]% exit [~]% ghc --version The Glorious Glasgow Haskell Compilation System, version 8.2.2 My system installation has ghc 8.2.2. After running `stack exec` with resolver lts-6.25, invoking ghc is 7.10.3. After exiting that shell it's back to the system installed version. The stackage homepage lists which resolver to use to get a given ghc version: https://www.stackage.org/ Caveat: I'm a haskell newbie, and I've not used ghcjs ever, so I'm not really sure if this will work for you. I guess the suggested approach is to run `stack exec ...` to get the appropriate ghc version you need, then proceed with whatever you need to do for ghcjs. I think the suggested --no-ghc-package-path flag is to ensure cabal works properly. I *think* `stack exec` sets up the environment so that any packages installed with cabal go into a sandbox for the version of ghc you're using. Since you already have stack installed, it seems easier to try this approach before modifying you system installation. Also, there is this which might be easier: https://docs.haskellstack.org/en/stable/ghcjs/ Hope that helps, Liam On 5 April 2018 at 20:41, Dennis Raddle wrote: > Sorry, I don't follow what you're saying. What does 'stack-shell' do? How do > I make or choose a resolver? > > And is this going to work with GHCJS? Seems simpler to go along with what > GHCJS expects, as there may be a number of auxiliary programs to GHCJS that > expect the same thing. > > D > > > On Thu, Apr 5, 2018 at 11:13 AM, Matt wrote: >> >> I do not have a system GHC installed. For tools that need it (eg cabal), I >> have an alias `stack-shell` that does `stack exec --no-ghc-package-path >> zsh`. You can use that, with a given resolver (that corresponds to the GHC >> version you want) to have a shell open with the GHC you want to use >> available "globally." I find that this keeps things clean and easy to >> understand. >> >> Matt Parsons >> >> On Thu, Apr 5, 2018 at 12:06 PM, Dennis Raddle >> wrote: >>> >>> I'm on a MacBook Pro. I'm not very familiar with software installation. >>> >>> Up until now I've been using Stack for GHC work, and it seems to take >>> care of having the right version of GHC. >>> >>> Now I'm going to use GHCJS, and I need to have a system GHC installed (I >>> believe). At some point in the past I installed the Haskell Platform for >>> Mac, and I have GHC 8.01. But I want to downgrade that to 7.10 so that I >>> don't have to worry about compatibility with GHCJS. >>> >>> How do I go about uninstalling GHC 8 and installing 7.10 in its place? >>> Can I use Homebrew? >>> >>> D >>> >>> _______________________________________________ >>> 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. From nectarien at gmail.com Fri Apr 6 09:35:57 2018 From: nectarien at gmail.com (Peter Dedecker) Date: Fri, 6 Apr 2018 11:35:57 +0200 Subject: [Haskell-cafe] Windows: how to perform cleanup actions when the console window closes Message-ID: Hi Joachim, > You need to intercept the various events that may cause a console > windows to be closed; this is done via the Windows API call > SetConsoleCtrlHandler . > https://stackoverflow.com/a/30843219/6944068 gives an overview very informative, thanks! > I don't know how to register a Haskell function as a Windows callback, > that will have to be answered by somebody else. With your tips, I came across https://hackage.haskell.org/package/base-4.11.0.0/docs/GHC-ConsoleHandler.html. (The documentation doesn't work, but you can look at the source to see the gist of it). I think this may do what you describe. The documentation for this function says that > When the event is received, if the > 'Handler' value is @Catch f@, then a new thread will be spawned by > the system to execute @f e@, where @e@ is the 'ConsoleEvent' that > was received. I wonder if I can add a handler function that detects Control-C and Close events, and responds by throwing a userInterrupt exception to the main thread, and then sleeping forever. The main thread then sees an asynchronous exception, the bracket cleanup action fires (which is my goal here), main thread shuts down and the program stops. Will try to experiment with that later. Thanks again Peter From ivanperezdominguez at gmail.com Fri Apr 6 11:00:41 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 6 Apr 2018 07:00:41 -0400 Subject: [Haskell-cafe] ANN: Yampa 0.11 Message-ID: Dear all, I'm happy to announce version 0.11 of Yampa! Yampa is a mature and robust FRP implementation that has been used to create mobile, desktop, and web games and applications, including games that use devices like wiimotes and kinect, as well as free and commercial mobile games available on iTunes and Google Play. (For reference, see [1-4].) This version includes documentation for all modules and all definitions. We have closed a total of 29 issues. Thanks to @ptvirgo for contributing to this release. A limitation of Haddock prevents us from achieving 100% coverage. Help with that would be appreciated [5, 6]. This version has been tested against all major GHC versions, from 7.6 to 8.4. A minor change in the low-level interface has triggered a major version bump (0.11). I would expect all projects that use Yampa to work by, at most, adapting the version constraints in the cabal files. Everybody is welcome to collaborate. The github repo includes some simple issues especially suitable for beginners, and we are working on the next major version. We are also exploring different research ideas related to FRP, and actively look for research collaborators. Hope you all enjoy it. Happy Haskelling! Ivan [1] https://github.com/ivanperez-keera/Yampa [2] https://github.com/ivanperez-keera/haskanoid [3] https://github.com/ksaveljev/yampa-2048 [4] https://haskell.games [5] https://github.com/haskell/haddock/issues/123 [6] https://github.com/ivanperez-keera/Yampa/issues/72 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nectarien at gmail.com Fri Apr 6 12:46:45 2018 From: nectarien at gmail.com (Peter Dedecker) Date: Fri, 6 Apr 2018 14:46:45 +0200 Subject: [Haskell-cafe] Windows: how to perform cleanup actions when the console window closes Message-ID: So I looked at this some more, and determined a few things: - Ctrl-C did not do anything in the original program because the main thread was blocked on a socket accept() call, which seemingly could not be interrupted for an asynchronous exception. - I fixed this by having the main thread initialize everything, then running the main body of code in an async and waiting on that. Apparently this wait is interruptible, so Ctrl-C works, bracket nicely cleans up, and the application exits. Good! - Then I added a console handler to capture 'close' events. Here is the code for the handler: f mainThreadID event = case event of ControlC -> putStrLn "HANDLER" >> throwTo mainThreadID UserInterrupt Break -> putStrLn "HANDLER" >> throwTo mainThreadID UserInterrupt Close -> putStrLn "HANDLER" >> throwTo mainThreadID ThreadKilled >> threadDelay maxBound _ -> pure () Where the 'threadDelay' call serves simply to give the main thread time to exit. This works fine for ControlC and Break, but fails for Close: the program exists immediately, and no cleanup is run. So I still haven't solved how to clean up when the window close button is hit. Any thoughts? Thanks Peter From mail at joachim-breitner.de Fri Apr 6 18:18:26 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 06 Apr 2018 14:18:26 -0400 Subject: [Haskell-cafe] PatternSignatures (rant) In-Reply-To: <49DC4E83.3060100@imn.htwk-leipzig.de> References: <49DC4E83.3060100@imn.htwk-leipzig.de> Message-ID: <1523038706.28605.1.camel@joachim-breitner.de> Hi Johannes, Am Mittwoch, den 08.04.2009, 03:00 +0000 schrieb Johannes Waldmann: > Dear all, (this is a rant - please ignore) > > why has "PatternSignatures" > been renamed to "ScopedTypeVariables" (in ghc-6.10)? > > show me the alleged "type variable" in this code: > do x :: Int <- [ 1 .. 10 ] ; return $ x^2 > > and why on earth do I need to use a language extension at all > to get to the most basic thing of declarative programming: > to declare the type of an identifier? > > This seriously hurts (me, at least) when teaching Haskell. I agree, and it has bothered me for quite a while. But better late than never: https://github.com/ghc-proposals/ghc-proposals/pull/119 If if this still seriously hurts you, feel free to express your support in the proposal. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From dennis.raddle at gmail.com Sat Apr 7 19:53:04 2018 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Sat, 7 Apr 2018 12:53:04 -0700 Subject: [Haskell-cafe] stack and GHCJS Message-ID: Now I'm trying to use stack to install and run GCHJS. Can someone help me figure out this error? I first created project 'proj01' using the ghcjs template via stack new proj01 ghcjs Then I typed stack build It ran for a while, then gave an error messages that starts "While building custom Setup.hs for package semigroupoids-5.0.0.4 using .... , Process exited with code ExitFailure 1" But it didn't halt. Instead it started compiling Main.hs, and ended up saying "at least the following dependencies are missing: tagged >= 0.8.5 && <1 && ==0.8.1" I tried adding "tagged" to the extra-deps in the stack.yaml, but it didn't help. While I'm posting, is there a resource that explains background to this? I don't know much about "packages," "snapshots," "dependencies", means of specifying versions, cabal, or YAML files. Everything I find online seems to assume some background knowledge of these things. For instance the stack documentation talks about snapshots, but I can't find an explanation that I understand for what a "snapshot" actually is. Ditto for all these many concepts that go into configuring and building. D -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sun Apr 8 20:48:41 2018 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 8 Apr 2018 13:48:41 -0700 Subject: [Haskell-cafe] stack and GHCJS In-Reply-To: References: Message-ID: Here's the GHC docs on "packages": https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/packages.html tl;dr a package is a bundle of modules. Packages are installed into a ghc package database. (Stack manages ghc package databases for you.) "dependencies" generally refers to any other packages required to build a given project or package. For more info on "packages" and "projects" (with regards to stack), see https://docs.haskellstack.org/en/stable/stack_yaml_vs_cabal_package_file/#package-versus-project A "Stackage snapshot" is a collection of packages, where each package is pinned to a specific version of that package. https://docs.haskellstack.org/en/stable/stack_yaml_vs_cabal_package_file/#resolvers-and-snapshots https://docs.haskellstack.org is generally the place to go for info like this. And of course, if you have any questions, you're welcome to ask them here, or on the haskell-stack mailing list: https://groups.google.com/forum/#!forum/haskell-stack -- Dan Burton On Sat, Apr 7, 2018 at 12:53 PM, Dennis Raddle wrote: > Now I'm trying to use stack to install and run GCHJS. Can someone help me > figure out this error? > > I first created project 'proj01' using the ghcjs template via > > stack new proj01 ghcjs > > Then I typed > > stack build > > It ran for a while, then gave an error messages that starts > > "While building custom Setup.hs for package semigroupoids-5.0.0.4 > using .... , Process exited with code ExitFailure 1" > > But it didn't halt. Instead it started compiling Main.hs, and ended up > saying > > "at least the following dependencies are missing: tagged >= 0.8.5 && <1 && > ==0.8.1" > > I tried adding "tagged" to the extra-deps in the stack.yaml, but it didn't > help. > > While I'm posting, is there a resource that explains background to this? I > don't know much about "packages," "snapshots," "dependencies", means of > specifying versions, cabal, or YAML files. Everything I find online seems > to assume some background knowledge of these things. For instance the stack > documentation talks about snapshots, but I can't find an explanation that I > understand for what a "snapshot" actually is. Ditto for all these many > concepts that go into configuring and building. > > D > > > > > _______________________________________________ > 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 R.Paterson at city.ac.uk Mon Apr 9 12:45:22 2018 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Mon, 9 Apr 2018 13:45:22 +0100 Subject: [Haskell-cafe] Join a transformer In-Reply-To: References: Message-ID: <20180409124521.GA16690@city.ac.uk> On Thu, Mar 14, 2013 at 05:24:23AM +0200, Michael Snoyman wrote: > I'm wondering if this pattern exists and has a name. We have the > concept of joining a Monad: > join :: Monad m => m (m a) -> ma > How about joining a monad transformer? > joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a This is a monad in the category of monads. Moggi discusses them in "An Abstract View of Programming Languages", including which transformers have joinT. I was thinking of adding the class to the transformers package. From konn.jinro at gmail.com Mon Apr 9 12:52:48 2018 From: konn.jinro at gmail.com (Hiromi ISHII) Date: Mon, 9 Apr 2018 21:52:48 +0900 Subject: [Haskell-cafe] Join a transformer In-Reply-To: <20180409124521.GA16690@city.ac.uk> References: <20180409124521.GA16690@city.ac.uk> Message-ID: Hi there, Gabriel's `mmorph` library [1] provides such abstraction, i.e. `MMonad` type-class and `squash` function. [1]: http://hackage.haskell.org/package/mmorph > On 2018/04/09 21:45, Ross Paterson wrote: > > On Thu, Mar 14, 2013 at 05:24:23AM +0200, Michael Snoyman wrote: >> I'm wondering if this pattern exists and has a name. We have the >> concept of joining a Monad: >> join :: Monad m => m (m a) -> ma >> How about joining a monad transformer? >> joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a > > This is a monad in the category of monads. Moggi discusses them in > "An Abstract View of Programming Languages", including which transformers > have joinT. I was thinking of adding the class to the transformers package. > _______________________________________________ > 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. -- Hiromi ISHII konn.jinro at gmail.com Doctoral program in Mathematics, University of Tsukuba -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: From dhelta.diaz at gmail.com Mon Apr 9 13:41:04 2018 From: dhelta.diaz at gmail.com (=?UTF-8?Q?Daniel_D=C3=ADaz_Casanueva?=) Date: Mon, 9 Apr 2018 15:41:04 +0200 Subject: [Haskell-cafe] Join a transformer In-Reply-To: <20180409124521.GA16690@city.ac.uk> References: <20180409124521.GA16690@city.ac.uk> Message-ID: +1 on adding this to transformers. 2018-04-09 14:45 GMT+02:00 Ross Paterson : > On Thu, Mar 14, 2013 at 05:24:23AM +0200, Michael Snoyman wrote: > > I'm wondering if this pattern exists and has a name. We have the > > concept of joining a Monad: > > join :: Monad m => m (m a) -> ma > > How about joining a monad transformer? > > joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a > > This is a monad in the category of monads. Moggi discusses them in > "An Abstract View of Programming Languages", including which transformers > have joinT. I was thinking of adding the class to the transformers > package. > _______________________________________________ > 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 csaba.hruska at gmail.com Mon Apr 9 18:51:57 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Mon, 9 Apr 2018 20:51:57 +0200 Subject: [Haskell-cafe] GHC Core / STG to supercombinators Message-ID: Hello, I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. Is it possible to use GHC simplifier to transform the parsed Haskell source to supercombinators? i.e. to do - eta expansion - closure conversion - lambda lifting Or should it be written from scratch? Is Core or STG suited better for this purpose? Thanks, Csaba -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrohavoc at gmail.com Mon Apr 9 19:11:27 2018 From: astrohavoc at gmail.com (Shao Cheng) Date: Tue, 10 Apr 2018 03:11:27 +0800 Subject: [Haskell-cafe] GHC Core / STG to supercombinators In-Reply-To: References: Message-ID: Hi Csaba, The transformations you described already exist as core simplifier passes. For custom compilation, you may write your own pass using the core plugin mechanism, see https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#compiler-plugins It's also possible to perform transformations on STG, but it takes extra effort to retrieve/transform the in-memory STG representations, and type safety is also not guaranteed. Regards, Shao Cheng On Tue, Apr 10, 2018 at 2:51 AM, Csaba Hruska wrote: > Hello, > > I wonder what is the easiest way to compile Haskell to supercombinators > (top level functions) using GHC as a library. > > Is it possible to use GHC simplifier to transform the parsed Haskell > source to supercombinators? i.e. to do > > - eta expansion > - closure conversion > - lambda lifting > > Or should it be written from scratch? > > Is Core or STG suited better for this purpose? > > Thanks, > Csaba > > _______________________________________________ > 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 csaba.hruska at gmail.com Mon Apr 9 22:26:20 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 10 Apr 2018 00:26:20 +0200 Subject: [Haskell-cafe] GHC Core / STG to supercombinators In-Reply-To: References: Message-ID: I've checked the source code of GHC's simplifier. Regarding the eta expansion and lambda lifting it seems (according the comments) it does not guarantee to make these transformations in every case. If GHC can transform the Core representation to supercombinators, which transformation sould I use from *CoreToDo*? https://github.com/ghc/ghc/blob/master/compiler/simplCore/CoreMonad.hs#L107-L135 Maybe I should give more details: I'd like to use GHC as a frontend for my custom code generator which can handle (lazy) top level functions only. Is it better to use GHC as a library or is it better to write a compiler plugin to capture the core representation. I do not want to optimize the Core at all neither want to use other parts of GHC's backend (i.e. codegen). Ideally GHC would typecheck and transform everything to top level function and my system would do the rest. Do you know what would be the easiest way to do this? (i.e. via *CoreToDo* or custom calls for the simplifying functions) Regards, Csaba Hruska On Mon, Apr 9, 2018 at 9:11 PM, Shao Cheng wrote: > Hi Csaba, > > The transformations you described already exist as core simplifier passes. > For custom compilation, you may write your own pass using the core plugin > mechanism, see https://downloads.haskell.org/~ghc/latest/docs/html/users_ > guide/extending_ghc.html#compiler-plugins > > It's also possible to perform transformations on STG, but it takes extra > effort to retrieve/transform the in-memory STG representations, and type > safety is also not guaranteed. > > Regards, > Shao Cheng > > On Tue, Apr 10, 2018 at 2:51 AM, Csaba Hruska > wrote: > >> Hello, >> >> I wonder what is the easiest way to compile Haskell to supercombinators >> (top level functions) using GHC as a library. >> >> Is it possible to use GHC simplifier to transform the parsed Haskell >> source to supercombinators? i.e. to do >> >> - eta expansion >> - closure conversion >> - lambda lifting >> >> Or should it be written from scratch? >> >> Is Core or STG suited better for this purpose? >> >> Thanks, >> Csaba >> >> _______________________________________________ >> 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 litchard.michael at gmail.com Tue Apr 10 16:03:57 2018 From: litchard.michael at gmail.com (Michael Litchard) Date: Tue, 10 Apr 2018 09:03:57 -0700 Subject: [Haskell-cafe] looking for a particular paper Message-ID: Could someone provide a copy of the following paper? Safe Client/Server Web Development with Haskell Mark Mazumder ; Timothy Braje -------------- next part -------------- An HTML attachment was scrubbed... URL: From ichistmeinname at web.de Tue Apr 10 16:12:20 2018 From: ichistmeinname at web.de (Sandra Dylus) Date: Tue, 10 Apr 2018 18:12:20 +0200 Subject: [Haskell-cafe] looking for a particular paper In-Reply-To: References: Message-ID: <36D5785A-5598-4DFC-8AB4-634A9AC45C6D@web.de> Hi, On 10 Apr 2018, at 18:03, Michael Litchard wrote: > Safe Client/Server Web Development with Haskell as far as I can tell, this is not a “conventional” paper but an abstract for a tutorial and the tutorial can be found on GitHub. https://github.com/haskell-web-intro Cheers Sandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Tue Apr 10 19:20:55 2018 From: leiva.steven at gmail.com (Steven Leiva) Date: Tue, 10 Apr 2018 14:20:55 -0500 Subject: [Haskell-cafe] looking for a particular paper In-Reply-To: <36D5785A-5598-4DFC-8AB4-634A9AC45C6D@web.de> References: <36D5785A-5598-4DFC-8AB4-634A9AC45C6D@web.de> Message-ID: Slides are also available: https://haskell-web-intro.github.io/secdev/#/ Thank you to Sandra for the initial link. On Tue, Apr 10, 2018 at 11:12 AM, Sandra Dylus wrote: > Hi, > > On 10 Apr 2018, at 18:03, Michael Litchard > wrote: > > Safe Client/Server Web Development with Haskell > > > as far as I can tell, this is not a “conventional” paper but an abstract > for a tutorial and the tutorial can be found on GitHub. > > https://github.com/haskell-web-intro > > Cheers > Sandra > > _______________________________________________ > 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.franksen at online.de Tue Apr 10 22:54:47 2018 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 11 Apr 2018 00:54:47 +0200 Subject: [Haskell-cafe] hackage style Message-ID: The new hackage style has nice colors but severe problems w.r.t. readability. The right column with the package meta data causes the Readme text to be cut off. This make it almost impossible to read it. I attached a screenshot for illustration. Cheers Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: Bildschirmfoto_2018-04-11_00-52-17.png Type: image/png Size: 143712 bytes Desc: not available URL: From gershomb at gmail.com Wed Apr 11 01:39:27 2018 From: gershomb at gmail.com (Gershom B) Date: Tue, 10 Apr 2018 21:39:27 -0400 Subject: [Haskell-cafe] downgrading GHC version on a Mac In-Reply-To: References: Message-ID: You can install multiple versions of ghc with the haskell platform — just procure the one for the appropriate version of GHC and install it. Swapping between versions can be done with the activate-hs script that is installed for you. That said, there is also a ghc-8.0 branch of ghcjs that should work with 8.0.1 -g On April 5, 2018 at 2:08:22 PM, Dennis Raddle (dennis.raddle at gmail.com) wrote: I'm on a MacBook Pro. I'm not very familiar with software installation. Up until now I've been using Stack for GHC work, and it seems to take care of having the right version of GHC. Now I'm going to use GHCJS, and I need to have a system GHC installed (I believe). At some point in the past I installed the Haskell Platform for Mac, and I have GHC 8.01. But I want to downgrade that to 7.10 so that I don't have to worry about compatibility with GHCJS.  How do I go about uninstalling GHC 8 and installing 7.10 in its place? Can I use Homebrew? D _______________________________________________ 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 ivan.miljenovic at gmail.com Wed Apr 11 01:43:30 2018 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 11 Apr 2018 11:43:30 +1000 Subject: [Haskell-cafe] hackage style In-Reply-To: References: Message-ID: On 11 April 2018 at 08:54, Ben Franksen wrote: > The new hackage style has nice colors but severe problems w.r.t. > readability. The right column with the package meta data causes the > Readme text to be cut off. This make it almost impossible to read it. I > attached a screenshot for illustration. It can also be difficult to read through long module names, e.g. http://hackage.haskell.org/package/distributed-process -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From gershomb at gmail.com Wed Apr 11 06:05:15 2018 From: gershomb at gmail.com (Gershom B) Date: Wed, 11 Apr 2018 02:05:15 -0400 Subject: [Haskell-cafe] hackage style In-Reply-To: References: Message-ID: The problem with that particular README is that it is a text file. Nearly all the readme files these days are in markdown, which wraps. For text files, we do something very basic and render in a 
 block, which does not wrap. 

To improve display of such readme files I see three options. A) use a smaller font only for pre blocks, so that more text fits, without rewrapping. B) allow text files to rewrap. C) force the content _only_ for such files to always be below a clear, and as such, below the entire properties table. I’m leaning towards A here at the moment. Thoughts?

-g

On April 10, 2018 at 6:56:47 PM, Ben Franksen (ben.franksen at online.de) wrote:

The new hackage style has nice colors but severe problems w.r.t.  
readability. The right column with the package meta data causes the  
Readme text to be cut off. This make it almost impossible to read it. I  
attached a screenshot for illustration.  

Cheers  
Ben  
_______________________________________________
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 alexey.raga at gmail.com  Wed Apr 11 07:13:01 2018
From: alexey.raga at gmail.com (Alexey Raga)
Date: Wed, 11 Apr 2018 07:13:01 +0000
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
Message-ID: 

World treating text tiles as markdowns (or even converting them to
markdowns) be an option?
I really don't like the idea of small/different font sizes...

Regards,
Alexey

On Wed, Apr 11, 2018 at 4:06 PM Gershom B  wrote:

> The problem with that particular README is that it is a text file. Nearly
> all the readme files these days are in markdown, which wraps. For text
> files, we do something very basic and render in a 
 block, which does
> not wrap.
>
> To improve display of such readme files I see three options. A) use a
> smaller font only for pre blocks, so that more text fits, without
> rewrapping. B) allow text files to rewrap. C) force the content _only_ for
> such files to always be below a clear, and as such, below the entire
> properties table. I’m leaning towards A here at the moment. Thoughts?
>
> -g
>
> On April 10, 2018 at 6:56:47 PM, Ben Franksen (ben.franksen at online.de)
> wrote:
>
> The new hackage style has nice colors but severe problems w.r.t.
> readability. The right column with the package meta data causes the
> Readme text to be cut off. This make it almost impossible to read it. I
> attached a screenshot for illustration.
>
> Cheers
> Ben
> _______________________________________________
> 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 gershomb at gmail.com  Wed Apr 11 07:15:45 2018
From: gershomb at gmail.com (Gershom B)
Date: Wed, 11 Apr 2018 09:15:45 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
 
Message-ID: 

I took a look and the smaller font doesn’t help enough anyway. But note
that it is a “different style” regardless in that it is in a 
 block to
preserve provided formatting (with regards to whitespace, etc).

i think the simplest thing is to give it a “pre-wrap” whitespace style
which keeps the whitespace rather than collapsing, but allows lines to
wrap. Things get a little ragged, but they fit without scrolling…

In general we can’t assume arbitrary text files will convert nicely to
markdown.

—g


On April 11, 2018 at 3:13:12 AM, Alexey Raga (alexey.raga at gmail.com) wrote:

World treating text tiles as markdowns (or even converting them to
markdowns) be an option?
I really don't like the idea of small/different font sizes...

Regards,
Alexey

On Wed, Apr 11, 2018 at 4:06 PM Gershom B  wrote:

> The problem with that particular README is that it is a text file. Nearly
> all the readme files these days are in markdown, which wraps. For text
> files, we do something very basic and render in a 
 block, which does
> not wrap.
>
> To improve display of such readme files I see three options. A) use a
> smaller font only for pre blocks, so that more text fits, without
> rewrapping. B) allow text files to rewrap. C) force the content _only_ for
> such files to always be below a clear, and as such, below the entire
> properties table. I’m leaning towards A here at the moment. Thoughts?
>
> -g
>
> On April 10, 2018 at 6:56:47 PM, Ben Franksen (ben.franksen at online.de)
> wrote:
>
> The new hackage style has nice colors but severe problems w.r.t.
> readability. The right column with the package meta data causes the
> Readme text to be cut off. This make it almost impossible to read it. I
> attached a screenshot for illustration.
>
> Cheers
> Ben
> _______________________________________________
> 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 ben.franksen at online.de  Wed Apr 11 07:22:47 2018
From: ben.franksen at online.de (Ben Franksen)
Date: Wed, 11 Apr 2018 09:22:47 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
Message-ID: 

Am 11.04.2018 um 03:43 schrieb Ivan Lazar Miljenovic:
> On 11 April 2018 at 08:54, Ben Franksen  wrote:
>> The new hackage style has nice colors but severe problems w.r.t.
>> readability. The right column with the package meta data causes the
>> Readme text to be cut off. This make it almost impossible to read it. I
>> attached a screenshot for illustration.
> 
> It can also be difficult to read through long module names, e.g.
> http://hackage.haskell.org/package/distributed-process

Is there a bug tracker for hackage where one can make suggestions to
improve the UI?

Cheers
Ben


From svenpanne at gmail.com  Wed Apr 11 07:25:43 2018
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 11 Apr 2018 09:25:43 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
Message-ID: 

2018-04-11 8:05 GMT+02:00 Gershom B :

> [...] I’m leaning towards A here at the moment. Thoughts?
>

+1 for that. In addition, I think that the 40% width of the right column
(the "properties" div) is a bit excessive, 25% looks better IMHO. The left
column ("description", "modules", "flags", ... divs) is probably more
interesting for the average user, so it deserves more screen space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alexander.kjeldaas at gmail.com  Wed Apr 11 08:03:01 2018
From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas)
Date: Wed, 11 Apr 2018 10:03:01 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, Apr 11, 2018 at 8:05 AM, Gershom B  wrote:

> The problem with that particular README is that it is a text file. Nearly
> all the readme files these days are in markdown, which wraps. For text
> files, we do something very basic and render in a 
 block, which does
> not wrap.
>
> To improve display of such readme files I see three options. A) use a
> smaller font only for pre blocks, so that more text fits, without
> rewrapping. B) allow text files to rewrap. C) force the content _only_ for
> such files to always be below a clear, and as such, below the entire
> properties table. I’m leaning towards A here at the moment. Thoughts?
>

I'd go with C, and an explicit note (in red or similar) that the package
includes a fixed-width readme.  I'd also throw in a link to the issue
tracker so people can easily file a bug if this is in fact an error.

Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ben.franksen at online.de  Wed Apr 11 08:03:44 2018
From: ben.franksen at online.de (Ben Franksen)
Date: Wed, 11 Apr 2018 10:03:44 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
 
Message-ID: 

Am 11.04.2018 um 09:25 schrieb Sven Panne:
> 2018-04-11 8:05 GMT+02:00 Gershom B :
> 
>> [...] I’m leaning towards A here at the moment. Thoughts?

Not sure what this refers to, but...

> +1 for that. In addition, I think that the 40% width of the right column
> (the "properties" div) is a bit excessive, 25% looks better IMHO. The left
> column ("description", "modules", "flags", ... divs) is probably more
> interesting for the average user, so it deserves more screen space.

Yes. It should also use all of the available horizontal space.

Cheers
Ben


From david.feuer at gmail.com  Wed Apr 11 11:17:54 2018
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 11 Apr 2018 11:17:54 +0000
Subject: [Haskell-cafe] Join a transformer
In-Reply-To: 
References: 
 <20180409124521.GA16690@city.ac.uk>
 
Message-ID: 

If something like MMonad gets added to transformers, then its MFunctor
version should really be double-ended to work with things like the final
version of FreeT.

On Mon, Apr 9, 2018, 9:41 AM Daniel Díaz Casanueva 
wrote:

> +1 on adding this to transformers.
>
> 2018-04-09 14:45 GMT+02:00 Ross Paterson :
>
>> On Thu, Mar 14, 2013 at 05:24:23AM +0200, Michael Snoyman wrote:
>> >    I'm wondering if this pattern exists and has a name. We have the
>> >    concept of joining a Monad:
>> >    join :: Monad m => m (m a) -> ma
>> >    How about joining a monad transformer?
>> >    joinT :: (Monad m, MonadTrans t) => t (t m) a -> t m a
>>
>> This is a monad in the category of monads.  Moggi discusses them in
>> "An Abstract View of Programming Languages", including which transformers
>> have joinT.  I was thinking of adding the class to the transformers
>> package.
>> _______________________________________________
>> 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 svenpanne at gmail.com  Wed Apr 11 12:34:37 2018
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 11 Apr 2018 14:34:37 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
 
 
Message-ID: 

2018-04-11 10:03 GMT+02:00 Ben Franksen :

> [...] It should also use all of the available horizontal space.
>

That's a good point, too. Currently it only uses 75% of the viewport (75vw
in the "content" div), perhaps 90% (or even 94%) would be quite an
improvement. Changing the font size for the preformatted content from 17px
to e.g. 14px makes things fit for my screen and doesn't screw up things too
much typographically IMHO. pre-wrap is useful as a fallback. So in a
nutshell:

   "properties": change from 40% to 25%
   "content": change from 75vw to 90vw
   pre within "embedded-author-content": change font-size from 17px to
14px, and add white-space: pre-wrap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fa-ml at ariis.it  Wed Apr 11 13:18:00 2018
From: fa-ml at ariis.it (Francesco Ariis)
Date: Wed, 11 Apr 2018 15:18:00 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
 
Message-ID: <20180411131800.2bt2rq55i5gy5oep@x60s.casa>

On Wed, Apr 11, 2018 at 09:22:47AM +0200, Ben Franksen wrote:
> Is there a bug tracker for hackage where one can make suggestions to
> improve the UI?

https://github.com/haskell/hackage-server/issues/741

The points made in this thread:
  - non markdown readmes (like [1])
  - very-long-module-names (like [2])
  - (maybe) some whitespace on the sidebars could be trimmer

[1] http://hackage.haskell.org/package/animascii
[2] http://hackage.haskell.org/package/distributed-process

I am putting Nuno Alexandre (who did an excellent job on the redesign!)
in CC:, as I am pretty sure he's not subscribed to -cafe
-F

From R.Paterson at city.ac.uk  Wed Apr 11 14:03:39 2018
From: R.Paterson at city.ac.uk (Ross Paterson)
Date: Wed, 11 Apr 2018 15:03:39 +0100
Subject: [Haskell-cafe] Join a transformer
In-Reply-To: 
References: 
 <20180409124521.GA16690@city.ac.uk>
 
 
Message-ID: <20180411140338.GA2814@city.ac.uk>

On Wed, Apr 11, 2018 at 11:17:54AM +0000, David Feuer wrote:
>    If something like MMonad gets added to transformers, then its MFunctor
>    version should really be double-ended to work with things like the
>    final version of FreeT.

Since transformers is targeted at standard Haskell, it wouldn't be able
to define MFunctor or embed.  It would have to be something like

class (MonadTrans t) => MonadMonad t where
    joinT :: Monad m => t (t m) a -> t m a

From jo at durchholz.org  Wed Apr 11 20:24:57 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Wed, 11 Apr 2018 22:24:57 +0200
Subject: [Haskell-cafe] hackage style
In-Reply-To: 
References: 
 
Message-ID: <5b59ab22-6182-5c32-60d2-7bf956219a6a@durchholz.org>

Am 11.04.2018 um 08:05 schrieb Gershom B:
> The problem with that particular README is that it is a text file. 
> Nearly all the readme files these days are in markdown, which wraps. For 
> text files, we do something very basic and render in a 
 block, 
> which does not wrap.
> To improve display of such readme files I see three options. A) use a 
> smaller font only for pre blocks, so that more text fits, without 
> rewrapping.

Not enough space for that.

> B) allow text files to rewrap.
If you throw in replacing start-of-line blanks with   this even 
preserves indentation. Also, use a fixed-width font.
It's going to look ugly though.

> C) force the content _only_ for such files to always be below a
> clear, and as such, below the entire properties table.

This is going to be horrible. Site visitors will find the same 
information in different places, depending on something that they don't 
know before they visit the page.


Let me add a few more options:

D) Redesign the page so that the README always takes up the full width.
E) Redesign the sidebar so that it is narrower. This sidebar is way too 
wide, you almost have a two-column layout here.
F) Move the sidebar content into its own full-width section.
G) Look at how GitHub, GitLab, etc. place this kind of information, 
steal the best layout ideas from there.

H) Move the sidebar information into a mouse-over flyout. (Not sure 
whether that's a good idea.)

Hope this helps.
Regards,
Jo

From gershomb at gmail.com  Thu Apr 12 07:41:33 2018
From: gershomb at gmail.com (Gershom B)
Date: Thu, 12 Apr 2018 09:41:33 +0200
Subject: [Haskell-cafe] Unplanned Hackage Downtime
Message-ID: 

I made a terrible administrative snafu, and we need to take some time to
restore Hackage. Luckily we have better mirroring in place now, so
cabal-install should be able to fall back automatically to mirrors. If this
does not work, you can use http://objects-us-west-1.dream.io/hackage-mirror/
or http://hackage.fpcomplete.com/ manually.
Best (and sincere apologies),
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From neil_mayhew at users.sourceforge.net  Thu Apr 12 13:51:19 2018
From: neil_mayhew at users.sourceforge.net (Neil Mayhew)
Date: Thu, 12 Apr 2018 07:51:19 -0600
Subject: [Haskell-cafe] Unplanned Hackage Downtime
In-Reply-To: 
References: 
Message-ID: <0c340b98-45d1-0855-0750-d4c4a85a1ab5@users.sourceforge.net>

On 2018-04-12 01:41 AM, Gershom B wrote:
>
> I made a terrible administrative snafu, and we need to take some time
to restore Hackage.

As a sysadmin myself (of other servers unrelated to Hackage) I feel your
pain.

From dennis.raddle at gmail.com  Thu Apr 12 19:47:47 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Thu, 12 Apr 2018 12:47:47 -0700
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
Message-ID: 

Let's say I've written a function on three types.

myFunc :: a -> b -> c
myFunc x y z = ...
  where
    helper :: a -> [b]
    helper xx = ...


Notice that I'm attempting to declare 'helper' using my type variables.
I've noticed that this results in an error.

Is this actually possible, and how?

D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From lysxia at gmail.com  Thu Apr 12 19:50:34 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Thu, 12 Apr 2018 15:50:34 -0400
Subject: [Haskell-cafe] using type variables in type declarations inside
 function
In-Reply-To: 
References: 
Message-ID: <29612660-c591-1d10-8307-77c9e30a1e68@gmail.com>

Hi Dennis,

Use ScopedTypeVariables.

{-# LANGUAGE ScopedTypeVariables #-}

myFunc :: forall a b c. a -> b -> c  -- explicit binders
...
     helper :: a -> [b]

On 04/12/2018 03:47 PM, Dennis Raddle wrote:
> Let's say I've written a function on three types.
> 
> myFunc :: a -> b -> c
> myFunc x y z = ...
>    where
>      helper :: a -> [b]
>      helper xx = ...
> 
> 
> Notice that I'm attempting to declare 'helper' using my type variables. 
> I've noticed that this results in an error.
> 
> Is this actually possible, and how?
> 
> D
> 
> 
> _______________________________________________
> 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  Thu Apr 12 19:51:40 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 12 Apr 2018 15:51:40 -0400
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
Message-ID: 

On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle 
wrote:

> myFunc :: a -> b -> c
> myFunc x y z = ...
>   where
>     helper :: a -> [b]
>     helper xx = ...
>
> Notice that I'm attempting to declare 'helper' using my type variables.
> I've noticed that this results in an error.
> Is this actually possible, and how?
>

You need the ScopedTypeVariables extension, *and* to "declare" the type
variables whose scope is to be extended with an explicit "forall" in the
signature.

-- 
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 dennis.raddle at gmail.com  Thu Apr 12 20:24:21 2018
From: dennis.raddle at gmail.com (Dennis Raddle)
Date: Thu, 12 Apr 2018 13:24:21 -0700
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
 
Message-ID: 

Thanks!

By the way, why do I sometimes have to use forall, and sometimes not?

I'm also learning Purescript, and I noticed that the examples use 'forall'
in every case. Why would it be different with Purescript?
D

On Thu, Apr 12, 2018 at 12:51 PM, Brandon Allbery 
wrote:

> On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle 
> wrote:
>
>> myFunc :: a -> b -> c
>> myFunc x y z = ...
>>   where
>>     helper :: a -> [b]
>>     helper xx = ...
>>
>> Notice that I'm attempting to declare 'helper' using my type variables.
>> I've noticed that this results in an error.
>> Is this actually possible, and how?
>>
>
> You need the ScopedTypeVariables extension, *and* to "declare" the type
> variables whose scope is to be extended with an explicit "forall" in the
> signature.
>
> --
> 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 allbery.b at gmail.com  Thu Apr 12 20:26:50 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 12 Apr 2018 16:26:50 -0400
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
 
 
Message-ID: 

I don't know Purescript so couldn't say about that. In standard Haskell you
don't need to use forall at all; it's used by this extension and by
extensions for existential types.

On Thu, Apr 12, 2018 at 4:24 PM, Dennis Raddle 
wrote:

> Thanks!
>
> By the way, why do I sometimes have to use forall, and sometimes not?
>
> I'm also learning Purescript, and I noticed that the examples use 'forall'
> in every case. Why would it be different with Purescript?
> D
>
> On Thu, Apr 12, 2018 at 12:51 PM, Brandon Allbery 
> wrote:
>
>> On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle 
>> wrote:
>>
>>> myFunc :: a -> b -> c
>>> myFunc x y z = ...
>>>   where
>>>     helper :: a -> [b]
>>>     helper xx = ...
>>>
>>> Notice that I'm attempting to declare 'helper' using my type variables.
>>> I've noticed that this results in an error.
>>> Is this actually possible, and how?
>>>
>>
>> You need the ScopedTypeVariables extension, *and* to "declare" the type
>> variables whose scope is to be extended with an explicit "forall" in the
>> signature.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>


-- 
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 ryan.reich at gmail.com  Thu Apr 12 20:41:33 2018
From: ryan.reich at gmail.com (Ryan Reich)
Date: Thu, 12 Apr 2018 20:41:33 +0000
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
 
 
Message-ID: 

I too am curious about the forall in ScopedTypeVariables. It seems formally
unnecessary, so I assume it is designed to avert some kind of inconsistency
with standard behavior? Thinking about other extensions, e.g.
FlexibleInstances or MultiParamTypeClasses, it seems like they all give
meaning to constructs that are forbidden by the standard, while this one
actually changes the standard behavior (for the better, imho) and so
requires protection by some nonstandard signifier, i.e. forall.

On Apr 12, 2018 13:27, "Dennis Raddle"  wrote:

Thanks!

By the way, why do I sometimes have to use forall, and sometimes not?

I'm also learning Purescript, and I noticed that the examples use 'forall'
in every case. Why would it be different with Purescript?
D

On Thu, Apr 12, 2018 at 12:51 PM, Brandon Allbery 
wrote:

> On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle 
> wrote:
>
>> myFunc :: a -> b -> c
>> myFunc x y z = ...
>>   where
>>     helper :: a -> [b]
>>     helper xx = ...
>>
>> Notice that I'm attempting to declare 'helper' using my type variables.
>> I've noticed that this results in an error.
>> Is this actually possible, and how?
>>
>
> You need the ScopedTypeVariables extension, *and* to "declare" the type
> variables whose scope is to be extended with an explicit "forall" in the
> signature.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>

_______________________________________________
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 fa-ml at ariis.it  Thu Apr 12 20:42:45 2018
From: fa-ml at ariis.it (Francesco Ariis)
Date: Thu, 12 Apr 2018 22:42:45 +0200
Subject: [Haskell-cafe] using type variables in type declarations inside
 function
In-Reply-To: 
References: 
 
 
 
Message-ID: <20180412204245.ckaw2svb75pvqjsu@x60s.casa>

On Thu, Apr 12, 2018 at 04:26:50PM -0400, Brandon Allbery wrote:
> I don't know Purescript so couldn't say about that. In standard Haskell you
> don't need to use forall at all; it's used by this extension and by
> extensions for existential types.

RankNTypes too iirc


From allbery.b at gmail.com  Thu Apr 12 20:43:32 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 12 Apr 2018 16:43:32 -0400
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
 
 
 
Message-ID: 

It's just compatibility with the standard: there might be existing code
that depends on Haskell 98 not extending the scope of a type variable, so
you need to be explicit about which type variables' scope to extend.
"forall" is already there for other extensions, and is otherwise a no-op in
this situation, so it's a safe way to specify the extended scope.

On Thu, Apr 12, 2018 at 4:41 PM, Ryan Reich  wrote:

> I too am curious about the forall in ScopedTypeVariables. It seems
> formally unnecessary, so I assume it is designed to avert some kind of
> inconsistency with standard behavior? Thinking about other extensions, e.g.
> FlexibleInstances or MultiParamTypeClasses, it seems like they all give
> meaning to constructs that are forbidden by the standard, while this one
> actually changes the standard behavior (for the better, imho) and so
> requires protection by some nonstandard signifier, i.e. forall.
>
> On Apr 12, 2018 13:27, "Dennis Raddle"  wrote:
>
> Thanks!
>
> By the way, why do I sometimes have to use forall, and sometimes not?
>
> I'm also learning Purescript, and I noticed that the examples use 'forall'
> in every case. Why would it be different with Purescript?
> D
>
> On Thu, Apr 12, 2018 at 12:51 PM, Brandon Allbery 
> wrote:
>
>> On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle 
>> wrote:
>>
>>> myFunc :: a -> b -> c
>>> myFunc x y z = ...
>>>   where
>>>     helper :: a -> [b]
>>>     helper xx = ...
>>>
>>> Notice that I'm attempting to declare 'helper' using my type variables.
>>> I've noticed that this results in an error.
>>> Is this actually possible, and how?
>>>
>>
>> You need the ScopedTypeVariables extension, *and* to "declare" the type
>> variables whose scope is to be extended with an explicit "forall" in the
>> signature.
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
> _______________________________________________
> 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 migmit at gmail.com  Thu Apr 12 20:57:33 2018
From: migmit at gmail.com (MigMit)
Date: Thu, 12 Apr 2018 22:57:33 +0200
Subject: [Haskell-cafe] using type variables in type declarations inside
	function
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

It could still be useful in local definitions. Like

something :: a -> ...
something =
    let somethinElse :: forall b. b -> a -> ...

Az iPademről küldve

2018. ápr. 12. dátummal, 22:43 időpontban Brandon Allbery  írta:

> It's just compatibility with the standard: there might be existing code that depends on Haskell 98 not extending the scope of a type variable, so you need to be explicit about which type variables' scope to extend. "forall" is already there for other extensions, and is otherwise a no-op in this situation, so it's a safe way to specify the extended scope.
> 
>> On Thu, Apr 12, 2018 at 4:41 PM, Ryan Reich  wrote:
>> I too am curious about the forall in ScopedTypeVariables. It seems formally unnecessary, so I assume it is designed to avert some kind of inconsistency with standard behavior? Thinking about other extensions, e.g. FlexibleInstances or MultiParamTypeClasses, it seems like they all give meaning to constructs that are forbidden by the standard, while this one actually changes the standard behavior (for the better, imho) and so requires protection by some nonstandard signifier, i.e. forall.
>> 
>> On Apr 12, 2018 13:27, "Dennis Raddle"  wrote:
>> Thanks!
>> 
>> By the way, why do I sometimes have to use forall, and sometimes not? 
>> 
>> I'm also learning Purescript, and I noticed that the examples use 'forall' in every case. Why would it be different with Purescript?
>> D
>> 
>>> On Thu, Apr 12, 2018 at 12:51 PM, Brandon Allbery  wrote:
>>>> On Thu, Apr 12, 2018 at 3:47 PM, Dennis Raddle  wrote:
>>>> myFunc :: a -> b -> c
>>>> myFunc x y z = ...
>>>>   where
>>>>     helper :: a -> [b]
>>>>     helper xx = ...
>>>> 
>>>> Notice that I'm attempting to declare 'helper' using my type variables. I've noticed that this results in an error.
>>>> Is this actually possible, and how?
>>> 
>>> 
>>> You need the ScopedTypeVariables extension, *and* to "declare" the type variables whose scope is to be extended with an explicit "forall" in the signature.
>>> 
>>> -- 
>>> brandon s allbery kf8nh                               sine nomine associates
>>> allbery.b at gmail.com                                  ballbery at sinenomine.net
>>> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
>> 
>> _______________________________________________
>> 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
> _______________________________________________
> 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 joshchia at gmail.com  Fri Apr 13 13:29:20 2018
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Fri, 13 Apr 2018 21:29:20 +0800
Subject: [Haskell-cafe] OneTuple unmaintained
Message-ID: 

OneTuple needs an update for compatibility with GHC 8.4. I emailed the
listed maintained but the email bounced. I would like to take over the
package if there are no other takers.

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From oleg.grenrus at iki.fi  Fri Apr 13 13:33:22 2018
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 13 Apr 2018 16:33:22 +0300
Subject: [Haskell-cafe] OneTuple unmaintained
In-Reply-To: 
References: 
Message-ID: 

See https://mail.haskell.org/pipermail/libraries/2018-April/028719.html
discussion, I have the very same intention!


On 13.04.2018 16:29, ☂Josh Chia (謝任中) wrote:
> OneTuple needs an update for compatibility with GHC 8.4. I emailed the
> listed maintained but the email bounced. I would like to take over the
> package if there are no other takers.
>
> Josh
>
>
> _______________________________________________
> 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 olshanskydr at gmail.com  Fri Apr 13 13:55:09 2018
From: olshanskydr at gmail.com (Dmitry Olshansky)
Date: Fri, 13 Apr 2018 16:55:09 +0300
Subject: [Haskell-cafe] Performance of TL-calculations
Message-ID: 

Hello, cafe,

The main problem I have when using promising type-level calculation is
compile time.

E.g. I have
> type T = ... :: [Symbol]
Now I don't know the order of Symbols in T. But I want to sort it before
using for some reasons.

I can define
> type T1 = Sort T   -- where Sort is from Singletons library
but T1 is only type synonym and long type-level calculation will be done in
any places where I use T1.
So I will have problems with compile-time performance.

Probably I would overcome this if I can define
> class X x where ...
> instance X T1 where ...
but I can't do it because can't define instances for (non-injective) Type
Families.


Is there any workaround?
Are there any plans to make it better?
Are there any hidden problems to make an analog of CAF on the type level?

Best regards,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marc at lamarciana.com  Fri Apr 13 13:59:44 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 13 Apr 2018 15:59:44 +0200 (CEST)
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
Message-ID: 

Hi there!

I'm using [selda](https://github.com/valderman/selda) package to deal
with relational databases.

This package represents database tables in haskell in a type-safe way.
And to do so it leans on type operators. For example, here they are two
different tables:

```
categories :: Table (RowID:*:Text)
expenses :: Table (RowID:*:Text:*:Double:*:RowID)
```

As both of them belong to different types, I can't put them in a single
list out of the box:

```
[categories, expenses] --- not valid!!
```

I'm aware of [different solutions](https://wiki.haskell.org/Heterogenous_collections) to deal with it, but they don't convince me:

- Algebraic data types: I think in this situation it is specially a
   burden having to play type-switching... There can exist a lot of
   different table schemas and they may change at any moment.

- Universal type: I see it as a kind of hack

- Existential types: I have read that usually it is an anti-pattern, and
   in this case I don't understand how it should work, because types are
   constructed with `:*:` operator.

So my question if it exists some natural way to treat types built with
type operators as a single type. I have to recognize I don't understand
well how all this stuff about type operators works. I have read
something but I still don't get it. So any direction with it would be
very gratifying, too :)

Thanks in advance.

Marc Busqué
http://waiting-for-dev.github.io/about/

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Fri Apr 13 14:15:43 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 13 Apr 2018 15:15:43 +0100
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: 
References: 
Message-ID: <20180413141543.GA22299@weber>

On Fri, Apr 13, 2018 at 03:59:44PM +0200, Marc Busqué wrote:
> ```
> categories :: Table (RowID:*:Text)
> expenses :: Table (RowID:*:Text:*:Double:*:RowID)
> ```
> 
> As both of them belong to different types, I can't put them in a single
> list out of the box:

Before we can help we need to know more.  Specifically, why do you want to
put them in a single list?

From marc at lamarciana.com  Fri Apr 13 14:38:46 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 13 Apr 2018 16:38:46 +0200 (CEST)
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: <20180413141543.GA22299@weber>
References: 
 <20180413141543.GA22299@weber>
Message-ID: 

On Fri, 13 Apr 2018, Tom Ellis wrote:

> On Fri, Apr 13, 2018 at 03:59:44PM +0200, Marc Busqué wrote:
>
> Before we can help we need to know more.  Specifically, why do you want to
> put them in a single list?

I want to make the same action with more than one (creating them in
the database server):

```
migrate :: IO ()
migrate = do
     dir <- dBDir
     createDirectoryIfMissing True dir
     forM_ [categories, expenses]
        $ withDB . createTable 
```

Marc Busqué
http://waiting-for-dev.github.io/about/

From litchard.michael at gmail.com  Fri Apr 13 15:26:56 2018
From: litchard.michael at gmail.com (Michael Litchard)
Date: Fri, 13 Apr 2018 08:26:56 -0700
Subject: [Haskell-cafe] need to find generated reflex/reflex-dom docs
Message-ID: 

I've installed reflex-platform on ubuntu via nix, and am pretty sure I have
local docs installed.
I located this file

/nix/store/hv5zkh1gmhklk4sgwhd8gy1q79l37zpc-reflex-dom-0.4-doc/share/doc/html/index.html
But it doesn't lead to very much. I'm thinking I didn't do a full doc
install. I'd like some advice on how to make sure I've got a complete local
install of reflex docs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ben.franksen at online.de  Fri Apr 13 19:19:15 2018
From: ben.franksen at online.de (Ben Franksen)
Date: Fri, 13 Apr 2018 21:19:15 +0200
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: 
References: 
 <20180413141543.GA22299@weber> 
Message-ID: 

Am 13.04.2018 um 16:38 schrieb Marc Busqué:
> On Fri, 13 Apr 2018, Tom Ellis wrote:
> 
>> On Fri, Apr 13, 2018 at 03:59:44PM +0200, Marc Busqué wrote:
>>
>> Before we can help we need to know more.  Specifically, why do you
>> want to
>> put them in a single list?
> 
> I want to make the same action with more than one (creating them in
> the database server):
> 
> ```
> migrate :: IO ()
> migrate = do
>     dir <- dBDir
>     createDirectoryIfMissing True dir
>     forM_ [categories, expenses]
>        $ withDB . createTable ```

So a possible solution is to store a list of actions instead of a list
of items (untested code):

    let dbCreateTable = withDB . createTable
    sequence_ $
        map dbCreateTable categories ++ map dbCreateTable expenses

or perhaps, if the types allow it:

    withDB $ do
        let dbCreateTable = withDB . createTable
        sequence_ $
            map createTable categories ++ map createTable expenses


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sat Apr 14 07:09:27 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sat, 14 Apr 2018 08:09:27 +0100
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: 
References: 
 <20180413141543.GA22299@weber>
 
Message-ID: <20180414070927.GB22299@weber>

On Fri, Apr 13, 2018 at 04:38:46PM +0200, Marc Busqué wrote:
> On Fri, 13 Apr 2018, Tom Ellis wrote:
> >On Fri, Apr 13, 2018 at 03:59:44PM +0200, Marc Busqué wrote:
> >
> >Before we can help we need to know more.  Specifically, why do you want to
> >put them in a single list?
> 
> I want to make the same action with more than one (creating them in
> the database server):
> 
> ```
> migrate :: IO ()
> migrate = do
>     dir <- dBDir
>     createDirectoryIfMissing True dir
>     forM_ [categories, expenses]
>        $ withDB . createTable ```

I think I would just tolerate

      forM_ [createTable categories, createTable expenses]
        $ withDB

From slucas at dsic.upv.es  Sat Apr 14 07:16:56 2018
From: slucas at dsic.upv.es (Salvador Lucas)
Date: Sat, 14 Apr 2018 09:16:56 +0200
Subject: [Haskell-cafe] WST 2018 - Call for Papers (extended deadline: April
	30, 2018)
Message-ID: <4bb4838e-c5ad-4f0c-7247-a3e4a6ab5614@dsic.upv.es>

==========================================================================
                           WST 2018 - Call for Papers
                    16th International Workshop on Termination

                     July 18-19, 2018, Oxford, United Kingdom
                           http://wst2018.webs.upv.es/

==========================================================================

NEW: Deadline extended to April 30, 2018
NEW: Akihisa Yamada, WST 2018 invited speaker

The Workshop on Termination (WST) traditionally brings together, in an
informal setting, researchers interested in all aspects of termination,
whether this interest be practical or theoretical, primary or derived.
The workshop also provides a ground for cross-fertilization of ideas from
the different communities interested in termination (e.g., working on
computational mechanisms, programming languages, software engineering,
constraint solving, etc.). The friendly atmosphere enables fruitful
exchanges leading to joint research and subsequent publications.

The workshop is held as part of the 2018 Federated Logic Conference
(FLoC 2018)

           http://www.floc2018.org/

IMPORTANT DATES:
  * submission deadline:  April 30, 2018 (extended)
  * notification:         May 28, 2018
  * final version due:    June 11, 2018
  * workshop:             July 18-19, 2018

TOPICS: The 16th International Workshop on Termination welcomes
contributions on all aspects of termination. In particular, papers
investigating applications of termination (for example in complexity
analysis, program analysis and transformation, theorem proving, program
correctness, modeling computational systems, etc.) are very welcome.

Topics of interest include (but are not limited to):
  * abstraction methods in termination analysis
  * certification of termination and complexity proofs
  * challenging termination problems
  * comparison and classification of termination methods
  * complexity analysis in any domain
  * implementation of termination methods
  * non-termination analysis and loop detection
  * normalization and infinitary normalization
  * operational termination of logic-based systems
  * ordinal notation and subrecursive hierarchies
  * SAT, SMT, and constraint solving for (non-)termination analysis
  * scalability and modularity of termination methods
  * termination analysis in any domain (lambda calculus, declarative
    programming, rewriting, transition systems, etc.)
  * well-founded relations and well-quasi-orders

COMPETITION: Since 2003, the catalytic effect of WST to stimulate
new research on termination has been enhanced by the celebration
of the Termination Competition and its continuously developing
problem databases containing thousands of programs as challenges
for termination analysis in different categories, see

    http://termination-portal.org/wiki/Termination_Competition

In 2018, the Termination Competition will run in parallel with FLoC 2018.
More details will be provided in a dedicated announcement on the
competition.

PROGRAM COMMITTEE:
     Cristina Borralleras - U. de Vic
     Ugo Dal Lago - U. degli Studi di Bologna
     Carsten Fuhs - Birkbeck, U. of London
     Samir Genaim - U. Complutense de Madrid
     Juergen Giesl - RWTH Aachen
     Raul Gutiérrez - U. Politecnica de València
     Keiichirou Kusakari - Gifu University
     Salvador Lucas (chair) - U. Politecnica de Valencia
     Fred Mesnard - U. de La Reunion
     Aart Middeldorp - U. of Innsbruck
     Albert Rubio - U. Politecnica de Catalunya
     Rene Thiemann - U. of Innsbruck
     Caterina Urban - ETH Zürich

INVITED SPEAKERS:

     Akihisa Yamada - NII Japan


SUBMISSION: Submissions are short papers/extended abstracts which
should not exceed 5 pages. There will be no formal reviewing. In
particular, we welcome short versions of recently published articles
and papers submitted elsewhere. The program committee checks relevance
and provides additional feedback for each submission. The accepted
papers will be made available electronically before the workshop.

Papers should be submitted electronically via the submission page:

     https://easychair.org/conferences/?conf=wst2018

Please, use LaTeX and the LIPIcs style file

     http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz

to prepare your submission.

From marc at lamarciana.com  Sun Apr 15 16:34:04 2018
From: marc at lamarciana.com (=?UTF-8?B?TWFyYyBCdXNxdcOp?=)
Date: Sun, 15 Apr 2018 18:34:04 +0200
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: <20180414070927.GB22299@weber>
References: 
 <20180413141543.GA22299@weber>
  <20180414070927.GB22299@weber>
Message-ID: 

Thanks for both answers. It wasn't what I had in mind, but surely it is
just that I have to get used to Haskell strong typing. Until now I think
I'm used to apply DRY beyond types :)

So, from you answers, I can conclude that there is no way to tell something
like the following in a type signature: "any type build with that type
operators". Isn't it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamesbtobin at gmail.com  Mon Apr 16 10:57:45 2018
From: jamesbtobin at gmail.com (James Tobin)
Date: Mon, 16 Apr 2018 11:57:45 +0100
Subject: [Haskell-cafe] JOB | Permanent Web Developer (New York)
Message-ID: 

Hello, I'm working with an established financial technology employer
that is looking to hire a permanent web developer with significant
Java client side experience to join their New York office.
Consequently, I had hoped that some members of this mailing list may
like to discuss further off-list using "JamesBTobin (at) Gmail (dot)
Com".  Kind regards, James

From ky3 at atamo.com  Mon Apr 16 11:19:34 2018
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Mon, 16 Apr 2018 18:19:34 +0700
Subject: [Haskell-cafe] JOB | Permanent Web Developer (New York)
In-Reply-To: 
References: 
Message-ID: 

wait a minute, isn't this job posting off topic for this list?

how are you and this job related to haskell?

On Monday, April 16, 2018, James Tobin  wrote:

> Hello, I'm working with an established financial technology employer
> that is looking to hire a permanent web developer with significant
> Java client side experience to join their New York office.
> Consequently, I had hoped that some members of this mailing list may
> like to discuss further off-list using "JamesBTobin (at) Gmail (dot)
> Com".  Kind regards, James
> _______________________________________________
> 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.



-- 
-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From P.Achten at cs.ru.nl  Mon Apr 16 13:07:08 2018
From: P.Achten at cs.ru.nl (Peter Achten)
Date: Mon, 16 Apr 2018 15:07:08 +0200
Subject: [Haskell-cafe] 2nd call for papers: Trends in Functional
 Programming, 11-13 june 2018, Chalmers Campus Johanneberg, Gothenburg
Message-ID: <1b2bfcbe-65c3-462c-7e42-de9e1e0f7650@cs.ru.nl>

                -------------------------------------
                2 N D   C A L L   F O R   P A P E R S
                -------------------------------------

                     ======== TFP 2018 ===========

           19th Symposium on Trends in Functional Programming
                            11-13 June, 2018
                      Chalmers Campus Johanneberg, Gothenburg
            http://www.cse.chalmers.se/~myreen/tfp2018/index.html

The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions (see
below at scope).

Please be aware that TFP uses two distinct rounds of submissions (see
below at submission details).

TFP 2018 will be the main event of a pair of functional programming
events. TFP 2018 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 14.


== SCOPE ==

The symposium recognizes that new trends may arise through various routes.
As part of the Symposium's focus on trends we therefore identify the
following five article categories. High-quality articles are solicited in
any of these categories:

Research Articles:
     Leading-edge, previously unpublished research work
Position Articles:
     On what new trends should or should not be
Project Articles:
     Descriptions of recently started new projects
Evaluation Articles:
     What lessons can be drawn from a finished project
Overview Articles:
     Summarizing work with respect to a trendy subject.

Articles must be original and not simultaneously submitted for 
publication to
any other forum. They may consider any aspect of functional programming:
theoretical, implementation-oriented, or experience-oriented. 
Applications of
functional programming techniques to other languages are also within the 
scope
of the symposium.

Topics suitable for the symposium include, but are not limited to:

     Functional programming and multicore/manycore computing
     Functional programming in the cloud
     High performance functional computing
     Extra-functional (behavioural) properties of functional programs
     Dependently typed functional programming
     Validation and verification of functional programs
     Debugging and profiling for functional languages
     Functional programming in different application areas:
     security, mobility, telecommunications applications, embedded
     systems, global computing, grids, etc.
     Interoperability with imperative programming languages
     Novel memory management techniques
     Program analysis and transformation techniques
     Empirical performance studies
     Abstract/virtual machines and compilers for functional languages
     (Embedded) domain specific languages
     New implementation strategies
     Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of TFP, 
please
contact the TFP 2018 program chairs, Michał Pałka and Magnus Myreen.


== Best Paper Awards ==

To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.

TFP traditionally pays special attention to research students, 
acknowledging
that students are almost by definition part of new subject trends. A 
student
paper is one for which the authors state that the paper is mainly the 
work of
students, the students are listed as first authors, and a student would 
present
the paper. A prize for the best student paper is awarded each year.

In both cases, it is the PC of TFP that awards the prize. In case the best
paper happens to be a student paper, that paper will then receive both 
prizes.


== Paper Submissions ==

We use EasyChair for the refereeing process. The link to the submission 
page is:

https://easychair.org/conferences/?conf=tfp2018

Authors of papers have the choice of having their contributions formally 
reviewed
either before or after the Symposium.


== Pre-symposium formal review ==

Papers to be formally reviewed before the symposium should be submitted 
before
an early deadline and receive their reviews and notification of 
acceptance for
both presentation and publication before the symposium. A paper that has 
been
rejected in this process may still be accepted for presentation at the 
symposium,
but will not be considered for the post-symposium formal review.


== Post-symposium formal review ==

Draft papers will receive minimal reviews and notification of acceptance 
for
presentation at the symposium. Authors of draft papers will be invited 
to submit
revised papers based on the feedback receive at the symposium. A 
post-symposium
refereeing process will then select a subset of these articles for 
formal publication.


== Paper categories ==

Draft papers and papers submitted for formal review are submitted as 
extended
abstracts (4 to 10 pages in length) or full papers (20 pages). The 
submission must
clearly indicate which category it belongs to: research, position, project,
evaluation, or overview paper. It should also indicate which authors are 
research
students, and whether the main author(s) are students. A draft paper for 
which all
authors are students will receive additional feedback by one of the PC 
members
shortly after the symposium has taken place.


== Format ==

Papers must be written in English, and written using the LNCS style. For 
more
information about formatting please consult the Springer LNCS web site.


== Important Dates ==

Submission (pre-symposium review):                   March 26, 2018  -- 
passed --
Submission (draft, post-symposium review):           April 26, 2018  --  
open  --
Notification (pre- and post-symposium review):       May    3, 2018
Registration:                                        June   3, 2018
TFP Symposium:                                       June 11-13, 2018
TFPIE Workshop:                                      June   14, 2018
Student papers feedback:                             June   21, 2018
Submission (post-symposium review):                  August 14, 2018
Notification (post-symposium review):                September 20, 2018
Camera-ready paper (pre- and post-symposium review): November 30, 2018


== Program Committee ==

Program Co-chairs
Michał Pałka,    Chalmers University of Technology (SE)
Magnus Myreen,    Chalmers University of Technology (SE)

Program Committee
Soichiro Hidaka,        Hosei University (JP)
Meng Wang,              University of Bristol (UK)
Sam Tobin-Hochstadt,    Indiana University Bloomington (US)
Tiark Rompf,            Purdue University (US)
Patricia Johann,        Appalachian State University (US)
Neil Sculthorpe,        Nottingham Trent University (UK)
Andres Löh,             Well-Typed LLP (UK)
Tarmo Uustalu,          Tallinn University of Technology (EE)
Cosmin E. Oancea,       University of Copenhagen (DK)
Mauro Jaskelioff,       Universidad Nacional de Rosario (AR)
Peter Achten,           Radboud University (NL)
Dimitrios Vytiniotis,   Microsoft Research (UK)
Alberto Pardo,          Universidad de la República (UY)
Natalia Chechina,       University of Glasgow (UK)
Peter Sestoft,          IT University of Copenhagen (DK)
Scott Owens,            University of Kent (UK)


From trupill at gmail.com  Mon Apr 16 13:26:20 2018
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 16 Apr 2018 15:26:20 +0200
Subject: [Haskell-cafe] Call for Participation: Summer School on Advanced
	Functional Programming
Message-ID: 

# Call for Participation

 SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING

 Utrecht, the Netherlands, 27-31 August 2018

 http://www.afp.school

## ABOUT

The Advanced Functional Programming summer school has been running for
more than ten years. We aim to educate aspiring Haskell programmers
beyond the basic material covered by many textbooks.

The lectures will cover several more advanced topics regarding the
theory and practice of Haskell programming, including topics such as:

  * lambda calculus;
  * monads and monad transformers;
  * lazy evaluation;
  * generalized algebraic data types;
  * type families and type-level programming;
  * concurrency and parallelism.

The summer school consists of a mix of lectures, labs, and a busy
social program.

## LECTURERS

Utrecht staff:
  * Johan Jeuring
  * Alejandro Serrano Mena
  * Doaitse Swierstra
  * Wouter Swierstra

Guest lectures:
  * Manuel Chakravarty
  * Koen Claessen
  * Gabriele Keller


## PREREQUISITES

We expect students to have a basic familiarity with Haskell
already. You should be able to write recursive functions over
algebraic data types, such as lists and trees. There is a great deal
of material readily available that covers this material. If you’ve
already started learning Haskell and are looking to take your
functional programming skills to the next level, this is the course
for you.

## DATES

Registration deadline: 1 August, 2017
School:                27-31 August

## COSTS

€1700 - Housing and registration
€1500 - Registration only

We offer a €1000 discount for students and staff members affiliated with
a university.

## SCHOLARSHIPS

If you’re struggling to finance your trip to Utrecht, please let us
know. We have a limited number of scholarships or discounts available
for students that would not be able to attend otherwise, especially
for women and under represented minorities.

## FURTHER INFORMATION

Further information, including instructions on how to register, is
available on our website:

                        http://www.afp.school
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sweemaykhaw at gmail.com  Mon Apr 16 13:59:32 2018
From: sweemaykhaw at gmail.com (May Khaw)
Date: Mon, 16 Apr 2018 13:59:32 +0000
Subject: [Haskell-cafe] JOB | Permanent Web Developer (New York)
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Apr 2018, 18:59 James Tobin,  wrote:

> Hello, I'm working with an established financial technology employer
> that is looking to hire a permanent web developer with significant
> Java client side experience to join their New York office.
> Consequently, I had hoped that some members of this mailing list may
> like to discuss further off-list using "JamesBTobin (at) Gmail (dot)
> Com".  Kind regards, James
> _______________________________________________
> 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 chrisdone at gmail.com  Mon Apr 16 16:36:22 2018
From: chrisdone at gmail.com (Christopher Done)
Date: Mon, 16 Apr 2018 17:36:22 +0100
Subject: [Haskell-cafe] Is there a reason that template-haskell does not
 expose its own parser for using in quasi-quoters?
Message-ID: 

I.e. something like parseExpr :: String -> Either String Exp

It seems that a lot of trivial extensions could be made nicely if this was
so. An example might be:

[ne| 1, 2, 3, ... |]

for a non-empty list statically checked to be non-empty. In there I could
put any Haskell code. But presently I need to use HSE which isn't quite GHC
Haskell and has a large foot-print. The alternative splice

$(ne [| [1, 2, 3, ... ] |])

is rather unwieldy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From nikhil at acm.org  Thu Apr 19 13:11:56 2018
From: nikhil at acm.org (Rishiyur Nikhil)
Date: Thu, 19 Apr 2018 09:11:56 -0400
Subject: [Haskell-cafe] ANN: RISC-V ISA Formal Spec (written in Haskell)
Message-ID: 

Title: RISC-V ISA Formal Specification

Speaker: Thomas Bourgeat, MIT
Venue: 8th RISC-V Workshop, Barcelona
Date: Monday May 7, 2018

Abstract: In this tutorial we will demonstrate several flavors of a
    formal specification of the RISC-V ISA, written in Haskell.  We
    will present the important part of the code, use it as a software
    simulator, automatically transform it into a coq specification
    (used to prove the correctness of a small imperative language),
    and automatically synthesize it to circuit (to model check against
    other designs).

    If time permits, we will show how the same code can be used to
    explore some non-determinism in the specification.

Registration info: https://riscv.org/workshops/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jake.waksbaum at gmail.com  Thu Apr 19 17:01:57 2018
From: jake.waksbaum at gmail.com (Jake)
Date: Thu, 19 Apr 2018 17:01:57 +0000
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: 
References: 
 <20180413141543.GA22299@weber>
  <20180414070927.GB22299@weber>
 
Message-ID: 

I would argue that in this case existential types actually are the correct
tool. What you want to do is hide some amount of type information, which is
exactly what existential types do. Then, because createTable can handle any
Table a when you unwrap the Table from the existential type you can still
pass it to createTable.

Here's a sort of mock example:

```{-# LANGUAGE TypeOperators #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE ExistentialQuantification #-}
{-# LANGUAGE LambdaCase #-}

import Control.Monad (forM_)

data Table a

data a :*: b where
  (:*:) :: a -> b -> a :*: b
infixr 1 :*:

type RowID = Int
type Text = String

categories :: Table (RowID :*: Text)
categories = undefined

expenses :: Table (RowID:*:Text:*:Double:*:RowID)
expenses = undefined

createTable :: Table a -> IO ()
createTable _ = return ()

data ExTable = forall a. ExTable (Table a)

main :: IO ()
main = forM_ [ExTable categories, ExTable expenses] (\case ExTable t ->
createTable t)
```

In your example this requires more boilerplate and doesn't seem much better
than [createTable categories, createTable expenses], but this provides a
way to actually have a list of tables of differing types without applying
createTable to them first and I think that's closer to what you were going
for.

On Sun, Apr 15, 2018 at 12:35 PM Marc Busqué  wrote:

> Thanks for both answers. It wasn't what I had in mind, but surely it is
> just that I have to get used to Haskell strong typing. Until now I think
> I'm used to apply DRY beyond types :)
>
> So, from you answers, I can conclude that there is no way to tell
> something like the following in a type signature: "any type build with that
> type operators". Isn't it?
> _______________________________________________
> 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 david.feuer at gmail.com  Thu Apr 19 17:13:39 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 Apr 2018 13:13:39 -0400
Subject: [Haskell-cafe] Integer representation
Message-ID: 

Is there any way to determine whether Integer comes from integer-gmp
or integer-simple? I'm playing with the idea of using the underlying
representation to get more compact/efficient tries, but I need to be
able to find out what that representation is.

From andrew.thaddeus at gmail.com  Thu Apr 19 17:17:34 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 19 Apr 2018 13:17:34 -0400
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
Message-ID: 

Here a guess:

    #if !(MIN_VERSION_integer-gmp(0,0,0))

Not sure if this works, but it might.

On Thu, Apr 19, 2018 at 1:13 PM, David Feuer  wrote:

> Is there any way to determine whether Integer comes from integer-gmp
> or integer-simple? I'm playing with the idea of using the underlying
> representation to get more compact/efficient tries, but I need to be
> able to find out what that representation is.
> _______________________________________________
> 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.




-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From claude at mathr.co.uk  Thu Apr 19 19:01:51 2018
From: claude at mathr.co.uk (Claude Heiland-Allen)
Date: Thu, 19 Apr 2018 20:01:51 +0100
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
Message-ID: 

Hi David,

On 19/04/18 18:13, David Feuer wrote:
> Is there any way to determine whether Integer comes from integer-gmp
> or integer-simple? I'm playing with the idea of using the underlying
> representation to get more compact/efficient tries, but I need to be
> able to find out what that representation is.
One way could be to use an automatic cabal flag.  With it enabled,
depend on integer-gmp and add hs-source-dirs to a directory containing
your integer-gmp implementation, with it disabled, depend on
integer-simple and add hs-source dirs to a directory containing your
integer-simple implementation.  This gives module-level control.  With
automatic flag I think cabal will try both and choose the setting that
gives the best build plan (likely corresponding to the Integer
implementation of your ghc).


Claude
-- 
https://mathr.co.uk

From david.feuer at gmail.com  Thu Apr 19 20:05:29 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 19 Apr 2018 16:05:29 -0400
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
 
Message-ID: 

I'm not familiar with automatic cabal flags. Could you point me to
documentation?

On Thu, Apr 19, 2018 at 3:01 PM, Claude Heiland-Allen
 wrote:
> Hi David,
>
> On 19/04/18 18:13, David Feuer wrote:
>> Is there any way to determine whether Integer comes from integer-gmp
>> or integer-simple? I'm playing with the idea of using the underlying
>> representation to get more compact/efficient tries, but I need to be
>> able to find out what that representation is.
> One way could be to use an automatic cabal flag.  With it enabled,
> depend on integer-gmp and add hs-source-dirs to a directory containing
> your integer-gmp implementation, with it disabled, depend on
> integer-simple and add hs-source dirs to a directory containing your
> integer-simple implementation.  This gives module-level control.  With
> automatic flag I think cabal will try both and choose the setting that
> gives the best build plan (likely corresponding to the Integer
> implementation of your ghc).
>
>
> Claude
> --
> https://mathr.co.uk
> _______________________________________________
> 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 claude at mathr.co.uk  Thu Apr 19 20:09:34 2018
From: claude at mathr.co.uk (Claude Heiland-Allen)
Date: Thu, 19 Apr 2018 21:09:34 +0100
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
 
 
Message-ID: 

On 19/04/18 21:05, David Feuer wrote:
> I'm not familiar with automatic cabal flags. Could you point me to
> documentation?

https://www.haskell.org/cabal/users-guide/developing-packages.html?highlight=flag#configuration-flags

> 
> On Thu, Apr 19, 2018 at 3:01 PM, Claude Heiland-Allen
>  wrote:
>> Hi David,
>>
>> On 19/04/18 18:13, David Feuer wrote:
>>> Is there any way to determine whether Integer comes from integer-gmp
>>> or integer-simple? I'm playing with the idea of using the underlying
>>> representation to get more compact/efficient tries, but I need to be
>>> able to find out what that representation is.
>> One way could be to use an automatic cabal flag.  With it enabled,
>> depend on integer-gmp and add hs-source-dirs to a directory containing
>> your integer-gmp implementation, with it disabled, depend on
>> integer-simple and add hs-source dirs to a directory containing your
>> integer-simple implementation.  This gives module-level control.  With
>> automatic flag I think cabal will try both and choose the setting that
>> gives the best build plan (likely corresponding to the Integer
>> implementation of your ghc).
>>
>>
>> Claude
>> --
>> https://mathr.co.uk
>> _______________________________________________
>> 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.


Claude
-- 
https://mathr.co.uk

From andrew.thaddeus at gmail.com  Thu Apr 19 20:38:57 2018
From: andrew.thaddeus at gmail.com (Andrew Martin)
Date: Thu, 19 Apr 2018 16:38:57 -0400
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
 
Message-ID: 

I've never realized how it worked before your explanation of automatic
flags, but this is what the bytestring library does to depend on
integer-gmp/integer-simple.

On Thu, Apr 19, 2018 at 3:01 PM, Claude Heiland-Allen 
wrote:

> Hi David,
>
> On 19/04/18 18:13, David Feuer wrote:
> > Is there any way to determine whether Integer comes from integer-gmp
> > or integer-simple? I'm playing with the idea of using the underlying
> > representation to get more compact/efficient tries, but I need to be
> > able to find out what that representation is.
> One way could be to use an automatic cabal flag.  With it enabled,
> depend on integer-gmp and add hs-source-dirs to a directory containing
> your integer-gmp implementation, with it disabled, depend on
> integer-simple and add hs-source dirs to a directory containing your
> integer-simple implementation.  This gives module-level control.  With
> automatic flag I think cabal will try both and choose the setting that
> gives the best build plan (likely corresponding to the Integer
> implementation of your ghc).
>
>
> Claude
> --
> https://mathr.co.uk
> _______________________________________________
> 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.
>



-- 
-Andrew Thaddeus Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From oleg.grenrus at iki.fi  Thu Apr 19 20:44:19 2018
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Thu, 19 Apr 2018 23:44:19 +0300
Subject: [Haskell-cafe] Integer representation
In-Reply-To: 
References: 
 
 
Message-ID: <48852189-4abc-7f9c-e80e-67d67bdb4c9e@iki.fi>

Hi David,

you could  check http://hackage.haskell.org/package/integer-logarithms

I don't use different source-dirs (I could), the implementation isn't
that different so  CPP didn't felt too intrusive.

The
http://cabal.readthedocs.io/en/latest/developing-packages.html#resolution-of-conditions-and-flags
section speaks about automatic flags.
TL;DR cabal solver will toggle _automatic_ flags (manual flags are set
to defaults). It's recommended to make flag assignment disjoint, e.g.
note how bytestring version ranges are disjoint.

    if flag(bytestring-builder)
      build-depends: bytestring >= 0.9.2 && < 0.10.4,
                     bytestring-builder >= 0.10.4 && < 1
    else
      build-depends: bytestring >= 0.10.4 && < 0.11

Similarly, in `integer-logarithms` we have

    flag integer-gmp
      description:  integer-gmp or integer-simple
      default:      True
      manual:       False

    library
    ...
     if flag(integer-gmp)
        build-depends:
          integer-gmp < 1.1
     else
        build-depends:
          integer-simple
          -- here we could have hs-source-dirs

relying that there aren't install plan with both integer-gmp and
integer-simple

For very complicated example see: functor-classes-compat
http://hackage.haskell.org/package/functor-classes-compat-1/functor-classes-compat.cabal


Hopefully these help

Cheers, Oleg.


On 19.04.2018 23:05, David Feuer wrote:
> I'm not familiar with automatic cabal flags. Could you point me to
> documentation?
>
> On Thu, Apr 19, 2018 at 3:01 PM, Claude Heiland-Allen
>  wrote:
>> Hi David,
>>
>> On 19/04/18 18:13, David Feuer wrote:
>>> Is there any way to determine whether Integer comes from integer-gmp
>>> or integer-simple? I'm playing with the idea of using the underlying
>>> representation to get more compact/efficient tries, but I need to be
>>> able to find out what that representation is.
>> One way could be to use an automatic cabal flag.  With it enabled,
>> depend on integer-gmp and add hs-source-dirs to a directory containing
>> your integer-gmp implementation, with it disabled, depend on
>> integer-simple and add hs-source dirs to a directory containing your
>> integer-simple implementation.  This gives module-level control.  With
>> automatic flag I think cabal will try both and choose the setting that
>> gives the best build plan (likely corresponding to the Integer
>> implementation of your ghc).
>>
>>
>> Claude
>> --
>> https://mathr.co.uk
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 

From ben at well-typed.com  Fri Apr 20 00:01:22 2018
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 19 Apr 2018 20:01:22 -0400
Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.2 released
Message-ID: <87in8md9v9.fsf@smart-cactus.org>


Hello everyone,

The GHC team is pleased to announce the availability of GHC 8.4.2. The
source distribution, binary distributions, and documentation for this
release are available at

    https://downloads.haskell.org/~ghc/8.4.2

This release is a bug-fix release, fixing numerous regressions and bugs
present in GHC 8.4.1. These include:

 * A regression resulting in some uses of `Control.Exception.evaluate`
   to be inappropriately optimised away (see #13930)

 * A regression resulting in segmentation faults of programs compiled
   with profiling (#14705)

 * A bug causing runtime system panics while running programs with
   retainer profiling (#14947)

 * The configure scripts now accepts a `--disable-dtrace` option, again
   allowing GHC to be bootstrapped on FreeBSD (#15040)

 * The version number of the `base` package has been bumped to
   4.11.1.0 to reflect the addition of the `GHC.IO.FixIOException` type.
   This interface was added in 8.4.1 but the version bump was missed due to
   an oversight.

 * Support for DWARF debug information has been significantly improved
   (#14894, #14779)

A more thorough list of the changes in this release can be found in the
release notes,

  https://downloads.haskell.org/~ghc/8.4.2/docs/html/users_guide/8.4.2-notes.html

Thanks to everyone who has contributed to developing, documenting, and
testing this release!

As always, let us know if you encounter trouble.


How to get it
~~~~~~~~~~~~~

The easy way is to go to the web page, which should be self-explanatory:

        http://www.haskell.org/ghc/

We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.

Packages will appear as they are built - if the package for your
system isn't available yet, please try again later.


Background
~~~~~~~~~~

Haskell is a standard lazy functional programming language.

GHC is a state-of-the-art programming suite for Haskell.  Included is
an optimising compiler generating efficient code for a variety of
platforms, together with an interactive system for convenient, quick
development.  The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces. GHC is distributed under a BSD-style open source license.

A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).


On-line GHC-related resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Relevant URLs on the World-Wide Web:

GHC home page              http://www.haskell.org/ghc/
GHC developers' home page  http://ghc.haskell.org/trac/ghc/
Haskell home page          http://www.haskell.org/


Supported Platforms
~~~~~~~~~~~~~~~~~~~

The list of platforms we support, and the people responsible for them,
is here:

   http://ghc.haskell.org/trac/ghc/wiki/Contributors

Ports to other platforms are possible with varying degrees of
difficulty.  The Building Guide describes how to go about porting to a
new platform:

    http://ghc.haskell.org/trac/ghc/wiki/Building


Developers
~~~~~~~~~~

We welcome new contributors.  Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:

  http://ghc.haskell.org/trac/ghc/


Mailing lists
~~~~~~~~~~~~~

We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at

    http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
    http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets

There are several other haskell and ghc-related mailing lists on
www.haskell.org; for the full list, see

    https://mail.haskell.org/cgi-bin/mailman/listinfo

Some GHC developers hang out on #haskell on IRC, too:

    http://www.haskell.org/haskellwiki/IRC_channel

Please report bugs using our bug tracking system.  Instructions on
reporting bugs can be found here:

    http://www.haskell.org/ghc/reportabug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: 

From johannes.waldmann at htwk-leipzig.de  Fri Apr 20 07:31:57 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 20 Apr 2018 09:31:57 +0200
Subject: [Haskell-cafe] building ghc-8.4.2 from source: undefined reference
	to 'mpz_powm_sec'
Message-ID: <5c5cee69-28ae-50cd-e02e-d7eec10e3a8c@htwk-leipzig.de>

Dear Cafe,

I am getting this when building ghc-8.4.2 from source,
with ghc-8.2.2:

ghc-8.4.2/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-1.0.2.0_p.a(wrappers.p_o):wrappers.c:function
integer_gmp_powm_sec: error: undefined reference to 'mpz_powm_sec'
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
make[1]: *** [iserv/ghc.mk:104: iserv/stage2_p/build/tmp/ghc-iserv-prof]
Error 1

This may be due to some mis-config on my part,
because I'm getting this on one machine only, and it works on others.

Still, perhaps you have seen this before, and could help me with
an educated guess on what may have caused this.

It is especially puzzling because this install of ghc-8.2.2
seems to work perfectly fine for all of my projects.

Thanks - J.W.

From joshchia at gmail.com  Fri Apr 20 09:36:44 2018
From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=)
Date: Fri, 20 Apr 2018 17:36:44 +0800
Subject: [Haskell-cafe] building ghc-8.4.2 from source: undefined
 reference to 'mpz_powm_sec'
In-Reply-To: <5c5cee69-28ae-50cd-e02e-d7eec10e3a8c@htwk-leipzig.de>
References: <5c5cee69-28ae-50cd-e02e-d7eec10e3a8c@htwk-leipzig.de>
Message-ID: 

You can start by checking whether you have libgmp and whether it has the
referenced symbol, e.g. on my machine, there's a /usr/lib64/libgmp.a, and I
get this:

$ nm /usr/lib64/libgmp.a | grep mpz_powm_sec
0000000000000000 T __gmpz_powm_sec

I'm not sure what the relationship is between __gmpz_powm_sec
and mpz_powm_sec, though it may be just some naming convention.

Without knowing much about various versions of GHC or libgmp, I think it's
possible that newer GHC requires newer libgmp that has this symbol and you
have an older libgmp.

Josh

On Fri, Apr 20, 2018 at 3:31 PM, Johannes Waldmann <
johannes.waldmann at htwk-leipzig.de> wrote:

> Dear Cafe,
>
> I am getting this when building ghc-8.4.2 from source,
> with ghc-8.2.2:
>
> ghc-8.4.2/libraries/integer-gmp/dist-install/build/
> libHSinteger-gmp-1.0.2.0_p.a(wrappers.p_o):wrappers.c:function
> integer_gmp_powm_sec: error: undefined reference to 'mpz_powm_sec'
> collect2: error: ld returned 1 exit status
> `gcc' failed in phase `Linker'. (Exit code: 1)
> make[1]: *** [iserv/ghc.mk:104: iserv/stage2_p/build/tmp/ghc-iserv-prof]
> Error 1
>
> This may be due to some mis-config on my part,
> because I'm getting this on one machine only, and it works on others.
>
> Still, perhaps you have seen this before, and could help me with
> an educated guess on what may have caused this.
>
> It is especially puzzling because this install of ghc-8.2.2
> seems to work perfectly fine for all of my projects.
>
> Thanks - J.W.
> _______________________________________________
> 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 johannes.waldmann at htwk-leipzig.de  Fri Apr 20 10:05:10 2018
From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann)
Date: Fri, 20 Apr 2018 12:05:10 +0200
Subject: [Haskell-cafe] building ghc-8.4.2 from source: undefined
 reference to 'mpz_powm_sec'
In-Reply-To: 
References: <5c5cee69-28ae-50cd-e02e-d7eec10e3a8c@htwk-leipzig.de>
 
Message-ID: <68030cdd-5fe5-0370-b3d8-ca4ec9ebfc2c@htwk-leipzig.de>

Hi

> You can start by checking whether you have libgmp 

ah yes, I was missing the "gmp-static" package (on Fedora)
so the compilation picked up some other gmp version
installed someplace else. (Worse, since I had "gmp-devel",
I think it picked the .so from one place, and .a from another.)
Thanks, and sorry for the noise.

- J.W.

From manny at fpcomplete.com  Fri Apr 20 12:25:02 2018
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Fri, 20 Apr 2018 05:25:02 -0700
Subject: [Haskell-cafe] ANN: stack-1.7 RELEASE CANDIDATE
Message-ID: 

This is the second release candidate for stack-1.7 (the first was short-lived and never widely announced).  

Binaries for supported platforms are available here: https://github.com/commercialhaskell/stack/releases/tag/v1.7.0.3 .

You easily upgrade to it using: `stack upgrade --binary-version=1.7.0.3`

## Changes since v1.6.5:

Release notes:

* aarch64 (64-bit ARM) bindists are now available for the first time.
* Statically linked Linux bindists are no longer available, due to difficulty with GHC 8.2.2 on Alpine Linux.
* 32-bit Linux GMP4 bindists for CentOS 6 are no longer available, since GHC 8.2.2 is no longer being built for that platform.

Major changes:

* Upgrade from Cabal 2.0 to Cabal 2.2

Behavior changes:

* `stack setup` no longer uses different GHC configure options on Linux
  distributions that use GCC with PIE enabled by default.  GHC detects
  this itself since ghc-8.0.2, and Stack's attempted workaround for older
  versions caused more problems than it solved.

* `stack new` no longer initializes a project if the project template contains
   a stack.yaml file.

Other enhancements:

* `stack unpack` now supports a `--to /target/directory` option to
  specify where to unpack the package into
* `stack hoogle` now supports a new flag `--server` that launches local
  Hoogle server on port 8080. See
  [#2310](https://github.com/commercialhaskell/stack/issues/2310)
* A new sub command `ls` has been introduced to stack to view
  local and remote snapshots present in the system. Use `stack ls
  snapshots --help` to get more details about it.
* `list-dependencies` has been deprecated. The functionality has
  to accessed through the new `ls dependencies` interface. See
  [#3669](https://github.com/commercialhaskell/stack/issues/3669)
  for details.
* Specify User-Agent HTTP request header on every HTTP request.
  See [#3628](https://github.com/commercialhaskell/stack/issues/3628) for details.
* `stack setup` looks for GHC bindists and installations by any OS key
  that is compatible (rather than only checking a single one).   This is
  relevant on Linux where different distributions may have different
  combinations of libtinfo 5/6, ncurses 5/6, and gmp 4/5, and will allow
  simpifying the setup-info metadata YAML for future GHC releases.
* The build progress bar reports names of packages currently building.
* `stack setup --verbose` causes verbose output of GHC configure process.
  See [#3716](https://github.com/commercialhaskell/stack/issues/3716)
* Improve the error message when an `extra-dep` from a path or git reference can't be found
  See [#3808](https://github.com/commercialhaskell/stack/pull/3808)
* Nix integration is now disabled on windows even if explicitly enabled,
  since it isn't supported. See
  [#3600](https://github.com/commercialhaskell/stack/issues/3600)
* `stack build` now supports a new flag `--keep-tmp-files` to retain intermediate
  files and directories for the purpose of debugging.
  It is best used with ghc's equivalent flag,
  i.e. `stack build --keep-tmp-files --ghc-options=-keep-tmp-files`.
  See [#3857](https://github.com/commercialhaskell/stack/issues/3857)
* Improved error messages for snapshot parse exceptions

Bug fixes:

* When a package contained sublibraries, stack was always recompiling the
  package. This has been fixed now, no recompilation is being done because of
  sublibraries. See [#3899](https://github.com/commercialhaskell/stack/issues/3899).
* The `get-stack.sh` install script now matches manual instructions
  when it comes to Debian/Fedora/CentOS install dependencies.
* Compile Cabal-simple with gmp when using Nix.
  See [#2944](https://github.com/commercialhaskell/stack/issues/2944)
* `stack ghci` now replaces the stack process with ghci. This improves
  signal handling behavior. In particular, handling of Ctrl-C.  To make
  this possible, the generated files are now left behind after exit.
  The paths are based on hashing file contents, and it's stored in the
  system temporary directory, so this shouldn't result in too much
  garbage. See
  [#3821](https://github.com/commercialhaskell/stack/issues/3821).
* The script interpreter's implicit file arguments are now passed before other
  arguments. See [#3658](https://github.com/commercialhaskell/stack/issues/3658).
  In particular, this makes it possible to pass `-- +RTS ... -RTS` to specify
  RTS arguments used when running the script.
* Don't ignore the template `year` parameter in config files, and clarify the
  surrounding documentation. See
  [#2275](https://github.com/commercialhaskell/stack/issues/2275).
* Benchmarks used to be run concurrently with other benchmarks
  and build steps. This is non-ideal because CPU usage of other processes
  may interfere with benchmarks. It also prevented benchmark output from
  being displayed by default. This is now fixed. See
  [#3663](https://github.com/commercialhaskell/stack/issues/3663).
* `stack ghci` now allows loading multiple packages with the same
  module name, as long as they have the same filepath. See
  [#3776](https://github.com/commercialhaskell/stack/pull/3776).
* `stack ghci` no longer always adds a dependency on `base`. It is
  now only added when there are no local targets. This allows it to
  be to load code that uses replacements for `base`. See
  [#3589](https://github.com/commercialhaskell/stack/issues/3589#issuecomment)
* `stack ghci` now uses correct paths for autogen files with
  [#3791](https://github.com/commercialhaskell/stack/issues/3791)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marc at lamarciana.com  Fri Apr 20 15:05:10 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 20 Apr 2018 17:05:10 +0200 (CEST)
Subject: [Haskell-cafe] Selda, type operators and heterogeneous lists
In-Reply-To: 
References: 
 <20180413141543.GA22299@weber> 
 <20180414070927.GB22299@weber>
 
 
Message-ID: 

> I would argue that in this case existential types actually are the correct tool. What you want to do is hide some amount of type information,
> which is exactly what existential types do. Then, because createTable can handle any Table a when you unwrap the Table from the existential type
> you can still pass it to createTable.

Thanks Jake for your response. I think it makes a lot of sense. I'll
give it a try.

Marc Busqué
http://waiting-for-dev.github.io/about/

From marc at lamarciana.com  Fri Apr 20 18:33:10 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 20 Apr 2018 20:33:10 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
Message-ID: 

Hi!

I'm using [selda](https://hackage.haskell.org/package/selda) package in
order to deal with database backends.

Selda uses `TypeOperators` language extension, and it introduces  `:*:`
type operator constructor which take concrete types like `RowID` or
`Text` . It also has a `Table` type constructor which takes anything
built with `:*:`). On the other hand, `SeldaM` is selda custom monad
transformer with `IO` at the bottom.

I have following helper function which just wraps a call to the SQLite
backend. `dBPath` is just the database file path:

```
withDB :: SeldaM a -> IO a
withDB act = do
   path <- dBPath
   withSQLite path act
```

I want to wrap selda API in custom functions to be more resilient to
changes. Right now I'm trying to abstract selecting all rows for a given
table (maybe it seems brittle, but it is just a toy project in order to
learn Haskell):

```
list table = withDB $ query (select table) 
```

Not adding a type signature to `list` produces following compilation
error:

```
• Non type-variable argument
     in the constraint: selda-0.1.12.1:Database.Selda.Column.Columns
                          (selda-0.1.12.1:Database.Selda.Column.Cols s a)
   (Use FlexibleContexts to permit this)
• When checking the inferred type
     list :: forall s a.
             (selda-0.1.12.1:Database.Selda.Column.Columns
                (selda-0.1.12.1:Database.Selda.Column.Cols s a),
              selda-0.1.12.1:Database.Selda.Compile.Result
                (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
             Table a
             -> IO
                  [selda-0.1.12.1:Database.Selda.Compile.Res
                     (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
```

If I try to add what I think would be the correct signature:

```
list :: Table a -> IO [a]
```

The error changes to:

```
• Couldn't match type ‘a’
                  with ‘selda-0.1.12.1:Database.Selda.Compile.Res
                          (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)’
   ‘a’ is a rigid type variable bound by
     the type signature for:
       list :: forall a. Table a -> IO [a]
     at src/Hedger/Category.hs:35:1-25
   Expected type: SeldaM [a]
     Actual type: selda-0.1.12.1:Database.Selda.Backend.Internal.SeldaT
                    IO
                    [selda-0.1.12.1:Database.Selda.Compile.Res
                       (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)]
• In the second argument of ‘($)’, namely ‘query (select table)’
   In the expression: withDB $ query (select table)
   In an equation for ‘list’:
       list table = withDB $ query (select table)
• Relevant bindings include
     table :: Table a (bound at src/Hedger/Category.hs:36:6)
     list :: Table a -> IO [a] (bound at src/Hedger/Category.hs:36:1)
    |
36 | list table = withDB $ query (select table)
```

However, if I constraint the type signature to act just for a given
table, it compiles without errors:

```
type CategoriesSchema = RowID:*:Text
list :: Table CategoriesSchema -> IO [CategoriesSchema]
```

Why is that it works with concrete types but not with a type variable
that takes the same concrete type in its both placeholders?

Thanks in advance,

Marc Busqué
http://waiting-for-dev.github.io/about/

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Fri Apr 20 18:39:34 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Fri, 20 Apr 2018 19:39:34 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
Message-ID: <20180420183934.GC3956@weber>

On Fri, Apr 20, 2018 at 08:33:10PM +0200, Marc Busqué wrote:
> Not adding a type signature to `list` produces following compilation
> error:
> 
[...]
>   (Use FlexibleContexts to permit this)
>
> Why is that it works with concrete types but not with a type variable
> that takes the same concrete type in its both placeholders?

Did you try applying the suggested fix?  Explicitly, add

{-# LANGUAGE FlexibleContexts #-}

at the top of your file to permit this.

From marc at lamarciana.com  Fri Apr 20 18:46:30 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 20 Apr 2018 20:46:30 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180420183934.GC3956@weber>
References: 
 <20180420183934.GC3956@weber>
Message-ID: 

On Fri, 20 Apr 2018, Tom Ellis wrote:

> Did you try applying the suggested fix?  Explicitly, add
>
> {-# LANGUAGE FlexibleContexts #-}
>
> at the top of your file to permit this.

It doesn't work neither. In this case the error is:

```
• Couldn't match type ‘selda-0.1.12.1:Database.Selda.Compile.Res
                          (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)’
                  with ‘selda-0.1.12.1:Database.Selda.Compile.Res
                          (selda-0.1.12.1:Database.Selda.Column.Cols s a)’
   Expected type: Table a
                  -> IO
                       [selda-0.1.12.1:Database.Selda.Compile.Res
                          (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
     Actual type: Table a
                  -> IO
                       [selda-0.1.12.1:Database.Selda.Compile.Res
                          (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)]
   NB: ‘selda-0.1.12.1:Database.Selda.Compile.Res’ is a type function, and may not be injective
   The type variable ‘s0’ is ambiguous
• In the ambiguity check for the inferred type for ‘list’
   To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
   When checking the inferred type
     list :: forall s a.
             (selda-0.1.12.1:Database.Selda.Column.Columns
                (selda-0.1.12.1:Database.Selda.Column.Cols s a),
              selda-0.1.12.1:Database.Selda.Compile.Result
                (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
             Table a
             -> IO
                  [selda-0.1.12.1:Database.Selda.Compile.Res
                     (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
    |
36 | list table = withDB $ query (select table)
```

Anyway, I'm more interested in understanding an explicit type signature,
in this case.

Marc Busqué
http://waiting-for-dev.github.io/about/

From allbery.b at gmail.com  Fri Apr 20 18:47:59 2018
From: allbery.b at gmail.com (Brandon Allbery)
Date: Fri, 20 Apr 2018 14:47:59 -0400
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
Message-ID: 

The more precise answer to your question is that an explicit type signature
is taken as exact. If the type needed is some (Ctx a => a), as here, but
your type signature just says a, you will get a type error exactly as you
did.

"a" there does not mean "figure out a type for me". It means *any type at
all*. Including Void, (), Int, etc., which one would not expect to work
there.

On Fri, Apr 20, 2018 at 2:33 PM, Marc Busqué  wrote:

> Hi!
>
> I'm using [selda](https://hackage.haskell.org/package/selda) package in
> order to deal with database backends.
>
> Selda uses `TypeOperators` language extension, and it introduces  `:*:`
> type operator constructor which take concrete types like `RowID` or
> `Text` . It also has a `Table` type constructor which takes anything
> built with `:*:`). On the other hand, `SeldaM` is selda custom monad
> transformer with `IO` at the bottom.
>
> I have following helper function which just wraps a call to the SQLite
> backend. `dBPath` is just the database file path:
>
> ```
> withDB :: SeldaM a -> IO a
> withDB act = do
>   path <- dBPath
>   withSQLite path act
> ```
>
> I want to wrap selda API in custom functions to be more resilient to
> changes. Right now I'm trying to abstract selecting all rows for a given
> table (maybe it seems brittle, but it is just a toy project in order to
> learn Haskell):
>
> ```
> list table = withDB $ query (select table) ```
>
> Not adding a type signature to `list` produces following compilation
> error:
>
> ```
> • Non type-variable argument
>     in the constraint: selda-0.1.12.1:Database.Selda.Column.Columns
>                          (selda-0.1.12.1:Database.Selda.Column.Cols s a)
>   (Use FlexibleContexts to permit this)
> • When checking the inferred type
>     list :: forall s a.
>             (selda-0.1.12.1:Database.Selda.Column.Columns
>                (selda-0.1.12.1:Database.Selda.Column.Cols s a),
>              selda-0.1.12.1:Database.Selda.Compile.Result
>                (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
>             Table a
>             -> IO
>                  [selda-0.1.12.1:Database.Selda.Compile.Res
>                     (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
> ```
>
> If I try to add what I think would be the correct signature:
>
> ```
> list :: Table a -> IO [a]
> ```
>
> The error changes to:
>
> ```
> • Couldn't match type ‘a’
>                  with ‘selda-0.1.12.1:Database.Selda.Compile.Res
>                          (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)’
>   ‘a’ is a rigid type variable bound by
>     the type signature for:
>       list :: forall a. Table a -> IO [a]
>     at src/Hedger/Category.hs:35:1-25
>   Expected type: SeldaM [a]
>     Actual type: selda-0.1.12.1:Database.Selda.Backend.Internal.SeldaT
>                    IO
>                    [selda-0.1.12.1:Database.Selda.Compile.Res
>                       (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)]
> • In the second argument of ‘($)’, namely ‘query (select table)’
>   In the expression: withDB $ query (select table)
>   In an equation for ‘list’:
>       list table = withDB $ query (select table)
> • Relevant bindings include
>     table :: Table a (bound at src/Hedger/Category.hs:36:6)
>     list :: Table a -> IO [a] (bound at src/Hedger/Category.hs:36:1)
>    |
> 36 | list table = withDB $ query (select table)
> ```
>
> However, if I constraint the type signature to act just for a given
> table, it compiles without errors:
>
> ```
> type CategoriesSchema = RowID:*:Text
> list :: Table CategoriesSchema -> IO [CategoriesSchema]
> ```
>
> Why is that it works with concrete types but not with a type variable
> that takes the same concrete type in its both placeholders?
>
> Thanks in advance,
>
> Marc Busqué
> http://waiting-for-dev.github.io/about/
> _______________________________________________
> 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 marc at lamarciana.com  Fri Apr 20 19:20:48 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Fri, 20 Apr 2018 21:20:48 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Apr 2018, Brandon Allbery wrote:

> The more precise answer to your question is that an explicit type signature is taken as exact. If the type needed is some (Ctx a => a), as here,
> but your type signature just says a, you will get a type error exactly as you did.
> "a" there does not mean "figure out a type for me". It means *any type at all*. Including Void, (), Int, etc., which one would not expect to work
> there.

Thanks! That was an illuminating answer :)

Marc Busqué
http://waiting-for-dev.github.io/about/

From dominic at steinitz.org  Sun Apr 22 14:25:18 2018
From: dominic at steinitz.org (dominic at steinitz.org)
Date: Sun, 22 Apr 2018 15:25:18 +0100
Subject: [Haskell-cafe] New Version of hmatrix (more ODE solvers)
Message-ID: <2AC8F7D0-05AA-4DB7-8311-E7B664A893DF@steinitz.org>

I am pleased to announce a new version of hmatrix: 0.19.0.0.

This is not intended to be a breaking change but a lot of modules have been modified to ensure that continuous integration (which has now been set up) is green.
Support for SUNDIALS  has been added. It should be possible to replace Numeric.GSL.ODE with Numeric.Sundials.ARKode.ODE and have your program work as before bearing in mind that the methods and error control might differ (even for those with the same names!).
The packages that comprise hmatrix are:

hmatrix
hmatrix-gsl
hmatrix-special
hmatrix-sparse
hmatrix-glpk
hmatrix-tests
hmatrix-sundials
I am planning to split these up into separate projects to make it easier for contributors. To this end, I have created an hmatrix  organisation in github. Please contact me if you wish to become a member.

I strongly recommend anyone solving ODEs to look as hmatrix-sundials as the underlying package provides many more methods, more documentation and more diagnostic information (great when your 200 variable model fails). It is a truism that any sufficiently sophisticated ODE solver package is a domain specific language (I include the ODE solving part of GSL here). The current interface both to GSL and to SUNDIALS is somewhat rudimentary but will hopefully evovle to a nicer DSL (something at which Haskell excels).

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com
Twitter: @idontgetoutmuch



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From marc at lamarciana.com  Sun Apr 22 18:21:11 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Sun, 22 Apr 2018 20:21:11 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 20 Apr 2018, Brandon Allbery wrote:

> The more precise answer to your question is that an explicit type signature is taken as exact. If the type needed is some (Ctx a => a), as here,
> but your type signature just says a, you will get a type error exactly as you did.
> "a" there does not mean "figure out a type for me". It means *any type at all*. Including Void, (), Int, etc., which one would not expect to work
> there.

I'm still in troubles with this...

If I add `FlexibleContexts` and `AllowAmbiguosTypes` extensions, I can
compile the program and ask for the type of `list`:

```
:t list 
--- list
---   :: (selda-0.1.12.1:Database.Selda.Compile.Result
---         (selda-0.1.12.1:Database.Selda.Column.Cols s a),
---       selda-0.1.12.1:Database.Selda.Column.Columns
---         (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
---      selda-0.1.12.1:Database.Selda.Table.Table a
---      -> IO
---           [selda-0.1.12.1:Database.Selda.Compile.Res
---              (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
```

However, manually adding this same type:

```
list :: (Result (Cols s a), Columns (Cols s a))  => Table a -> IO [Res (Cols s a)]
list table = withDB $ query (select table)
```

results in a compilation error:

```
• Couldn't match type ‘Res (Cols s0 a)’ with ‘Res (Cols s a)’
   Expected type: IO [Res (Cols s a)]
     Actual type: IO [Res (Cols s0 a)]
   NB: ‘Res’ is a type function, and may not be injective
   The type variable ‘s0’ is ambiguous
• In the expression: withDB $ query (select table)
   In an equation for ‘list’:
       list table = withDB $ query (select table)
• Relevant bindings include
     table :: Table a (bound at src/Hedger/Category.hs:44:6)
     list :: Table a -> IO [Res (Cols s a)]
       (bound at src/Hedger/Category.hs:44:1)
    |
44 | list table = withDB $ query (select table)
```

I'm pretty sure that my error is related with what is exposed in this
page in the wiki: https://wiki.haskell.org/GHC/TypeSigsAndAmbiguity

But I'm not sure about how I could fix that. At the end of the article
it is said that this only happen in programs that "they could never
really work". But, if I'm not missing something, that function does work.
I have tried it with the auto-inferred signature way and it indeed can
list rows for different database tables.

I leave here more info just in case it is useful:

```
:t select
--- select :: Columns (Cols s a) => Table a -> Query s (Cols s a)

:t query
--- query :: (Result a, MonadSelda m) => Query s a -> m [Res a]

:t withDB
--- withDB :: SeldaM a -> IO a

:info Columns
class Columns a where
--- selda-0.1.12.1:Database.Selda.Column.toTup :: [ColName] -> a
--- selda-0.1.12.1:Database.Selda.Column.fromTup :: a
---                                                   -> [selda-0.1.12.1:Database.Selda.Exp.SomeCol
---                                                         selda-0.1.12.1:Database.Selda.SQL.SQL]
---   {-# MINIMAL toTup, fromTup #-}
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Column’
--- instance forall k (s :: k) a. Columns (Col s a)
---   -- Defined in ‘selda-0.1.12.1:Database.Selda.Column’
--- instance forall k b (s :: k) a.
---          Columns b =>
---          Columns (Col s a :*: b)
---   -- Defined in ‘selda-0.1.12.1:Database.Selda.Column’

:info Cols
--- type family Cols (s :: k) a :: *
---   where
---     [k, (s :: k), a, b] Cols k s (a :*: b) = Col s a :*: Cols s b
---     [k, (s :: k), a] Cols k s a = Col s a
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Column’

:info Result
--- class base-4.10.1.0:Data.Typeable.Internal.Typeable (Res r) =>
---       Result r where
---   type family Res r :: *
---   selda-0.1.12.1:Database.Selda.Compile.toRes :: Data.Proxy.Proxy r
---                                                  -> [selda-0.1.12.1:Database.Selda.SqlType.SqlValue]
---                                                  -> Res r
---   selda-0.1.12.1:Database.Selda.Compile.finalCols :: r
---                                                      -> [selda-0.1.12.1:Database.Selda.Exp.SomeCol
---                                                            selda-0.1.12.1:Database.Selda.SQL.SQL]
---   {-# MINIMAL toRes, finalCols #-}
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’
--- instance SqlType a => Result (Col s a)
---   -- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’
--- instance (SqlType a, Result b) => Result (Col s a :*: b)
---   -- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’

:info Res
--- class base-4.10.1.0:Data.Typeable.Internal.Typeable (Res r) =>
---       Result r where
---   type family Res r :: *
---   ...
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’
--- type instance Res (Col s a) = a
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’
--- type instance Res (Col s a :*: b) = a :*: Res b
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Compile’

:info Table
--- type role Table phantom
--- data Table a
---   = selda-0.1.12.1:Database.Selda.Table.Table {selda-0.1.12.1:Database.Selda.Table.tableName :: TableName,
---                                                selda-0.1.12.1:Database.Selda.Table.tableCols :: [selda-0.1.12.1:Database.Selda.Table.ColInfo],
---                                                selda-0.1.12.1:Database.Selda.Table.tableHasAutoPK :: Bool}
---   	-- Defined in ‘selda-0.1.12.1:Database.Selda.Table’
```

Marc Busqué
http://waiting-for-dev.github.io/about/
> 
> On Fri, Apr 20, 2018 at 2:33 PM, Marc Busqué  wrote:
>       Hi!
>
>       I'm using [selda](https://hackage.haskell.org/package/selda) package in
>       order to deal with database backends.
>
>       Selda uses `TypeOperators` language extension, and it introduces  `:*:`
>       type operator constructor which take concrete types like `RowID` or
>       `Text` . It also has a `Table` type constructor which takes anything
>       built with `:*:`). On the other hand, `SeldaM` is selda custom monad
>       transformer with `IO` at the bottom.
>
>       I have following helper function which just wraps a call to the SQLite
>       backend. `dBPath` is just the database file path:
>
>       ```
>       withDB :: SeldaM a -> IO a
>       withDB act = do
>         path <- dBPath
>         withSQLite path act
>       ```
>
>       I want to wrap selda API in custom functions to be more resilient to
>       changes. Right now I'm trying to abstract selecting all rows for a given
>       table (maybe it seems brittle, but it is just a toy project in order to
>       learn Haskell):
>
>       ```
>       list table = withDB $ query (select table) ```
>
>       Not adding a type signature to `list` produces following compilation
>       error:
>
>       ```
>       • Non type-variable argument
>           in the constraint: selda-0.1.12.1:Database.Selda.Column.Columns
>                                (selda-0.1.12.1:Database.Selda.Column.Cols s a)
>         (Use FlexibleContexts to permit this)
>       • When checking the inferred type
>           list :: forall s a.
>                   (selda-0.1.12.1:Database.Selda.Column.Columns
>                      (selda-0.1.12.1:Database.Selda.Column.Cols s a),
>                    selda-0.1.12.1:Database.Selda.Compile.Result
>                      (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
>                   Table a
>                   -> IO
>                        [selda-0.1.12.1:Database.Selda.Compile.Res
>                           (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
>       ```
>
>       If I try to add what I think would be the correct signature:
>
>       ```
>       list :: Table a -> IO [a]
>       ```
>
>       The error changes to:
>
>       ```
>       • Couldn't match type ‘a’
>                        with ‘selda-0.1.12.1:Database.Selda.Compile.Res
>                                (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)’
>         ‘a’ is a rigid type variable bound by
>           the type signature for:
>             list :: forall a. Table a -> IO [a]
>           at src/Hedger/Category.hs:35:1-25
>         Expected type: SeldaM [a]
>           Actual type: selda-0.1.12.1:Database.Selda.Backend.Internal.SeldaT
>                          IO
>                          [selda-0.1.12.1:Database.Selda.Compile.Res
>                             (selda-0.1.12.1:Database.Selda.Column.Cols s0 a)]
>       • In the second argument of ‘($)’, namely ‘query (select table)’
>         In the expression: withDB $ query (select table)
>         In an equation for ‘list’:
>             list table = withDB $ query (select table)
>       • Relevant bindings include
>           table :: Table a (bound at src/Hedger/Category.hs:36:6)
>           list :: Table a -> IO [a] (bound at src/Hedger/Category.hs:36:1)
>          |
>       36 | list table = withDB $ query (select table)
>       ```
>
>       However, if I constraint the type signature to act just for a given
>       table, it compiles without errors:
>
>       ```
>       type CategoriesSchema = RowID:*:Text
>       list :: Table CategoriesSchema -> IO [CategoriesSchema]
>       ```
>
>       Why is that it works with concrete types but not with a type variable
>       that takes the same concrete type in its both placeholders?
>
>       Thanks in advance,
>
>       Marc Busqué
>       http://waiting-for-dev.github.io/about/
>       _______________________________________________
>       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
> 
>

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Sun Apr 22 19:18:33 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Sun, 22 Apr 2018 20:18:33 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
 
Message-ID: <20180422191833.GB12914@weber>

On Sun, Apr 22, 2018 at 08:21:11PM +0200, Marc Busqué wrote:
> If I add `FlexibleContexts` and `AllowAmbiguosTypes` extensions, I can
> compile the program and ask for the type of `list`:
> 
> ```
> :t list --- list
> ---   :: (selda-0.1.12.1:Database.Selda.Compile.Result
> ---         (selda-0.1.12.1:Database.Selda.Column.Cols s a),
> ---       selda-0.1.12.1:Database.Selda.Column.Columns
> ---         (selda-0.1.12.1:Database.Selda.Column.Cols s a)) =>
> ---      selda-0.1.12.1:Database.Selda.Table.Table a
> ---      -> IO
> ---           [selda-0.1.12.1:Database.Selda.Compile.Res
> ---              (selda-0.1.12.1:Database.Selda.Column.Cols s a)]
> ```
> 
> However, manually adding this same type:
> 
> ```
> list :: (Result (Cols s a), Columns (Cols s a))  => Table a -> IO [Res (Cols s a)]
> list table = withDB $ query (select table)
> ```
> 
> results in a compilation error:

Unless I am much mistaken `Cols s a` is just `a`[1,2].  That explains why
the type is ambiguous.  There's nothing that fixes `s`.

> But I'm not sure about how I could fix that. At the end of the article
> it is said that this only happen in programs that "they could never
> really work". But, if I'm not missing something, that function does work.
> I have tried it with the auto-inferred signature way and it indeed can
> list rows for different database tables.

Can you show us a minimal example of `list` working?  I'm quite confused
about how it could work.

Tom


[1] https://www.stackage.org/haddock/lts-9.14/selda-0.1.11.1/src/Database.Selda.Compile.html#line-126)

[2] https://www.stackage.org/haddock/lts-9.14/selda-0.1.11.1/Database-Selda.html#t:Cols

From marc at lamarciana.com  Mon Apr 23 07:23:58 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 09:23:58 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180422191833.GB12914@weber>
References: 
 
  <20180422191833.GB12914@weber>
Message-ID: 

On Sun, 22 Apr 2018, Tom Ellis wrote:

> Unless I am much mistaken `Cols s a` is just `a`[1,2].  That explains why
> the type is ambiguous.  There's nothing that fixes `s`.

I also thought that, but if I substitute `Cols s a` by `a`, then the
compilation error is:

```
• Couldn't match type ‘Res (Cols s0 a)’ with ‘Res a’
   Expected type: IO [Res a]
     Actual type: IO [Res (Cols s0 a)]
   NB: ‘Res’ is a type function, and may not be injective
   The type variable ‘s0’ is ambiguous
• In the expression: withDB $ query (select table)
   In an equation for ‘list’:
       list table = withDB $ query (select table)
• Relevant bindings include
     table :: Table a (bound at src/Hedger/Category.hs:44:6)
     list :: Table a -> IO [Res a]
       (bound at src/Hedger/Category.hs:44:1)
    |
44 | list table = withDB $ query (select table)
```

Also, notice that the inferred type does differentiate between `Cols s a` and `a`.

> Can you show us a minimal example of `list` working?  I'm quite confused
> about how it could work.

```
type CategoriesSchema = RowID:*:Text
type ExpensesSchema = RowID:*:Text:*:Double:*:RowID

categories:: Table (CategoriesSchema)
(categories, categoryID :*: rest) = tableWithSelectors "categories"
     $ autoPrimary "id"
     :*: required "name"

expenses:: Table (ExpensesSchema)
expenses = table "expenses"
     $ autoPrimary "id"
     :*: required "name"
     :*: required "amount"
     :*: required "category_id" `fk` (categories, categoryID)

withDB (tryCreateTable categories)
withDB (tryCreateTable expenses)

withDB $ insert_ categories [ def :*: "foo" ]

list categories
--- [1 :*: "foo"]

list expenses
--- []

Marc Busqué
http://waiting-for-dev.github.io/about/

From lysxia at gmail.com  Mon Apr 23 11:58:56 2018
From: lysxia at gmail.com (Li-yao Xia)
Date: Mon, 23 Apr 2018 07:58:56 -0400
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
 
Message-ID: <77ffa81d-8c37-3b4e-7f67-0ce376752b63@gmail.com>

Hi Marc,

> ```
> list :: (Result (Cols s a), Columns (Cols s a))  => Table a -> IO [Res 
> (Cols s a)]
> list table = withDB $ query (select table)
> ```

The only occurence of `s`/`s0` that is not ambiguous is between `select` 
and `query`, as the first argument of the data type `Query`. Everywhere 
else, there is a type family in the way which prevents unification; for 
example `Cols s a ~ Cols s0 a` does not imply `s ~ s0`.

You can use a type annotation or TypeApplications to instantiate the 
`s0` between `query` and `select`. This requires ScopedTypeVariables, 
and an explicit `forall` at the top to make the type variables available 
in the definition body.

Note that the type of `list` is also ambiguous for the aforementioned 
reasons, since `s` is only an argument of the type family `Res` (and 
`Cols`). You will have to AllowAmbiguousTypes to define it and write 
`list @s` (with TypeApplications) to use it.

```
{-# LANGUAGE AllowAmbiguousTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}

list :: forall s a. (Result (Cols s a), Columns (Cols s a))
      => Table a -> IO [Res (Cols s a)]
list table = withDB $ query (select table :: Query s _)
-- or,                  ... (select @s table)
-- with {-# LANGUAGE TypeApplications #-}
```

References in the GHC manual:

- ScopedTypeVariables: 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#lexically-scoped-type-variables

- TypeApplications: 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application

- AllowAmbiguousTypes: 
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#ambiguous-types-and-the-ambiguity-check

Li-yao

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Apr 23 12:16:50 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 23 Apr 2018 13:16:50 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
 
 <20180422191833.GB12914@weber>
 
Message-ID: <20180423121650.GD12914@weber>

On Mon, Apr 23, 2018 at 09:23:58AM +0200, Marc Busqué wrote:
> On Sun, 22 Apr 2018, Tom Ellis wrote:
> >Unless I am much mistaken `Cols s a` is just `a`[1,2].  That explains why
> >the type is ambiguous.  There's nothing that fixes `s`.
> 
> I also thought that, but if I substitute `Cols s a` by `a`, then the
> compilation error is:

I had an error in what I said and also it was imprecise.  It's
`Res (Cols s a)` which is `a`, but only in the cases where you're actually
going to use it, and the compiler cannot take that into account when
solving the constraint.  Anyway, as Li-yao Xia points out in a sibling
message, the type variable `s` in not constrained and therefore it seems
impossible to solve.

> Also, notice that the inferred type does differentiate between `Cols s a` and `a`.
> 
> >Can you show us a minimal example of `list` working?  I'm quite confused
> >about how it could work.
[...]

Thanks, but could you send a full working version that includes a definition
of `list`?  I can't replicate what you've done on my end.

Tom


From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Apr 23 12:25:31 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 23 Apr 2018 13:25:31 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180423121650.GD12914@weber>
References: 
 
 
 <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber>
Message-ID: <20180423122531.GE12914@weber>

On Mon, Apr 23, 2018 at 01:16:50PM +0100, Tom Ellis wrote:
> Thanks, but could you send a full working version that includes a definition
> of `list`?  I can't replicate what you've done on my end.

And what GHC version are you using?  I can't replicate this on 7.10 or 8.0.

From leah at vuxu.org  Mon Apr 23 14:44:36 2018
From: leah at vuxu.org (Leah Neukirchen)
Date: Mon, 23 Apr 2018 16:44:36 +0200
Subject: [Haskell-cafe] Munich Haskell Meeting, 2018-04-26 @ 19:30
Message-ID: <871sf6yobv.fsf@gmail.com>

Dear all,

This week, our monthly Munich Haskell Meeting will take place again on
Thursday, April 26 at Augustiner-Gaststätte Rumpler at 19h30.
For details see here:

http://muenchen.haskell.bayern/dates.html

If you plan to join, please add yourself to this dudle so we can
reserve enough seats!  It is OK to add yourself to the dudle
anonymously or pseudonymously.

https://dudle.inf.tu-dresden.de/haskell-munich-apr-2018/

Everybody is welcome!

cu,
-- 
Leah Neukirchen    http://leah.zone

From marc at lamarciana.com  Mon Apr 23 14:45:11 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 16:45:11 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <77ffa81d-8c37-3b4e-7f67-0ce376752b63@gmail.com>
References: 
 
 
 <77ffa81d-8c37-3b4e-7f67-0ce376752b63@gmail.com>
Message-ID: 

On Mon, 23 Apr 2018, Li-yao Xia wrote:

> Hi Marc,
>
>> ```
>> list :: (Result (Cols s a), Columns (Cols s a))  => Table a -> IO [Res 
>> (Cols s a)]
>> list table = withDB $ query (select table)
>> ```
>
> The only occurence of `s`/`s0` that is not ambiguous is between `select` and 
> `query`, as the first argument of the data type `Query`. Everywhere else, 
> there is a type family in the way which prevents unification; for example 
> `Cols s a ~ Cols s0 a` does not imply `s ~ s0`.
>
> You can use a type annotation or TypeApplications to instantiate the `s0` 
> between `query` and `select`. This requires ScopedTypeVariables, and an 
> explicit `forall` at the top to make the type variables available in the 
> definition body.
>
> Note that the type of `list` is also ambiguous for the aforementioned 
> reasons, since `s` is only an argument of the type family `Res` (and `Cols`). 
> You will have to AllowAmbiguousTypes to define it and write `list @s` (with 
> TypeApplications) to use it.
>
> ```
> {-# LANGUAGE AllowAmbiguousTypes #-}
> {-# LANGUAGE ScopedTypeVariables #-}
>
> list :: forall s a. (Result (Cols s a), Columns (Cols s a))
>     => Table a -> IO [Res (Cols s a)]
> list table = withDB $ query (select table :: Query s _)
> -- or,                  ... (select @s table)
> -- with {-# LANGUAGE TypeApplications #-}
> ```
>
> References in the GHC manual:
>
> - ScopedTypeVariables: 
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#lexically-scoped-type-variables
>
> - TypeApplications: 
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#visible-type-application
>
> - AllowAmbiguousTypes: 
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#ambiguous-types-and-the-ambiguity-check
>
> Li-yao

Thanks Li-yao. I'll studiy it thoroughly. It looks promising.

Marc Busqué
http://waiting-for-dev.github.io/about/

From marc at lamarciana.com  Mon Apr 23 14:54:36 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 16:54:36 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180423121650.GD12914@weber>
References: 
 
  <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber>
Message-ID: 

On Mon, 23 Apr 2018, Tom Ellis wrote:

> I had an error in what I said and also it was imprecise.  It's
> `Res (Cols s a)` which is `a`, but only in the cases where you're actually
> going to use it, and the compiler cannot take that into account when
> solving the constraint.  Anyway, as Li-yao Xia points out in a sibling
> message, the type variable `s` in not constrained and therefore it seems
> impossible to solve.

Thanks Tom for your reply.

In this case the error is:

```
• Couldn't match type ‘a’ with ‘Res (Cols s0 a)’
       ‘a’ is a rigid type variable bound by
         the type signature for:
           list :: forall s a.
                   (Result (Cols s a), Columns (Cols s a)) =>
                   Table a -> IO [a]
         at src/Hedger/Backend.hs:24:1-69
       Expected type: selda-0.1.12.1:Database.Selda.Backend.Internal.SeldaM
                        [a]
         Actual type: selda-0.1.12.1:Database.Selda.Backend.Internal.SeldaT
                        IO [Res (Cols s0 a)]
     • In the second argument of ‘($)’, namely ‘query (select table)’
       In the expression: withDB $ query (select table)
       In an equation for ‘list’:
           list table = withDB $ query (select table)
     • Relevant bindings include
         table :: Table a (bound at src/Hedger/Backend.hs:25:6)
         list :: Table a -> IO [a] (bound at src/Hedger/Backend.hs:25:1)
    |
25 | list table = withDB $ query (select table)
```
> Thanks, but could you send a full working version that includes a definition
> of `list`?  I can't replicate what you've done on my end.

I have pushed the repo to Github:

https://github.com/waiting-for-dev/hedger

Important code is in `src/Hedger/` directory.

`Backend.hs` is where `list` is defined. Right now it has its type
signature commented out so that it compiles thanks to
`AllowAmbiguosTypes` and `FlexibleContexts`.

`Category.hs` has the function `listCategories` which uses `list`.
Anyway, from `ghci` one can just call `list categories` or `list
expenses`. There is also a helper function `addCategory` to add a
category record just providing its name (from `ghci`,
`OverloadedStrings` must be loaded).

In `Migration.hs` is where `categories` and `expenses` tables are
created.

Marc Busqué
http://waiting-for-dev.github.io/about/

From marc at lamarciana.com  Mon Apr 23 14:55:48 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 16:55:48 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180423122531.GE12914@weber>
References: 
 
  <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber> <20180423122531.GE12914@weber>
Message-ID: 

On Mon, 23 Apr 2018, Tom Ellis wrote:

> And what GHC version are you using?  I can't replicate this on 7.10 or 8.0.

I'm on 8.2.2.

Marc Busqué
http://waiting-for-dev.github.io/about/

From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Apr 23 16:48:40 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 23 Apr 2018 17:48:40 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
 
 <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber>
 
Message-ID: <20180423164840.GF12914@weber>

On Mon, Apr 23, 2018 at 04:54:36PM +0200, Marc Busqué wrote:
> On Mon, 23 Apr 2018, Tom Ellis wrote:
> >I had an error in what I said and also it was imprecise.  It's
> >`Res (Cols s a)` which is `a`, but only in the cases where you're actually
> >going to use it, and the compiler cannot take that into account when
> >solving the constraint.  Anyway, as Li-yao Xia points out in a sibling
> >message, the type variable `s` in not constrained and therefore it seems
> >impossible to solve.
> 
> I have pushed the repo to Github:
> 
> https://github.com/waiting-for-dev/hedger

Thanks for that Marc, it's very helpful.  I extracted the parts that are
relevant to the problem and created a version that doesn't depend on Selda:

    https://gist.github.com/tomjaguarpaw/f4db46671e2f39b790a25b8907dc53a3

I think I now understand what the situation is.  Interestingly your code
works on 8.0 but not 7.10.

Contrary to my earlier presumptions, the compiler *is* able to give a type
to `list` because `Cols` is a closed type family.  I suppose it can
determine that `Cols s a` does not actually depend on `s` so giving list the
type

    (Result (Cols s a), Columns (Cols s a)) => Table a -> Res (Cols s a)

is fine.  The type of `s` will never be needed.  When `list` is applied to
`categories` then `a` is fixed and `Res (Cols s a)` is fixed, regardless of
what `s` is.

Subtly changing the definition of Cols will break things.  For example, if
you add the clause

        Cols () a = Col Int a

then you won't be able to define `list` any more, even though `Res (Cols s
a)` is still just `a` because the `Columns (Cols s a)` instance might then
depend on what `s` is.

On the other hand, I do not yet understand why you cannot provide an
explicit signature for `list`.  I suspect this is some hairy compiler bug. 
Either it should be possible to give `list` its inferred type or it should
be forbidden.  It's probably worth filing an issue about this on GHC Trac.
I would be interested to hear Li-yao's thoughts on the matter.

Incidentally, this is why I try to avoid type families as much as possible. 
When they go wrong it's very hard to understand why, and indeed when they go
right it's also very hard to understand why.

Tom

From marc at lamarciana.com  Mon Apr 23 18:08:18 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 20:08:18 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180423164840.GF12914@weber>
References: 
 
  <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber> 
 <20180423164840.GF12914@weber>
Message-ID: 

Tom, thank you very much for your deep inspection. Your gist can be
really helpful in trying to understand the problem. I will study it
carefully. I have been reading books about Haskell and also Category
Theory for some months, but I have just started coding few weeks ago, so
I'm bit overwhelmed about having found a compiler bug so soon :D I'll
look into all of this and also about Li-yao recommendations and if it is
suitable I'll fill the issue and also report here.

Marc Busqué
http://waiting-for-dev.github.io/about/

On Mon, 23 Apr 2018, Tom Ellis wrote:

> On Mon, Apr 23, 2018 at 04:54:36PM +0200, Marc Busqué wrote:
>> On Mon, 23 Apr 2018, Tom Ellis wrote:
>> >I had an error in what I said and also it was imprecise.  It's
>> >`Res (Cols s a)` which is `a`, but only in the cases where you're actually
>> >going to use it, and the compiler cannot take that into account when
>> >solving the constraint.  Anyway, as Li-yao Xia points out in a sibling
>> >message, the type variable `s` in not constrained and therefore it seems
>> >impossible to solve.
>> 
>> I have pushed the repo to Github:
>> 
>> https://github.com/waiting-for-dev/hedger
>
> Thanks for that Marc, it's very helpful.  I extracted the parts that are
> relevant to the problem and created a version that doesn't depend on Selda:
>
>    https://gist.github.com/tomjaguarpaw/f4db46671e2f39b790a25b8907dc53a3
>
> I think I now understand what the situation is.  Interestingly your code
> works on 8.0 but not 7.10.
>
> Contrary to my earlier presumptions, the compiler *is* able to give a type
> to `list` because `Cols` is a closed type family.  I suppose it can
> determine that `Cols s a` does not actually depend on `s` so giving list the
> type
>
>    (Result (Cols s a), Columns (Cols s a)) => Table a -> Res (Cols s a)
>
> is fine.  The type of `s` will never be needed.  When `list` is applied to
> `categories` then `a` is fixed and `Res (Cols s a)` is fixed, regardless of
> what `s` is.
>
> Subtly changing the definition of Cols will break things.  For example, if
> you add the clause
>
>        Cols () a = Col Int a
>
> then you won't be able to define `list` any more, even though `Res (Cols s
> a)` is still just `a` because the `Columns (Cols s a)` instance might then
> depend on what `s` is.
>
> On the other hand, I do not yet understand why you cannot provide an
> explicit signature for `list`.  I suspect this is some hairy compiler bug. 
> Either it should be possible to give `list` its inferred type or it should
> be forbidden.  It's probably worth filing an issue about this on GHC Trac.
> I would be interested to hear Li-yao's thoughts on the matter.
>
> Incidentally, this is why I try to avoid type families as much as possible. 
> When they go wrong it's very hard to understand why, and indeed when they go
> right it's also very hard to understand why.
>
> Tom
> _______________________________________________
> 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 tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk  Mon Apr 23 18:16:49 2018
From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis)
Date: Mon, 23 Apr 2018 19:16:49 +0100
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: 
References: 
 
 
 <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber>
 
 <20180423164840.GF12914@weber>
 
Message-ID: <20180423181649.GH12914@weber>

Marc, you're doing very impressively if this is the beginning of your
Haskell career!  Do feel free to keep asking here if you have more
questions.

On Mon, Apr 23, 2018 at 08:08:18PM +0200, Marc Busqué wrote:
> Tom, thank you very much for your deep inspection. Your gist can be
> really helpful in trying to understand the problem. I will study it
> carefully. I have been reading books about Haskell and also Category
> Theory for some months, but I have just started coding few weeks ago, so
> I'm bit overwhelmed about having found a compiler bug so soon :D I'll
> look into all of this and also about Li-yao recommendations and if it is
> suitable I'll fill the issue and also report here.

From marc at lamarciana.com  Mon Apr 23 18:49:21 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Mon, 23 Apr 2018 20:49:21 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <20180423181649.GH12914@weber>
References: 
 
  <20180422191833.GB12914@weber>
 
 <20180423121650.GD12914@weber> 
 <20180423164840.GF12914@weber> 
 <20180423181649.GH12914@weber>
Message-ID: 

On Mon, 23 Apr 2018, Tom Ellis wrote:

> Marc, you're doing very impressively if this is the beginning of your
> Haskell career!  Do feel free to keep asking here if you have more
> questions.

Thanks for your encouragement :)

Marc Busqué
http://waiting-for-dev.github.io/about/

From marc at lamarciana.com  Tue Apr 24 06:00:32 2018
From: marc at lamarciana.com (=?ISO-8859-15?Q?Marc_Busqu=E9?=)
Date: Tue, 24 Apr 2018 08:00:32 +0200 (CEST)
Subject: [Haskell-cafe] Selda: confused about type signtures
In-Reply-To: <77ffa81d-8c37-3b4e-7f67-0ce376752b63@gmail.com>
References: 
 
 
 <77ffa81d-8c37-3b4e-7f67-0ce376752b63@gmail.com>
Message-ID: 

Just for completeness about this solution:

On Mon, 23 Apr 2018, Li-yao Xia wrote:

> ```
> {-# LANGUAGE AllowAmbiguousTypes #-}
> {-# LANGUAGE ScopedTypeVariables #-}
>
> list :: forall s a. (Result (Cols s a), Columns (Cols s a))
>     => Table a -> IO [Res (Cols s a)]
> list table = withDB $ query (select table :: Query s _)

This gives error:

```
     • Couldn't match type ‘Res a’ with ‘Res (Cols s a)’
       Expected type: IO [Res (Cols s a)]
         Actual type: IO [Res a]
       NB: ‘Res’ is a type function, and may not be injective
     • In the expression: withDB $ query (select table :: Query s a)
       In an equation for ‘list’:
           list table = withDB $ query (select table :: Query s a)
     • Relevant bindings include
         table :: Table a (bound at src/Hedger/Backend.hs:30:6)
         list :: Table a -> IO [Res (Cols s a)]
           (bound at src/Hedger/Backend.hs:30:1)
    |
30 | list table = withDB $ query (select table :: Query s a)

  Couldn't match type ‘a’ with ‘Cols s a’
       ‘a’ is a rigid type variable bound by
         the type signature for:
           list :: forall s a.
                   (Result (Cols s a), Columns (Cols s a)) =>
                   Table a -> IO [Res (Cols s a)]
         at src/Hedger/Backend.hs:29:1-93
       Expected type: Query s a
         Actual type: Query s (Cols s a)
     • In the first argument of ‘query’, namely
         ‘(select table :: Query s a)’
       In the second argument of ‘($)’, namely
         ‘query (select table :: Query s a)’
       In the expression: withDB $ query (select table :: Query s a)
     • Relevant bindings include
         table :: Table a (bound at src/Hedger/Backend.hs:30:6)
         list :: Table a -> IO [Res (Cols s a)]
           (bound at src/Hedger/Backend.hs:30:1)
    |
30 | list table = withDB $ query (select table :: Query s a)
```

> -- or,                  ... (select @s table)
> -- with {-# LANGUAGE TypeApplications #-}
> ```

This indeed works!!

In either case, however, I need to add `{-# LANGUAGE FlexibleContexts #-}`

Now I have an interesting road in front of me in order to try to
understand it, along with Tom Ellis' isolated reproducing environment :)

Marc Busqué
http://waiting-for-dev.github.io/about/

From simon.jakobi at googlemail.com  Tue Apr 24 08:28:30 2018
From: simon.jakobi at googlemail.com (Simon Jakobi)
Date: Tue, 24 Apr 2018 10:28:30 +0200
Subject: [Haskell-cafe] In which format should GHC expose documentation via
	its .hi-files?
Message-ID: 

Hi!

In preparation for the coding phase of the Hi Haddock proposal that I
want to implement, I need a decision on the format in which we should
expose haddocks in GHC's .hi interface files.

Please visit https://github.com/haskell/haddock/issues/805, ask
questions, make suggestions and help me find a timely decision! :)

Cheers,
Simon

From slucas at dsic.upv.es  Wed Apr 25 08:15:29 2018
From: slucas at dsic.upv.es (Salvador Lucas)
Date: Wed, 25 Apr 2018 10:15:29 +0200
Subject: [Haskell-cafe] WST 2018 - Last Call for Papers (deadline: April 30,
	2018)
Message-ID: <4a0927e5-2ca8-3d44-7436-b2a9c4adc71e@dsic.upv.es>

==========================================================================
                           WST 2018 - Call for Papers
                    16th International Workshop on Termination

                     July 18-19, 2018, Oxford, United Kingdom
                           http://wst2018.webs.upv.es/

==========================================================================

NEW: James Worrell and Akihisa Yamada, WST 2018 invited speakers

The Workshop on Termination (WST) traditionally brings together, in an
informal setting, researchers interested in all aspects of termination,
whether this interest be practical or theoretical, primary or derived.
The workshop also provides a ground for cross-fertilization of ideas from
the different communities interested in termination (e.g., working on
computational mechanisms, programming languages, software engineering,
constraint solving, etc.). The friendly atmosphere enables fruitful
exchanges leading to joint research and subsequent publications.

The workshop is held as part of the 2018 Federated Logic Conference
(FLoC 2018)

           http://www.floc2018.org/

IMPORTANT DATES:
  * submission deadline:  April 30, 2018
  * notification:         May 28, 2018
  * final version due:    June 11, 2018
  * workshop:             July 18-19, 2018

TOPICS: The 16th International Workshop on Termination welcomes
contributions on all aspects of termination. In particular, papers
investigating applications of termination (for example in complexity
analysis, program analysis and transformation, theorem proving, program
correctness, modeling computational systems, etc.) are very welcome.

Topics of interest include (but are not limited to):
  * abstraction methods in termination analysis
  * certification of termination and complexity proofs
  * challenging termination problems
  * comparison and classification of termination methods
  * complexity analysis in any domain
  * implementation of termination methods
  * non-termination analysis and loop detection
  * normalization and infinitary normalization
  * operational termination of logic-based systems
  * ordinal notation and subrecursive hierarchies
  * SAT, SMT, and constraint solving for (non-)termination analysis
  * scalability and modularity of termination methods
  * termination analysis in any domain (lambda calculus, declarative
    programming, rewriting, transition systems, etc.)
  * well-founded relations and well-quasi-orders

INVITED SPEAKERS:

     James Worrell - University of Oxford
        "Termination Checking and Invariant Synthesis for Affine Programs"

     Akihisa Yamada - NII Japan
        "Towards a Unified Method for Termination"


COMPETITION: Since 2003, the catalytic effect of WST to stimulate
new research on termination has been enhanced by the celebration
of the Termination Competition and its continuously developing
problem databases containing thousands of programs as challenges
for termination analysis in different categories, see

    http://termination-portal.org/wiki/Termination_Competition

In 2018, the Termination Competition will run in parallel with FLoC 2018.
More details will be provided in a dedicated announcement on the
competition.

PROGRAM COMMITTEE:
     Cristina Borralleras - U. de Vic
     Ugo Dal Lago - U. degli Studi di Bologna
     Carsten Fuhs - Birkbeck, U. of London
     Samir Genaim - U. Complutense de Madrid
     Juergen Giesl - RWTH Aachen
     Raul Gutiérrez - U. Politecnica de València
     Keiichirou Kusakari - Gifu University
     Salvador Lucas (chair) - U. Politecnica de Valencia
     Fred Mesnard - U. de La Reunion
     Aart Middeldorp - U. of Innsbruck
     Albert Rubio - U. Politecnica de Catalunya
     Rene Thiemann - U. of Innsbruck
     Caterina Urban - ETH Zürich

SUBMISSION: Submissions are short papers/extended abstracts which
should not exceed 5 pages. There will be no formal reviewing. In
particular, we welcome short versions of recently published articles
and papers submitted elsewhere. The program committee checks relevance
and provides additional feedback for each submission. The accepted
papers will be made available electronically before the workshop.

Papers should be submitted electronically via the submission page:

     https://easychair.org/conferences/?conf=wst2018

Please, use LaTeX and the LIPIcs style file

     http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz

to prepare your submission.

From a.pelenitsyn at gmail.com  Wed Apr 25 09:03:47 2018
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Wed, 25 Apr 2018 09:03:47 +0000
Subject: [Haskell-cafe] ML4PL '18, 1st Call for Submissions
In-Reply-To: 
References: 
Message-ID: 

********************************************************************************
|
|
|         The 2nd International Workshop on Machine Learning
Techniques        |
|                    for Programming Languages (ML4PL
'18)                     |
|
|
|                    July 18th 2018, Amsterdam,
Netherlands                    |
|                        Collocated with ECOOP &
ISSTA                         |
|
|
********************************************************************************

A workshop on machine learning techniques applied to programming
language-related
research and development. This workshop puts an emphasis on identifying
open problem
rather than presenting solution, and encourages discussion amongst the
participants.
Attendance will be limited to ensure that meeting retains an interactive
character.

Workshop web-site:
https://conf.researchr.org/track/ecoop-issta-2018/ML4PL-2018-papers
Submission web-site: https://ml4pl18.hotcrp.com/

********************************** SCOPE ***********************************

Over the last years, we have seen a rapid growth in the use of
machine-learning
technologies in programming languages and systems. This growth is driven by
the
need to design programming languages to analyze, detect patterns, and make
sense
of Big Data, along with the increasing complexity of programming language
tools,
including analyzers and compilers, and computer architectures. The scale of
complexity in available unstructured data and system tools has reached a
stage
where simple heuristics and solutions are no longer feasible or do not
deliver
adequate performance. At the same time, statistical and machine learning
techniques
have become mainstream.

This workshop is a broad forum to bring together researchers with interests
in the
intersection of programming languages and system tools with machine
learning.

Topics of interest include (but are not limited to):

* Program analysis + machine learning
* Programming languages + machine learning
* Compiler optimizations + machine learning
* Computer architecture + machine learning
* Probabilistic programming languages
* Design space exploration

Submissions should take the form of talk abstract or 2-page problem
statements.
Materials of accepted talks will be published in ACM DL.

---------------
IMPORTANT DATES
---------------

Submission deadline: Wednesday, May 18th, 2018, AOE
Notification (tentative): Monday, June 1st, 2018
ML4PL Workshop: Wednesday, July 18th, 2018

-----------------
PROGRAM COMMITTEE
-----------------

* Miltiadis Allamanis (Microsoft Research, Cambridge, United Kingdom)
* Lasse Blaauwbroek (Czech Institute for Informatics Robotics and
Cybernetics,
                     Czech Republic)
* Yoav Goldberg (Bar Ilan University, Israel)
* Georgy Lukyanov (Newcastle University, United Kingdom)
* Alex Polozov (Microsoft Research, United States)
* Mark Santolucito (Yale University, United States)
* Meital Zilberstein (Technion, Israel)

------------------------------
ORGANIZING COMMITTEE & CONTACT
------------------------------

* Hila Peleg (Technion, Israel)
* Artem Pelenitsyn (Czech Technical University in Prague, Czech Republic)

Please, address any questions to Artem (a.pelenitsyn at gmail.com)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From johannes.waldmann at htwk-leipzig.de  Wed Apr 25 11:26:55 2018
From: johannes.waldmann at htwk-leipzig.de (waldmann)
Date: Wed, 25 Apr 2018 13:26:55 +0200
Subject: [Haskell-cafe] how to catch/bracket in yesod-1.6?
Message-ID: 

Dear Cafe,

I wonder what's the recommended way to catch an exception,
clean up resources, etc., in a yesod Handler.
I was using Control.Monad.Catch.bracket_ in legacy code but now I get
"No instance for (Control.Monad.Catch.MonadMask (HandlerFor App))"

- J

From michael at snoyman.com  Wed Apr 25 12:19:07 2018
From: michael at snoyman.com (Michael Snoyman)
Date: Wed, 25 Apr 2018 15:19:07 +0300
Subject: [Haskell-cafe] how to catch/bracket in yesod-1.6?
In-Reply-To: 
References: 
Message-ID: 

You can use the functions in UnliftIO.Exception, in the unliftio package

https://www.stackage.org/package/unliftio

On Wed, Apr 25, 2018 at 2:26 PM, waldmann  wrote:

> Dear Cafe,
>
> I wonder what's the recommended way to catch an exception,
> clean up resources, etc., in a yesod Handler.
> I was using Control.Monad.Catch.bracket_ in legacy code but now I get
> "No instance for (Control.Monad.Catch.MonadMask (HandlerFor App))"
>
> - J
> _______________________________________________
> 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 hafnersimon at gmail.com  Wed Apr 25 12:21:33 2018
From: hafnersimon at gmail.com (Simon Hafner)
Date: Wed, 25 Apr 2018 14:21:33 +0200
Subject: [Haskell-cafe] how to catch/bracket in yesod-1.6?
In-Reply-To: 
References: 
Message-ID: 

>From the doc [1] there's a few instances you can use. `MonadResource`
sounds like the most obvious choice, with its `allocate` [2], but
that'll require you to refactor your application a bit. It's what I'd
recommend though. If that's unfeasable, there's always the new
`bracket_` on `MonadUnliftIO` [3]

[1] https://www.stackage.org/haddock/lts-11.6/yesod-core-1.6.3/Yesod-Core-Handler.html#t:HandlerFor
[2] https://www.stackage.org/haddock/lts-11.6/resourcet-1.2.1/Control-Monad-Trans-Resource.html#v:allocate
[3] https://www.stackage.org/haddock/lts-11.6/unliftio-0.2.6.0/UnliftIO-Exception.html#v:bracket_

2018-04-25 13:26 GMT+02:00 waldmann :
> Dear Cafe,
>
> I wonder what's the recommended way to catch an exception,
> clean up resources, etc., in a yesod Handler.
> I was using Control.Monad.Catch.bracket_ in legacy code but now I get
> "No instance for (Control.Monad.Catch.MonadMask (HandlerFor App))"
>
> - J
> _______________________________________________
> 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 srid at srid.ca  Thu Apr 26 01:52:39 2018
From: srid at srid.ca (Sridhar Ratnakumar)
Date: Wed, 25 Apr 2018 21:52:39 -0400
Subject: [Haskell-cafe] need to find generated reflex/reflex-dom docs
In-Reply-To: 
References: 
Message-ID: <1524707559.1450060.1351069256.17731556@webmail.messagingengine.com>

This doesn't directly answer your question but another way to get docs for reflex, including the other packages, is to use hoogle. 

Assuming your reflex project is based on reflex-project-skeleton[1], the following command will start a local hoogle server for all packages in your project (this includes reflex, reflex-dom, jsaddle, etc.):

nix-shell -A shells.ghc --run "hoogle serve --local -p 8080"

cheers,
-srid

[1] https://github.com/ElvishJerricco/reflex-project-skeleton


On Fri, Apr 13, 2018, at 11:26 AM, Michael Litchard wrote:
> I've installed reflex-platform on ubuntu via nix, and am pretty sure I have local docs installed.
> I located this file
> 
> /nix/store/hv5zkh1gmhklk4sgwhd8gy1q79l37zpc-reflex-dom-0.4-doc/share/doc/html/index.html

> But it doesn't lead to very much. I'm thinking I didn't do a full doc install. I'd like some advice on how to make sure I've got a complete local install of reflex docs.

From lemming at henning-thielemann.de  Thu Apr 26 06:50:33 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 26 Apr 2018 08:50:33 +0200 (CEST)
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
	overflows
Message-ID: 


I like to test whether some low-level routines overwrite non-allocated 
memory area. On the Amiga there was the program Mungwall that surrounded 
memory blocks with some byte patterns at allocation and checked the 
integrity of those patterns at deallocation. This would also be possible 
in Haskell with a modified mallocForeignPtrArray. Has someone already 
implemented this idea? If yes, how could I easily switch between the 
mallocForeignPtrArray version with such debugging support and the plain 
function? It would be unfeasible to re-compile a lot of packages only for 
debugging. Ideally the test-suite of a package would use the debugging 
version of mallocForeignPtrArray and the library part would use plain 
allocation.

I thought about using valgrind but I remember this often gave many false 
positive bug reports for Haskell programs.

From alex at slab.org  Thu Apr 26 08:47:43 2018
From: alex at slab.org (Alex McLean)
Date: Thu, 26 Apr 2018 09:47:43 +0100
Subject: [Haskell-cafe] Block editor for Haskell
Message-ID: 

Hi all,

I'm wondering if anyone has made a 'block editor' for Haskell, i.e. a
syntax-aware text editor where you make a program by snapping together
type-compatible words, usually with a mouse. Something similar to
Scratch for example: https://scratch.mit.edu/

Any leads appreciated!

Best wishes

alex

From alan.zimm at gmail.com  Thu Apr 26 09:15:49 2018
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 26 Apr 2018 11:15:49 +0200
Subject: [Haskell-cafe] Block editor for Haskell
In-Reply-To: 
References: 
Message-ID: 

See lambdu.org

On 26 April 2018 at 10:47, Alex McLean  wrote:

> Hi all,
>
> I'm wondering if anyone has made a 'block editor' for Haskell, i.e. a
> syntax-aware text editor where you make a program by snapping together
> type-compatible words, usually with a mouse. Something similar to
> Scratch for example: https://scratch.mit.edu/
>
> Any leads appreciated!
>
> Best wishes
>
> alex
> _______________________________________________
> 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  Thu Apr 26 13:17:27 2018
From: dominic at steinitz.org (dominic at steinitz.org)
Date: Thu, 26 Apr 2018 14:17:27 +0100
Subject: [Haskell-cafe] Numerical Programming in Functional Languages (CfP)
Message-ID: <15EE7F69-9C15-4777-A75D-472D012262B3@steinitz.org>

I’m the chair this year for the first(!) ACM SIGPLAN International Workshop on Numerical Programming in Functional Languages (NPFL), which will be co-located with ICFP this September in St. Louis, Missouri, USA.

Please consider submitting something! All you have to do is submit between half a page and a page describing your talk. There will be no proceedings so all you need do is prepare your slides or demo. We do plan to video the talks for the benefit of the wider world.

We have Eva Darulova  giving the keynote.

The submission deadline is Friday 13th July but I and the Committee would love to see your proposals earlier.

See here  for more information. Please contact me if you have any questions!

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com
Twitter: @idontgetoutmuch



-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alan.zimm at gmail.com  Thu Apr 26 14:02:34 2018
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Thu, 26 Apr 2018 16:02:34 +0200
Subject: [Haskell-cafe] HaRe : informal poll
Message-ID: 

Currently HaRe (on hackage) supports GHC 7.10 and 8.0

There is a new version ready to roll, with GHC 8.2 and 8.4 support.

But due to the complexities of the build environment (details here[1] for
anyone who cares) it will not be able to support earlier GHC versions.

Will this be a problem for anyone?

Alan

[1] https://github.com/haskell/cabal/pull/5275
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From cdsmith at gmail.com  Thu Apr 26 17:25:23 2018
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 26 Apr 2018 17:25:23 +0000
Subject: [Haskell-cafe] Block editor for Haskell
In-Reply-To: 
References: 
Message-ID: 

Alex, a couple years ago, Stefan Jacholke built something like this for
CodeWorld, which is a variant of Haskell.  It's not general-purpose and
builds for a custom prelude, but it might be worth looking at.  You should
be aware that while I've kept it basically working, there are plenty of
known bugs.

Available at https://code.world/blocks

On Thu, Apr 26, 2018, 1:48 AM Alex McLean  wrote:

> Hi all,
>
> I'm wondering if anyone has made a 'block editor' for Haskell, i.e. a
> syntax-aware text editor where you make a program by snapping together
> type-compatible words, usually with a mouse. Something similar to
> Scratch for example: https://scratch.mit.edu/
>
> Any leads appreciated!
>
> Best wishes
>
> alex
> _______________________________________________
> 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 asm13243546 at gmail.com  Thu Apr 26 18:26:47 2018
From: asm13243546 at gmail.com (Alfred Matthews)
Date: Thu, 26 Apr 2018 18:26:47 +0000
Subject: [Haskell-cafe] Block editor for Haskell
In-Reply-To: 
References: 
 
Message-ID: 

This is substantially interesting to me personally, persuant a paste below,
as a spectator of PLD.

Pretty keen to read the, Hey, but, wait,

Alfred Matthews.


Better Collaboration
One of the most difficult things about collaborative development is
handling merge conflicts.

The vast majority of merge conflicts are results of non-functional changes:
Renames, reformatting, textual movement of code lines between files, etc.

In Lamdu, "names", the "position" of the code and other non-functional
aspects of code are separate from the code itself, and avoid conflicts.

Rename conflicts
To get a conflict due to "rename" operations, two developers must rename
the same variable to two different names. Even then, the code is still
executable, but its on-screen rendering will display a localized conflict.

Formatting conflicts
Formatting is automatic, so there is no way to generate a conflict.

Code movement conflicts
The "position" of code is meta-data attached to the code, helping to find
that code and position its rendering.

Since code is not structured into text files, code "position" conflicts are
similarly less harmful, less likely and localized.

Change tracking
Instead of heuristically guessing what changed in the code, as traditional
version control systems do, Lamdu uses an integrated revision control
system and records the changes by the programmer as revisions.

This acts as a record of the developer's intent, allowing the RCS to
distinguish, for example, between function deletion and writing of a
similar function, and the modification of that same function. The recording
of intent helps prevent and resolve conflicts.

Regression Debugging
Integrated revision control and live test cases will allow "Regression
Debugging".

When a change causes a regression, the root of the problem can be found
quickly, by finding the deepest function application whose result value
diverged from the correct version of the code.

Automatic Formatting and Sugaring
Lamdu attempts to take away as much inconsequential freedom from the
developer, to free his mind and his key strokes to deal with the parts that
matter in the code. Thus, Lamdu does not provide means to edit formatting
on a case-by-case basis. Generalized changes to layout rules can be
provided, instead.

Additionally, to avoid further stylistic dilemmas, Lamdu uses automatic
sugaring of code, as the dual of typical "de-sugaring" done by textual
languages.

The code is edited and displayed in its sugared form. The edits to this
form are translated to lower-level, simpler edits of the stored language,
which is de-sugared. Lamdu uses "co-macros" that capture patterns in the
lower-level code and automatically sugar it to canonical form. This frees
the programmer from worrying about whether to use sugar for each particular
case.
On Thu, Apr 26, 2018, 5:16 AM Alan & Kim Zimmerman 
wrote:

> See lambdu.org
>
> On 26 April 2018 at 10:47, Alex McLean  wrote:
>
>> Hi all,
>>
>> I'm wondering if anyone has made a 'block editor' for Haskell, i.e. a
>> syntax-aware text editor where you make a program by snapping together
>> type-compatible words, usually with a mouse. Something similar to
>> Scratch for example: https://scratch.mit.edu/
>>
>> Any leads appreciated!
>>
>> Best wishes
>>
>> alex
>>
> _______________________________________________
>> 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 asm13243546 at gmail.com  Thu Apr 26 18:52:30 2018
From: asm13243546 at gmail.com (Alfred Matthews)
Date: Thu, 26 Apr 2018 18:52:30 +0000
Subject: [Haskell-cafe] Object assignment and equivalence
Message-ID: 

Numerically,

wondering if there are design implications to or via defining integers
(1,12) as

let mod(1)=0, 0

From lemming at henning-thielemann.de  Thu Apr 26 21:50:00 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Thu, 26 Apr 2018 23:50:00 +0200 (CEST)
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
	overflows
In-Reply-To: 
References: 
Message-ID: 


On Thu, 26 Apr 2018, Henning Thielemann wrote:

> I like to test whether some low-level routines overwrite non-allocated 
> memory area. On the Amiga there was the program Mungwall that surrounded 
> memory blocks with some byte patterns at allocation and checked the 
> integrity of those patterns at deallocation.

It seems that electric-fence is the counterpart to Mungwall on Linux. Any 
experiences how to use that in Haskell?

From david.feuer at gmail.com  Thu Apr 26 22:30:03 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 26 Apr 2018 18:30:03 -0400
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
	overflows
In-Reply-To: 
References: 
Message-ID: 

For debugging, this sounds like overkill to me. Can't you write
bounds-checking versions of your primitives that are turned on with
some CPP? Data.HashMap.Array does this sort of thing, although I don't
think it checks everything it really should. In the back of my mind,
I've been thinking it would be really nice to be able to tell GHC to
use checked versions of its primops. That's seems a bit tricky, since
the SomeException type is at a much higher level, but maybe there's
some way to make it work.

On Thu, Apr 26, 2018 at 2:50 AM, Henning Thielemann
 wrote:
>
> I like to test whether some low-level routines overwrite non-allocated
> memory area. On the Amiga there was the program Mungwall that surrounded
> memory blocks with some byte patterns at allocation and checked the
> integrity of those patterns at deallocation. This would also be possible in
> Haskell with a modified mallocForeignPtrArray. Has someone already
> implemented this idea? If yes, how could I easily switch between the
> mallocForeignPtrArray version with such debugging support and the plain
> function? It would be unfeasible to re-compile a lot of packages only for
> debugging. Ideally the test-suite of a package would use the debugging
> version of mallocForeignPtrArray and the library part would use plain
> allocation.
>
> I thought about using valgrind but I remember this often gave many false
> positive bug reports for Haskell programs.
> _______________________________________________
> 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 david.feuer at gmail.com  Thu Apr 26 22:46:29 2018
From: david.feuer at gmail.com (David Feuer)
Date: Thu, 26 Apr 2018 18:46:29 -0400
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
	overflows
In-Reply-To: 
References: 
 
Message-ID: 

I just opened https://ghc.haskell.org/trac/ghc/ticket/15092 to
consider such options.

On Thu, Apr 26, 2018 at 6:30 PM, David Feuer  wrote:
> For debugging, this sounds like overkill to me. Can't you write
> bounds-checking versions of your primitives that are turned on with
> some CPP? Data.HashMap.Array does this sort of thing, although I don't
> think it checks everything it really should. In the back of my mind,
> I've been thinking it would be really nice to be able to tell GHC to
> use checked versions of its primops. That's seems a bit tricky, since
> the SomeException type is at a much higher level, but maybe there's
> some way to make it work.
>
> On Thu, Apr 26, 2018 at 2:50 AM, Henning Thielemann
>  wrote:
>>
>> I like to test whether some low-level routines overwrite non-allocated
>> memory area. On the Amiga there was the program Mungwall that surrounded
>> memory blocks with some byte patterns at allocation and checked the
>> integrity of those patterns at deallocation. This would also be possible in
>> Haskell with a modified mallocForeignPtrArray. Has someone already
>> implemented this idea? If yes, how could I easily switch between the
>> mallocForeignPtrArray version with such debugging support and the plain
>> function? It would be unfeasible to re-compile a lot of packages only for
>> debugging. Ideally the test-suite of a package would use the debugging
>> version of mallocForeignPtrArray and the library part would use plain
>> allocation.
>>
>> I thought about using valgrind but I remember this often gave many false
>> positive bug reports for Haskell programs.
>> _______________________________________________
>> 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 jo at durchholz.org  Fri Apr 27 04:42:41 2018
From: jo at durchholz.org (Joachim Durchholz)
Date: Fri, 27 Apr 2018 06:42:41 +0200
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
 overflows
In-Reply-To: 
References: 
Message-ID: 

Am 26.04.2018 um 08:50 schrieb Henning Thielemann:
> 
> I like to test whether some low-level routines overwrite non-allocated 
> memory area. On the Amiga there was the program Mungwall that surrounded 
> memory blocks with some byte patterns at allocation and checked the 
> integrity of those patterns at deallocation.
Today, it's called a "canary value". Most C compilers have an option to 
activate this mode for all allocations.
I don't know whether GHC's native backend has such an option, but the 
LLVM backend should.

Regards,
Jo

From lemming at henning-thielemann.de  Fri Apr 27 06:27:15 2018
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Fri, 27 Apr 2018 08:27:15 +0200 (CEST)
Subject: [Haskell-cafe] mallocForeignPtrArray with check against buffer
 overflows
In-Reply-To: 
References: 
 
Message-ID: 


On Thu, 26 Apr 2018, David Feuer wrote:

> For debugging, this sounds like overkill to me. Can't you write 
> bounds-checking versions of your primitives that are turned on with some 
> CPP?

I call foreign functions from LAPACK that fill the arrays and I have not 
control over its primitives.

From manny at fpcomplete.com  Sat Apr 28 13:31:45 2018
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Sat, 28 Apr 2018 06:31:45 -0700
Subject: [Haskell-cafe] ANN: stack-1.7.1
Message-ID: 

See https://haskellstack.org for installation and upgrade instructions.

### Changes since v1.6.5:

Release notes:

* aarch64 (64-bit ARM) bindists are now available for the first time.
* Statically linked Linux bindists are no longer available, due to difficulty with GHC 8.2.2 on Alpine Linux.
* 32-bit Linux GMP4 bindists for CentOS 6 are no longer available, since GHC 8.2.2 is no longer being built for that platform.

Major changes:

* Upgrade from Cabal 2.0 to Cabal 2.2

Behavior changes:

* `stack setup` no longer uses different GHC configure options on Linux
  distributions that use GCC with PIE enabled by default.  GHC detects
  this itself since ghc-8.0.2, and Stack's attempted workaround for older
  versions caused more problems than it solved.
* `stack new` no longer initializes a project if the project template contains
   a stack.yaml file.

Other enhancements:

* A new sub command `ls` has been introduced to stack to view
  local and remote snapshots present in the system. Use `stack ls
  snapshots --help` to get more details about it.
* `list-dependencies` has been deprecated. The functionality has
  to accessed through the new `ls dependencies` interface. See
  [#3669](https://github.com/commercialhaskell/stack/issues/3669)
  for details.
* Specify User-Agent HTTP request header on every HTTP request.
  See [#3628](https://github.com/commercialhaskell/stack/issues/3628) for details.
* `stack setup` looks for GHC bindists and installations by any OS key
  that is compatible (rather than only checking a single one).   This is
  relevant on Linux where different distributions may have different
  combinations of libtinfo 5/6, ncurses 5/6, and gmp 4/5, and will allow
  simpifying the setup-info metadata YAML for future GHC releases.
* The build progress bar reports names of packages currently building.
* `stack setup --verbose` causes verbose output of GHC configure process.
  See [#3716](https://github.com/commercialhaskell/stack/issues/3716)
* Improve the error message when an `extra-dep` from a path or git reference can't be found
  See [#3808](https://github.com/commercialhaskell/stack/pull/3808)
* Nix integration is now disabled on windows even if explicitly enabled,
  since it isn't supported. See
  [#3600](https://github.com/commercialhaskell/stack/issues/3600)
* `stack build` now supports a new flag `--keep-tmp-files` to retain intermediate
  files and directories for the purpose of debugging.
  It is best used with ghc's equivalent flag,
  i.e. `stack build --keep-tmp-files --ghc-options=-keep-tmp-files`.
  See [#3857](https://github.com/commercialhaskell/stack/issues/3857)
* Improved error messages for snapshot parse exceptions
* `stack unpack` now supports a `--to /target/directory` option to
  specify where to unpack the package into
* `stack hoogle` now supports a new flag `--server` that launches local
  Hoogle server on port 8080. See
  [#2310](https://github.com/commercialhaskell/stack/issues/2310)

Bug fixes:

* The script interpreter's implicit file arguments are now passed before other
  arguments. See [#3658](https://github.com/commercialhaskell/stack/issues/3658).
  In particular, this makes it possible to pass `-- +RTS ... -RTS` to specify
  RTS arguments used when running the script.
* Don't ignore the template `year` parameter in config files, and clarify the
  surrounding documentation. See
  [#2275](https://github.com/commercialhaskell/stack/issues/2275).
* Benchmarks used to be run concurrently with other benchmarks
  and build steps. This is non-ideal because CPU usage of other processes
  may interfere with benchmarks. It also prevented benchmark output from
  being displayed by default. This is now fixed. See
  [#3663](https://github.com/commercialhaskell/stack/issues/3663).
* `stack ghci` now allows loading multiple packages with the same
  module name, as long as they have the same filepath. See
  [#3776](https://github.com/commercialhaskell/stack/pull/3776).
* `stack ghci` no longer always adds a dependency on `base`. It is
  now only added when there are no local targets. This allows it to
  be to load code that uses replacements for `base`. See
  [#3589](https://github.com/commercialhaskell/stack/issues/3589#issuecomment)
* `stack ghci` now uses correct paths for autogen files with
  [#3791](https://github.com/commercialhaskell/stack/issues/3791)
* When a package contained sublibraries, stack was always recompiling the
  package. This has been fixed now, no recompilation is being done because of
  sublibraries. See [#3899](https://github.com/commercialhaskell/stack/issues/3899).
* The `get-stack.sh` install script now matches manual instructions
  when it comes to Debian/Fedora/CentOS install dependencies.
* Compile Cabal-simple with gmp when using Nix.
  See [#2944](https://github.com/commercialhaskell/stack/issues/2944)
* `stack ghci` now replaces the stack process with ghci. This improves
  signal handling behavior. In particular, handling of Ctrl-C.  To make
  this possible, the generated files are now left behind after exit.
  The paths are based on hashing file contents, and it's stored in the
  system temporary directory, so this shouldn't result in too much
  garbage. See
  [#3821](https://github.com/commercialhaskell/stack/issues/3821).

### Thanks to all our contributors for this release:

* Alexey Kuleshevich
* Andrei Dziahel
* Andrew Cowie
* Daniel Bergey
* David Baynard
* Domen Kožar
* Don Waldhalm
* Emanuel Borsboom
* Geoffrey Noel
* Ivan Kasatenko
* Jan von Loewenstein
* Joshua Simmons
* Kirill Elagin
* Krishnan Parthasarathi
* Luke Murphy
* Matt Spaulding
* Matthias Braun
* Maximilian Tagher
* Michael Sloan
* Michael Snoyman
* Mihai Maruseac
* Mike Pilgrem
* Mitchell Rosen
* Nicolas Mattia
* Niklas Hambüchen
* Oleg Grenrus
* Reuben D'Netto
* Robert J. Macomber
* Sibi Prabakaran
* silky
* Simon Hengel
* Tero Laxström
* tswelsh
* Yuji Yamamoto

From svenpanne at gmail.com  Sat Apr 28 17:55:28 2018
From: svenpanne at gmail.com (Sven Panne)
Date: Sat, 28 Apr 2018 19:55:28 +0200
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: 
References: 
Message-ID: 

2018-04-28 15:31 GMT+02:00 Emanuel Borsboom :

> See https://haskellstack.org for installation and upgrade instructions.
> [...]
>

The download links for the Windows installers on
https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows are
broken. The GitHub release pages only mention ZIP files. Is this
intentional?

Cheers,
   S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ietf-dane at dukhovni.org  Sat Apr 28 18:12:57 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 28 Apr 2018 14:12:57 -0400
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: 
References: 
Message-ID: 



> On Apr 28, 2018, at 9:31 AM, Emanuel Borsboom  wrote:
> 
> See https://haskellstack.org for installation and upgrade instructions.

When I try to use the nightly-2018-04-28 snapshot on a FreeBSD11 system,
I get:

  $ stack build
  No setup information found for ghc-8.4.2 on your platform.
  This probably means a GHC bindist has not yet been added for OS key 'freebsd64'.
  Supported versions: ghc-7.8.4, ghc-7.10.1, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1,
  ghc-8.0.2, ghc-8.2.1, ghc-8.2.2

Is that expected?  FWIW, at:

  https://github.com/commercialhaskell/ghc/releases/

there's a link:

  * ghc-8.4.2-x86_64-portbld-freebsd.tar.xz

to:

   https://github.com/commercialhaskell/ghc/releases/download/ghc-8.4.2-release/ghc-8.4.2-x86_64-portbld-freebsd.tar.xz

-- 
	Viktor.


From manny at fpcomplete.com  Sat Apr 28 21:45:23 2018
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Sat, 28 Apr 2018 14:45:23 -0700
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: 
References: 
 
Message-ID: 

> The download links for the Windows installers on https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows  are broken. The GitHub release pages only mention ZIP files. Is this intentional?

Sorry about that, should be fixed now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From manny at fpcomplete.com  Sat Apr 28 21:53:51 2018
From: manny at fpcomplete.com (Emanuel Borsboom)
Date: Sat, 28 Apr 2018 14:53:51 -0700
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: 
References: 
 
Message-ID: <07635300-1E63-44A7-9238-68E7E1C00DA9@fpcomplete.com>

This should be fixed now.  The GHC 8.4.x bindists weren't under the right OS key in the GHC setup metadata.  That said, this shouldn't behave any differently on stack-1.7.x than it did with stack-1.6.x.

I'm curious if this will work for you though.  I just tried it on a FreeBSD 11 VM and GHC 8.4.2 failed stack's post-install sanity check with a bunch of errors like this:

/usr/local/bin/ld.gold: error: /home/vagrant/.stack/programs/x86_64-freebsd/ghc-8.4.2/lib/ghc-8.4.2/rts/libHSrts.a(RTS.o): unexpected reloc 8 in object file
/home/vagrant/.stack/programs/x86_64-freebsd/ghc-8.4.2/lib/ghc-8.4.2/rts/libHSrts.a(RTS.o):/usr/src/cddl/lib/drti/../../../cddl/contrib/opensolaris/lib/libdtrace/common/drti.c:__SUNW_dof: error: unexpected reloc 8 in object file
collect2: error: ld returned 1 exit status 

GHC 8.2.2 seems to work alright, so not sure what changed in the bindists.

> On Apr 28, 2018, at 11:12 AM, Viktor Dukhovni  wrote:
> 
> When I try to use the nightly-2018-04-28 snapshot on a FreeBSD11 system,
> I get:
> 
>  $ stack build
>  No setup information found for ghc-8.4.2 on your platform.
>  This probably means a GHC bindist has not yet been added for OS key 'freebsd64'.
>  Supported versions: ghc-7.8.4, ghc-7.10.1, ghc-7.10.2, ghc-7.10.3, ghc-8.0.1,
>  ghc-8.0.2, ghc-8.2.1, ghc-8.2.2
> 
> Is that expected?  FWIW, at:
> 
>  https://github.com/commercialhaskell/ghc/releases/
> 
> there's a link:
> 
>  * ghc-8.4.2-x86_64-portbld-freebsd.tar.xz
> 
> to:
> 
>   https://github.com/commercialhaskell/ghc/releases/download/ghc-8.4.2-release/ghc-8.4.2-x86_64-portbld-freebsd.tar.xz
> 
> -- 
> 	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.


From ietf-dane at dukhovni.org  Sat Apr 28 22:14:03 2018
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Sat, 28 Apr 2018 18:14:03 -0400
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: <07635300-1E63-44A7-9238-68E7E1C00DA9@fpcomplete.com>
References: 
 
 <07635300-1E63-44A7-9238-68E7E1C00DA9@fpcomplete.com>
Message-ID: 



> On Apr 28, 2018, at 5:53 PM, Emanuel Borsboom  wrote:
> 
> This should be fixed now.  The GHC 8.4.x bindists weren't under the right OS key in the GHC setup metadata.  That said, this shouldn't behave any differently on stack-1.7.x than it did with stack-1.6.x.

Yes, the same problem with stack 1.6, I just updated stack and tried the snapshot at the same time.

> I'm curious if this will work for you though.  I just tried it on a FreeBSD 11 VM and GHC 8.4.2 failed stack's post-install sanity check with a bunch of errors

I'll let you know.  For some reason running "strip" on the various ".a" files extracted from the archive is taking a very long time...  For example, still running as I write:

$ ps -wwww -o pid,etime,args -p $(pgrep strip)
  PID ELAPSED COMMAND
72558   05:49 strip --strip-unneeded /usr/home/viktor/.stack/programs/x86_64-freebsd/ghc-8.4.2/lib/ghc-8.4.2/Cabal-2.2.0.1/libHSCabal-2.2.0.1_p.a

-- 
	Viktor.


From evan at evanrutledgeborden.dreamhosters.com  Sat Apr 28 23:19:08 2018
From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com)
Date: Sat, 28 Apr 2018 19:19:08 -0400
Subject: [Haskell-cafe] ANN: network-2.7.0.0
Message-ID: 

Announcing network-2.7.0.0
https://hackage.haskell.org/package/network-2.7.0.0

The 2.7.0.0 release is mostly communicating change. There are a few new
APIs,
but much of this release is dedicated to preperation for 3.0.0.0. Many long
standing functions and modules with tacit deprecation have been officially
marked as such.

Change log:
 * Obsoleting the Network module.
 * Obsoleting the Network.BSD module.
 * Obsoleting APIs: MkSocket, htonl, ntohl,
              getPeerCred, getPeerEid,
              send, sendTo, recv, recvFrom, recvLen,
              inet_addr, inet_ntoa,
              isConnected, isBound, isListening, isReadable, isWritable,
              aNY_PORT, iNADDR_ANY, iN6ADDR_ANY, sOMAXCONN,
          sOL_SOCKET, sCM_RIGHTS,
              packFamily, unpackFamily, packSocketType
 * Do not closeFd within sendFd
   [#271](https://github.com/haskell/network/pull/271)
 * Exporting ifNameToIndex and ifIndexToName from Network.Socket.
 * New APIs: setCloseOnExecIfNeeded, getCloseOnExec and getNonBlock
 * New APIs: isUnixDomainSocketAvailable and getPeerCredential
 * socketPair, sendFd and recvFd are exported even on Windows.

Upcoming changes in 3.0.0.0 will include:
 * Functions and modules marked as deprecated in 2.7.0.0 will be removed.
 * New APIs introduced in 2.7.0.0 will be present in 3.0.0.0.
 * Socket addresses will have an extensible API.
 * Linux, BSD and Windows will all have the same API.

3.0.0.0 has been implemented, but we will wait a sufficient period of time
before releasing it.

As always thanks to network contributors!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From 6yearold at gmail.com  Sun Apr 29 08:27:52 2018
From: 6yearold at gmail.com (Gleb Popov)
Date: Sun, 29 Apr 2018 11:27:52 +0300
Subject: [Haskell-cafe] ANN: stack-1.7.1
In-Reply-To: 
References: 
 
 <07635300-1E63-44A7-9238-68E7E1C00DA9@fpcomplete.com>
 
Message-ID: 

On Sun, Apr 29, 2018 at 1:14 AM, Viktor Dukhovni 
wrote:

>
>
> > On Apr 28, 2018, at 5:53 PM, Emanuel Borsboom 
> wrote:
> >
> > This should be fixed now.  The GHC 8.4.x bindists weren't under the
> right OS key in the GHC setup metadata.  That said, this shouldn't behave
> any differently on stack-1.7.x than it did with stack-1.6.x.
>
> Yes, the same problem with stack 1.6, I just updated stack and tried the
> snapshot at the same time.
>
> > I'm curious if this will work for you though.  I just tried it on a
> FreeBSD 11 VM and GHC 8.4.2 failed stack's post-install sanity check with a
> bunch of errors
>
> I'll let you know.  For some reason running "strip" on the various ".a"
> files extracted from the archive is taking a very long time...  For
> example, still running as I write:
>

Yep, I also have this problem on 12-CURRENT.


>
> $ ps -wwww -o pid,etime,args -p $(pgrep strip)
>   PID ELAPSED COMMAND
> 72558   05:49 strip --strip-unneeded /usr/home/viktor/.stack/
> programs/x86_64-freebsd/ghc-8.4.2/lib/ghc-8.4.2/Cabal-2.2.0.
> 1/libHSCabal-2.2.0.1_p.a
>
> --
>         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 erkokl at gmail.com  Mon Apr 30 02:35:16 2018
From: erkokl at gmail.com (Levent Erkok)
Date: Sun, 29 Apr 2018 19:35:16 -0700
Subject: [Haskell-cafe] [ANNOUNCE] New release of SBV (v7.7),
 now with symbolic characters and strings
Message-ID: 

I'm pleased to announce v7.7 release of SBV, a library integrating modern
SMT solvers into Haskell.

The main feature in this version is support for symbolic characters,
strings, and regular-expressions; initially contributed by Joel Burget. SBV
can now deal with proofs of programs that work on strings, taking advantage
of modern SMT solving techniques. This is the first time SBV is venturing
out of the realm of "number" like types (bit-vectors, reals, integers,
floats etc.), so I am excited about the new problem domains we can now
model symbolically.

A symbolic string is not a mere list of symbolic characters, but rather is
a type on its own. While this departure seems not in the spirit of Haskell,
this change of view brings a lot of expressive/proof power. Joel
contributed two simple examples to illustrate:

   - A regular-expression crossword solver:
   https://hackage.haskell.org/package/sbv-7.7/docs/Documentation-SBV-Examples-Strings-RegexCrossword.html
   - A simple SQL-injection analyzer:
   https://hackage.haskell.org/package/sbv-7.7/docs/Documentation-SBV-Examples-Strings-SQLInjection.html

Support for strings/regular-expressions is rather new in the SMT solving
arena. Furthermore, the logic is not known to be decidable, and thus the
solvers might struggle with difficult queries. Currently, only Z3 and CVC4
support this logic. If you do play with it, you're likely to find issues in
both SBV itself and possibly with the underlying solver as well. Please
report if you run into anything that looks fishy. In any case,
implementations are solid enough that you should be able to model and
reason about non-trivial string-processing programs with relative ease.


   -  Hackage: https://hackage.haskell.org/package/sbv
   -  Homepage: http://leventerkok.github.io/sbv/
   -  Release notes: https://github.com/LeventErkok/sbv/blob/master/
   CHANGES.md
   -  SMTLib initiative: http://smtlib.cs.uiowa.edu/


Thanks to Joel Burget for doing the initial work for adding support for
symbolic strings.

Feedback and bug reports are most welcome!

Happy reasoning!

-Levent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Graham.Hutton at nottingham.ac.uk  Mon Apr 30 08:54:28 2018
From: Graham.Hutton at nottingham.ac.uk (Graham Hutton)
Date: Mon, 30 Apr 2018 08:54:28 +0000
Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD
	Abstracts
Message-ID: 

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 25th May 2018.  Please share!

Best wishes,

Graham Hutton


============================================================

CALL FOR PHD ABSTRACTS

Journal of Functional Programming

Deadline: 25th May 2018

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 25th May 2018.

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 contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.





From P.Achten at cs.ru.nl  Mon Apr 30 09:35:34 2018
From: P.Achten at cs.ru.nl (Peter Achten)
Date: Mon, 30 Apr 2018 11:35:34 +0200
Subject: [Haskell-cafe] final call for papers: Trends in Functional
 Programming, 11-13 june 2018, Chalmers Campus Johanneberg,
 Gothenburg - deadline extended -
Message-ID: <8e0b0d40-0174-003d-1fad-5b1bfbed8404@cs.ru.nl>

                -------------------------------------
              F I N A L   C A L L   F O R   P A P E R S
                -------------------------------------

                     ----- deadline extended -----
                     ======== TFP 2018 ===========

           19th Symposium on Trends in Functional Programming
                            11-13 June, 2018
                      Chalmers Campus Johanneberg, Gothenburg
            http://www.cse.chalmers.se/~myreen/tfp2018/index.html

The symposium on Trends in Functional Programming (TFP) is an
international forum for researchers with interests in all aspects of
functional programming, taking a broad view of current and future
trends in the area. It aspires to be a lively environment for
presenting the latest research results, and other contributions (see
below at scope).

Please be aware that TFP uses two distinct rounds of submissions (see
below at submission details).

TFP 2018 will be the main event of a pair of functional programming
events. TFP 2018 will be accompanied by the International Workshop on
Trends in Functional Programming in Education (TFPIE), which will take
place on June 14.


== SCOPE ==

The symposium recognizes that new trends may arise through various routes.
As part of the Symposium's focus on trends we therefore identify the
following five article categories. High-quality articles are solicited in
any of these categories:

Research Articles:
     Leading-edge, previously unpublished research work
Position Articles:
     On what new trends should or should not be
Project Articles:
     Descriptions of recently started new projects
Evaluation Articles:
     What lessons can be drawn from a finished project
Overview Articles:
     Summarizing work with respect to a trendy subject.

Articles must be original and not simultaneously submitted for 
publication to
any other forum. They may consider any aspect of functional programming:
theoretical, implementation-oriented, or experience-oriented. 
Applications of
functional programming techniques to other languages are also within the 
scope
of the symposium.

Topics suitable for the symposium include, but are not limited to:

     Functional programming and multicore/manycore computing
     Functional programming in the cloud
     High performance functional computing
     Extra-functional (behavioural) properties of functional programs
     Dependently typed functional programming
     Validation and verification of functional programs
     Debugging and profiling for functional languages
     Functional programming in different application areas:
     security, mobility, telecommunications applications, embedded
     systems, global computing, grids, etc.
     Interoperability with imperative programming languages
     Novel memory management techniques
     Program analysis and transformation techniques
     Empirical performance studies
     Abstract/virtual machines and compilers for functional languages
     (Embedded) domain specific languages
     New implementation strategies
     Any new emerging trend in the functional programming area

If you are in doubt on whether your article is within the scope of TFP, 
please
contact the TFP 2018 program chairs, Michał Pałka and Magnus Myreen.


== Best Paper Awards ==

To reward excellent contributions, TFP awards a prize for the best paper
accepted for the formal proceedings.

TFP traditionally pays special attention to research students, 
acknowledging
that students are almost by definition part of new subject trends. A 
student
paper is one for which the authors state that the paper is mainly the 
work of
students, the students are listed as first authors, and a student would 
present
the paper. A prize for the best student paper is awarded each year.

In both cases, it is the PC of TFP that awards the prize. In case the best
paper happens to be a student paper, that paper will then receive both 
prizes.


== Paper Submissions ==

We use EasyChair for the refereeing process. The link to the submission 
page is:

https://easychair.org/conferences/?conf=tfp2018

Authors of papers have the choice of having their contributions formally 
reviewed
either before or after the Symposium.


== Pre-symposium formal review ==

Papers to be formally reviewed before the symposium should be submitted 
before
an early deadline and receive their reviews and notification of 
acceptance for
both presentation and publication before the symposium. A paper that has 
been
rejected in this process may still be accepted for presentation at the 
symposium,
but will not be considered for the post-symposium formal review.


== Post-symposium formal review ==

Draft papers will receive minimal reviews and notification of acceptance 
for
presentation at the symposium. Authors of draft papers will be invited 
to submit
revised papers based on the feedback receive at the symposium. A 
post-symposium
refereeing process will then select a subset of these articles for 
formal publication.


== Paper categories ==

Draft papers and papers submitted for formal review are submitted as 
extended
abstracts (4 to 10 pages in length) or full papers (20 pages). The 
submission must
clearly indicate which category it belongs to: research, position, project,
evaluation, or overview paper. It should also indicate which authors are 
research
students, and whether the main author(s) are students. A draft paper for 
which all
authors are students will receive additional feedback by one of the PC 
members
shortly after the symposium has taken place.


== Format ==

Papers must be written in English, and written using the LNCS style. For 
more
information about formatting please consult the Springer LNCS web site.


== Important Dates ==

Submission (pre-symposium review):                   March 26, 2018  --  
passed  --
Submission (draft, post-symposium review):           May   11, 2018  -- 
extended --
Notification (pre- and post-symposium review):       May   13, 2018  -- 
extended --
Registration:                                        June   3, 2018
TFP Symposium:                                       June 11-13, 2018
TFPIE Workshop:                                      June   14, 2018
Student papers feedback:                             June   21, 2018
Submission (post-symposium review):                  August 14, 2018
Notification (post-symposium review):                September 20, 2018
Camera-ready paper (pre- and post-symposium review): November 30, 2018


== Program Committee ==

Program Co-chairs
Michał Pałka,    Chalmers University of Technology (SE)
Magnus Myreen,    Chalmers University of Technology (SE)

Program Committee
Soichiro Hidaka,        Hosei University (JP)
Meng Wang,              University of Bristol (UK)
Sam Tobin-Hochstadt,    Indiana University Bloomington (US)
Tiark Rompf,            Purdue University (US)
Patricia Johann,        Appalachian State University (US)
Neil Sculthorpe,        Nottingham Trent University (UK)
Andres Löh,             Well-Typed LLP (UK)
Tarmo Uustalu,          Tallinn University of Technology (EE)
Cosmin E. Oancea,       University of Copenhagen (DK)
Mauro Jaskelioff,       Universidad Nacional de Rosario (AR)
Peter Achten,           Radboud University (NL)
Dimitrios Vytiniotis,   Microsoft Research (UK)
Alberto Pardo,          Universidad de la República (UY)
Natalia Chechina,       University of Glasgow (UK)
Peter Sestoft,          IT University of Copenhagen (DK)
Scott Owens,            University of Kent (UK)


From id at joeyh.name  Mon Apr 30 12:57:01 2018
From: id at joeyh.name (Joey Hess)
Date: Mon, 30 Apr 2018 08:57:01 -0400
Subject: [Haskell-cafe] <> as result of SemigroupMonoid changes
Message-ID: <20180430125701.GA26886@kitenet.net>

I tried to follow the instructions at 
https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid
and I got a <> when my code runs with ghc 8.2.2.

My code looked like this:

import Data.Monoid
import Prelude

data InfoVal v = NoInfoVal | InfoVal v
	deriving (Show)

instance Monoid (InfoVal v) where
	mempty = NoInfoVal
	mappend _ v@(InfoVal _) = v
	mappend v NoInfoVal = v

Following the "recommended variant" for compatible code, I changed that
too:

{-# LANGUAGE CPP #-}

import Data.Monoid
import qualified Data.Semigroup as Sem
import Prelude

data InfoVal v = NoInfoVal | InfoVal v
	deriving (Show)

instance Monoid (InfoVal v) where
	mempty = NoInfoVal
#if !(MIN_VERSION_base(4,11,0))
	mappend = (<>)
#endif

instance Sem.Semigroup (InfoVal v) where
	_ <> v@(InfoVal _) = v
	v <> NoInfoVal = v

This loops because <> comes from Data.Monoid not from Data.Semigroup, 
so mappend = mappend.

Note that I diverged slightly from the instructions to get to this wrong
code; I imported Data.Semigroup qualified. Without the qualification,
the above code fails to compile, with Ambiguous occurrence ‘<>’

So, the transition instructions don't produce code that ghc 8.2.2 can build, 
and when the obvious fix is made to get it to compile, it compiles into a
loop, that is *not* a loop when compiled with newer versions of ghc.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: 

From danburton.email at gmail.com  Mon Apr 30 14:07:18 2018
From: danburton.email at gmail.com (Dan Burton)
Date: Mon, 30 Apr 2018 14:07:18 +0000
Subject: [Haskell-cafe] <> as result of SemigroupMonoid changes
In-Reply-To: <20180430125701.GA26886@kitenet.net>
References: <20180430125701.GA26886@kitenet.net>
Message-ID: 

If you’re going to import Data.Semigroup as a sort of backwards
compatibility shim, then I don’t think you should import it qualified. To
avoid the ambiguity error, how about “import Data.Monoid hiding ((<>))”?

On Mon, Apr 30, 2018 at 05:57 Joey Hess  wrote:

> I tried to follow the instructions at
> https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid
> and I got a <> when my code runs with ghc 8.2.2.
>
> My code looked like this:
>
> import Data.Monoid
> import Prelude
>
> data InfoVal v = NoInfoVal | InfoVal v
>         deriving (Show)
>
> instance Monoid (InfoVal v) where
>         mempty = NoInfoVal
>         mappend _ v@(InfoVal _) = v
>         mappend v NoInfoVal = v
>
> Following the "recommended variant" for compatible code, I changed that
> too:
>
> {-# LANGUAGE CPP #-}
>
> import Data.Monoid
> import qualified Data.Semigroup as Sem
> import Prelude
>
> data InfoVal v = NoInfoVal | InfoVal v
>         deriving (Show)
>
> instance Monoid (InfoVal v) where
>         mempty = NoInfoVal
> #if !(MIN_VERSION_base(4,11,0))
>         mappend = (<>)
> #endif
>
> instance Sem.Semigroup (InfoVal v) where
>         _ <> v@(InfoVal _) = v
>         v <> NoInfoVal = v
>
> This loops because <> comes from Data.Monoid not from Data.Semigroup,
> so mappend = mappend.
>
> Note that I diverged slightly from the instructions to get to this wrong
> code; I imported Data.Semigroup qualified. Without the qualification,
> the above code fails to compile, with Ambiguous occurrence ‘<>’
>
> So, the transition instructions don't produce code that ghc 8.2.2 can
> build,
> and when the obvious fix is made to get it to compile, it compiles into a
> loop, that is *not* a loop when compiled with newer versions of ghc.
>
> --
> see shy jo
> _______________________________________________
> 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.

-- 
-- Dan Burton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From id at joeyh.name  Mon Apr 30 17:42:09 2018
From: id at joeyh.name (Joey Hess)
Date: Mon, 30 Apr 2018 13:42:09 -0400
Subject: [Haskell-cafe] <> as result of SemigroupMonoid changes
In-Reply-To: 
References: <20180430125701.GA26886@kitenet.net>
 
Message-ID: <20180430174209.GA8376@kitenet.net>

Dan Burton wrote:
> If you’re going to import Data.Semigroup as a sort of backwards compatibility
> shim, then I don’t think you should import it qualified. To avoid the ambiguity
> error, how about “import Data.Monoid hiding ((<>))”?

Likely mempty could be used elsewhere in the module and so Data.Monoid
would be needed (when supporting older versions of base).

mappend = (Sem.<>) seems like the simplest change to the examples on the
wiki page that would avoid the problem.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: