From christian at ponies.io Wed Jul 1 06:54:52 2015 From: christian at ponies.io (Christian Marie) Date: Wed, 1 Jul 2015 16:54:52 +1000 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: Message-ID: <20150701065452.GA29000@cucumber.anchor.net.au> On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: > There are a large number of untriaged pull requests and issues > currently open on the issue tracker for haskell-src-exts. The tool is > widely used by tool writers but the last commit to the project is now > over 6 months ago. I was about to post this exact message after searching around for a good hour. > 1. Does anyone know if Niklas or Peter plan to return to the project? I didn't contact them directly. I'm not so sure if Nicklas is active at all. > 2. Is there anyone else who is interested in updating the HSE parser? Yes, I've got at least one fix I'd like to make myself and I'd be happy to do some triaging and releasing too. Most of the PRs look pretty good. Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows something aobut this. I'll email some people in the haskell suite group directly if this thread doesn't go anywhere. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mike at izbicki.me Wed Jul 1 07:18:59 2015 From: mike at izbicki.me (Mike Izbicki) Date: Wed, 1 Jul 2015 00:18:59 -0700 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <20150701065452.GA29000@cucumber.anchor.net.au> References: <20150701065452.GA29000@cucumber.anchor.net.au> Message-ID: I've always been curious why we need a stand alone package for parsing haskell code? Last time I tried to use haskell-src-exts (admittedly several years ago), it was out of date and didn't support the extensions I wanted. It seems like the ideal solution would be to have GHC's parsing code exposed as a library. And this library would be compatible with template haskell. Is there some technical reason why this is inherently difficult? Or is it just an accident of history that things didn't develop that way? On Tue, Jun 30, 2015 at 11:54 PM, Christian Marie wrote: > On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: >> There are a large number of untriaged pull requests and issues >> currently open on the issue tracker for haskell-src-exts. The tool is >> widely used by tool writers but the last commit to the project is now >> over 6 months ago. > > I was about to post this exact message after searching around for a good hour. > >> 1. Does anyone know if Niklas or Peter plan to return to the project? > > I didn't contact them directly. I'm not so sure if Nicklas is active at all. > >> 2. Is there anyone else who is interested in updating the HSE parser? > > Yes, I've got at least one fix I'd like to make myself and I'd be happy to do > some triaging and releasing too. Most of the PRs look pretty good. > > Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows > something aobut this. > > I'll email some people in the haskell suite group directly if this thread > doesn't go anywhere. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From roma at ro-che.info Wed Jul 1 07:31:08 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 1 Jul 2015 10:31:08 +0300 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <20150701065452.GA29000@cucumber.anchor.net.au> References: <20150701065452.GA29000@cucumber.anchor.net.au> Message-ID: <5593973C.9010600@ro-che.info> On 01/07/15 09:54, Christian Marie wrote: > On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: >> There are a large number of untriaged pull requests and issues >> currently open on the issue tracker for haskell-src-exts. The tool is >> widely used by tool writers but the last commit to the project is now >> over 6 months ago. > > I was about to post this exact message after searching around for a good hour. > >> 1. Does anyone know if Niklas or Peter plan to return to the project? > > I didn't contact them directly. I'm not so sure if Nicklas is active at all. > >> 2. Is there anyone else who is interested in updating the HSE parser? > > Yes, I've got at least one fix I'd like to make myself and I'd be happy to do > some triaging and releasing too. Most of the PRs look pretty good. > > Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows > something aobut this. > > I'll email some people in the haskell suite group directly if this thread > doesn't go anywhere. I no longer maintain haskell-src-exts[1]. That said, I am happy to give maintainer rights on github and hackage to a new volunteer(s) unless Niklas or Peter (cc'd) objects. Just let me know your github and hackage usernames. [1]: https://ro-che.info/articles/2014-11-01-rebalancing-open-source-portfolio Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alan.zimm at gmail.com Wed Jul 1 07:33:26 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 1 Jul 2015 09:33:26 +0200 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: <20150701065452.GA29000@cucumber.anchor.net.au> Message-ID: I think the main argument against using GHC is that the library is intimately tied to the current compiler, so writing a tool to process haskell source which is compiler version independent it tricky, requiring lots of CPP. I am starting to wonder if it does not make sense to make a companion library for each GHC release with is just the parser/AST, and so can be used with any other compiler, even a non-ghc one. Alan On Wed, Jul 1, 2015 at 9:18 AM, Mike Izbicki wrote: > I've always been curious why we need a stand alone package for parsing > haskell code? Last time I tried to use haskell-src-exts (admittedly > several years ago), it was out of date and didn't support the > extensions I wanted. > > It seems like the ideal solution would be to have GHC's parsing code > exposed as a library. And this library would be compatible with > template haskell. Is there some technical reason why this is > inherently difficult? Or is it just an accident of history that > things didn't develop that way? > > On Tue, Jun 30, 2015 at 11:54 PM, Christian Marie > wrote: > > On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: > >> There are a large number of untriaged pull requests and issues > >> currently open on the issue tracker for haskell-src-exts. The tool is > >> widely used by tool writers but the last commit to the project is now > >> over 6 months ago. > > > > I was about to post this exact message after searching around for a good > hour. > > > >> 1. Does anyone know if Niklas or Peter plan to return to the project? > > > > I didn't contact them directly. I'm not so sure if Nicklas is active at > all. > > > >> 2. Is there anyone else who is interested in updating the HSE parser? > > > > Yes, I've got at least one fix I'd like to make myself and I'd be happy > to do > > some triaging and releasing too. Most of the PRs look pretty good. > > > > Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows > > something aobut this. > > > > I'll email some people in the haskell suite group directly if this thread > > doesn't go anywhere. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Wed Jul 1 07:50:52 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 1 Jul 2015 09:50:52 +0200 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <5593973C.9010600@ro-che.info> References: <20150701065452.GA29000@cucumber.anchor.net.au> <5593973C.9010600@ro-che.info> Message-ID: On Wed, Jul 1, 2015 at 9:31 AM, Roman Cheplyaka wrote: > On 01/07/15 09:54, Christian Marie wrote: >> On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: >>> There are a large number of untriaged pull requests and issues >>> currently open on the issue tracker for haskell-src-exts. The tool is >>> widely used by tool writers but the last commit to the project is now >>> over 6 months ago. >> >> I was about to post this exact message after searching around for a good hour. >> >>> 1. Does anyone know if Niklas or Peter plan to return to the project? >> >> I didn't contact them directly. I'm not so sure if Nicklas is active at all. >> >>> 2. Is there anyone else who is interested in updating the HSE parser? >> >> Yes, I've got at least one fix I'd like to make myself and I'd be happy to do >> some triaging and releasing too. Most of the PRs look pretty good. >> >> Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows >> something aobut this. >> >> I'll email some people in the haskell suite group directly if this thread >> doesn't go anywhere. > > I no longer maintain haskell-src-exts[1]. That said, I am happy to give > maintainer rights on github and hackage to a new volunteer(s) unless Niklas or > Peter (cc'd) objects. Just let me know your github and hackage usernames. I also have commit rights on github, and although I don't have enough free time to be official maintainer, I could merge the occasional pull request when I have some free time. I have not done so since I'm not the maintainer and I was added to the haskell-suite project for other packages, but if people would like me to be slightly more involved in haskell-src-exts, I could do that. Regards, Erik From roma at ro-che.info Wed Jul 1 07:51:26 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 1 Jul 2015 10:51:26 +0300 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: <20150701065452.GA29000@cucumber.anchor.net.au> <5593973C.9010600@ro-che.info> Message-ID: <55939BFE.3040307@ro-che.info> Thanks for the update, Peter. Forwarding it to cafe. On 01/07/15 10:36, Peter A Jonsson wrote: > Hi Roman, > > I?ve inserted what I replied to Matthew a couple of days ago below. > Unfortunately my reply bounced from both libraries and haskell-cafe > since I?m not a subscriber. Matthew should have gotten the reply > though. > > Kind Regards, > > Peter > > > Dear Matthew, > >> I think it is important to get this work merged and update the >> parser to support modern language features introduced in GHC 7.8 >> and 7.10. > > We all agree about the importance of HSE supporting modern language > features that people actually use. The simple reason for my > inactivity lately is that I?ve been swamped at work so HSE has been > on the backburner. I just started my vacation though so I?m slowly > working through my backlog of things that I haven?t had time to do > previously. Without having looked at any patches in the bug tracker I > can say that the current state of HSE is stable so we should be able > to merge the simple things quickly and the more involved things > should be doable. Once that is done it?s probably time to make a new > yearly major release. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian at ponies.io Wed Jul 1 08:19:56 2015 From: christian at ponies.io (Christian Marie) Date: Wed, 1 Jul 2015 18:19:56 +1000 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <5593973C.9010600@ro-che.info> References: <20150701065452.GA29000@cucumber.anchor.net.au> <5593973C.9010600@ro-che.info> Message-ID: <20150701081956.GA2283@cucumber.anchor.net.au> On Wed, Jul 01, 2015 at 10:31:08AM +0300, Roman Cheplyaka wrote: > I no longer maintain haskell-src-exts[1]. That said, I am happy to give > maintainer rights on github and hackage to a new volunteer(s) unless Niklas or > Peter (cc'd) objects. Just let me know your github and hackage usernames. > > [1]: https://ro-che.info/articles/2014-11-01-rebalancing-open-source-portfolio Your link helped with context, thanks. If Niklas or Peter does not object: My hackage username: ChristianMarie http://hackage.haskell.org/user/ChristianMarie Github username: christian-marie https://github.com/christian-marie/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From roma at ro-che.info Wed Jul 1 08:27:38 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 1 Jul 2015 11:27:38 +0300 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <20150701081956.GA2283@cucumber.anchor.net.au> References: <20150701065452.GA29000@cucumber.anchor.net.au> <5593973C.9010600@ro-che.info> <20150701081956.GA2283@cucumber.anchor.net.au> Message-ID: <5593A47A.40002@ro-che.info> On 01/07/15 11:19, Christian Marie wrote: > On Wed, Jul 01, 2015 at 10:31:08AM +0300, Roman Cheplyaka wrote: >> I no longer maintain haskell-src-exts[1]. That said, I am happy to give >> maintainer rights on github and hackage to a new volunteer(s) unless Niklas or >> Peter (cc'd) objects. Just let me know your github and hackage usernames. >> >> [1]: https://ro-che.info/articles/2014-11-01-rebalancing-open-source-portfolio > > Your link helped with context, thanks. > > If Niklas or Peter does not object: > > My hackage username: ChristianMarie http://hackage.haskell.org/user/ChristianMarie > Github username: christian-marie https://github.com/christian-marie/ Since Peter has responded and remains an active maintainer, I'll leave it up to him. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian at ponies.io Wed Jul 1 08:31:54 2015 From: christian at ponies.io (Christian Marie) Date: Wed, 1 Jul 2015 18:31:54 +1000 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: <20150701065452.GA29000@cucumber.anchor.net.au> Message-ID: <20150701083154.GB2283@cucumber.anchor.net.au> On Wed, Jul 01, 2015 at 09:33:26AM +0200, Alan & Kim Zimmerman wrote: > I am starting to wonder if it does not make sense to make a companion > library for each GHC release with is just the parser/AST, and so can be > used with any other compiler, even a non-ghc one. This would have been my intuition, I suspect it isn't that simple though. The duplication of effort does seem odd, and this would solve the problem of linters and the like always playing catch up. This is affecting many users. I, personally, have avoided extensions in the past when haskell-src-exts threw its toys out of the cot (specifically LambdaCase, then DataKinds). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matthewtpickering at gmail.com Wed Jul 1 09:29:10 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 1 Jul 2015 10:29:10 +0100 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: <20150701065452.GA29000@cucumber.anchor.net.au> Message-ID: Separating the parser from GHC is not trivial. Firstly the parser takes DynFlags as an argument which is used in all stages of the GHC pipeline to keep track of which flags are enabled. Second - this would also require all syntactic datatypes to be extracted into a separate module as well as all the various datatypes which they depend on as well, for example RdrName depends on Name which is only introduced after the parsing stage but would also need to be extracted. HSE is also desirable because it already has momentum, a not insignificant number of programs use tooling based on HSE. Secondly, it is much easier to manipulate in general than the GHC AST, especially the difference between the annotated and unannotated source. All this being said, I would much prefer a world where GHC was easier to use as a library for this kind of thing as it is difficult to remain consistent between the two but keeping HSE updated should remain important in the near future. Matt On Wed, Jul 1, 2015 at 8:18 AM, Mike Izbicki wrote: > I've always been curious why we need a stand alone package for parsing > haskell code? Last time I tried to use haskell-src-exts (admittedly > several years ago), it was out of date and didn't support the > extensions I wanted. > > It seems like the ideal solution would be to have GHC's parsing code > exposed as a library. And this library would be compatible with > template haskell. Is there some technical reason why this is > inherently difficult? Or is it just an accident of history that > things didn't develop that way? > > On Tue, Jun 30, 2015 at 11:54 PM, Christian Marie wrote: >> On Mon, Jun 29, 2015 at 01:13:54PM +0100, Matthew Pickering wrote: >>> There are a large number of untriaged pull requests and issues >>> currently open on the issue tracker for haskell-src-exts. The tool is >>> widely used by tool writers but the last commit to the project is now >>> over 6 months ago. >> >> I was about to post this exact message after searching around for a good hour. >> >>> 1. Does anyone know if Niklas or Peter plan to return to the project? >> >> I didn't contact them directly. I'm not so sure if Nicklas is active at all. >> >>> 2. Is there anyone else who is interested in updating the HSE parser? >> >> Yes, I've got at least one fix I'd like to make myself and I'd be happy to do >> some triaging and releasing too. Most of the PRs look pretty good. >> >> Roman Cheplyaka is a maintainer on hackage, hopefully he sees and knows >> something aobut this. >> >> I'll email some people in the haskell suite group directly if this thread >> doesn't go anywhere. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From saihemanth at gmail.com Wed Jul 1 14:10:14 2015 From: saihemanth at gmail.com (Hemanth Kapila) Date: Wed, 01 Jul 2015 14:10:14 +0000 Subject: [Haskell-cafe] A datatype with a single constructor and forall to multiple constructors without forall Message-ID: Hi, Occassionally, in (*good*) haskell libraries, I came across data types that are defined with a single constructor and a forall. For instance, Iteratee[0] is defined as below *newtype Iteratee s m a =* * Iteratee {runIter :: forall r. (a -> Stream s -> m r) -> ((Stream s -> Iteratee s m a) -> Maybe SomeException -> m r) -> m r}* I *think* it is equivalent to the following. But am not sure. *data Iteratee s m a = IOne (m (a , Stream s))* * | ITwo (Stream s -> m (Iteratee s m a)) (Maybe SomeException)* Can some one please explain what are the advantages of using the forall version? Does it significantly improve performance because it is newtype? Or does it help in reasoning about code (in some proof tools or such)? And can some one kindly point me to some references that help me convert from one form to another reliably? Many Thanks, Hemanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Wed Jul 1 14:38:04 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Wed, 1 Jul 2015 17:38:04 +0300 Subject: [Haskell-cafe] A datatype with a single constructor and forall to multiple constructors without forall In-Reply-To: References: Message-ID: <5593FB4C.9090301@ro-che.info> On 01/07/15 17:10, Hemanth Kapila wrote: > Hi, > > Occassionally, in (*good*) haskell libraries, I came across data types > that are defined with a single constructor and a forall. > > For instance, Iteratee[0] is defined as below > > > *newtype Iteratee s m a =* > * Iteratee {runIter :: forall r. (a -> Stream s -> m r) -> ((Stream s > -> Iteratee s m a) -> Maybe SomeException -> m r) -> m r}* > > > > I *think* it is equivalent to the following. But am not sure. > *data Iteratee s m a = IOne (m (a , Stream s))* > * | ITwo (Stream s -> m (Iteratee s m a)) (Maybe > SomeException)* > > > Can some one please explain what are the advantages of using the forall > version? Does it significantly improve performance because it is > newtype? Or does it help in reasoning about code (in some proof tools or > such)? > > And can some one kindly point me to some references that help me > convert from one form to another reliably? Here are a couple of references: http://okmij.org/ftp/tagless-final/course/Boehm-Berarducci.html http://www.janis-voigtlaender.eu/papers/AsymptoticImprovementOfComputationsOverFreeMonads.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nicola.gigante at gmail.com Wed Jul 1 16:27:40 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 1 Jul 2015 18:27:40 +0200 Subject: [Haskell-cafe] Bibliographic references on advantages of functional languages for refactoring In-Reply-To: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> References: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> Message-ID: > Il giorno 23/giu/2015, alle ore 18:11, Nicola Gigante ha scritto: > Ping, anyone? > Hi all, > > I?m writing my master thesis, which is not itself about functional programming but > I use Haskell as the language chosen for the implementation of whatever I?m > talking about. > > To motivate the choice more than ?I like the language? I?m arguing that > since I?m implementing experimental stuff and I?ll need to change the code > and refactor very often, a strongly typed language is what I need. > > I wrote this sentence: > "Strongly-typed programming eases the refactoring process by leveraging > the compiler to spot wrong transformations before they turn into runtime bugs? > > Since this thesis is not itself about functional programming this sentence needs > to be backed by something. In other words I need to cite some published paper > where this is said/surveyed/proved/whatever. > > So the question: can you help me find referentiable published work relative to > how strongly-typed functional programming eases refactoring? > A survey or some case-study report or some functional pearl, dunno. > > Thank you very much in advance, > > Nicola From alan.zimm at gmail.com Wed Jul 1 16:34:56 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 1 Jul 2015 18:34:56 +0200 Subject: [Haskell-cafe] Bibliographic references on advantages of functional languages for refactoring In-Reply-To: References: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> Message-ID: Try http://www.cs.kent.ac.uk/projects/refactor-fp/ Alan On Wed, Jul 1, 2015 at 6:27 PM, Nicola Gigante wrote: > > > Il giorno 23/giu/2015, alle ore 18:11, Nicola Gigante < > nicola.gigante at gmail.com> ha scritto: > > > > Ping, anyone? > > > Hi all, > > > > I?m writing my master thesis, which is not itself about functional > programming but > > I use Haskell as the language chosen for the implementation of whatever > I?m > > talking about. > > > > To motivate the choice more than ?I like the language? I?m arguing that > > since I?m implementing experimental stuff and I?ll need to change the > code > > and refactor very often, a strongly typed language is what I need. > > > > I wrote this sentence: > > "Strongly-typed programming eases the refactoring process by leveraging > > the compiler to spot wrong transformations before they turn into runtime > bugs? > > > > Since this thesis is not itself about functional programming this > sentence needs > > to be backed by something. In other words I need to cite some published > paper > > where this is said/surveyed/proved/whatever. > > > > So the question: can you help me find referentiable published work > relative to > > how strongly-typed functional programming eases refactoring? > > A survey or some case-study report or some functional pearl, dunno. > > > > Thank you very much in advance, > > > > Nicola > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at izbicki.me Wed Jul 1 16:49:30 2015 From: mike at izbicki.me (Mike Izbicki) Date: Wed, 1 Jul 2015 09:49:30 -0700 Subject: [Haskell-cafe] ANNOUNCE: SubHask-0.1 Message-ID: SubHask is an alternative prelude for programming in subcategories of Hask. The documentation includes examples on: * the category of polynomials * how to give set a monad instance in two different categories * basic linear algebra using the category of linear functions More information at: http://github.com/mikeizbicki/subhask I'd like to emphasize that SubHask still has a number of bugs that need to be fixed. This release should be seen as just a technology preview. From s.j.thompson at kent.ac.uk Wed Jul 1 21:52:42 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Wed, 1 Jul 2015 22:52:42 +0100 Subject: [Haskell-cafe] Bibliographic references on advantages of functional languages for refactoring In-Reply-To: References: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> Message-ID: There?s also a discussion about it in this overview paper Refactoring tools for functional languages, Journal of Functional Programming / Volume 23 / Issue 03 / May 2013 http://journals.cambridge.org/repo_A90unxgK Regards Simon > On 1 Jul 2015, at 17:34, Alan & Kim Zimmerman wrote: > > Try http://www.cs.kent.ac.uk/projects/refactor-fp/ > > Alan > > On Wed, Jul 1, 2015 at 6:27 PM, Nicola Gigante > wrote: > > > Il giorno 23/giu/2015, alle ore 18:11, Nicola Gigante > ha scritto: > > > > Ping, anyone? > > > Hi all, > > > > I?m writing my master thesis, which is not itself about functional programming but > > I use Haskell as the language chosen for the implementation of whatever I?m > > talking about. > > > > To motivate the choice more than ?I like the language? I?m arguing that > > since I?m implementing experimental stuff and I?ll need to change the code > > and refactor very often, a strongly typed language is what I need. > > > > I wrote this sentence: > > "Strongly-typed programming eases the refactoring process by leveraging > > the compiler to spot wrong transformations before they turn into runtime bugs? > > > > Since this thesis is not itself about functional programming this sentence needs > > to be backed by something. In other words I need to cite some published paper > > where this is said/surveyed/proved/whatever. > > > > So the question: can you help me find referentiable published work relative to > > how strongly-typed functional programming eases refactoring? > > A survey or some case-study report or some functional pearl, dunno. > > > > Thank you very much in advance, > > > > Nicola > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangbj at gmail.com Fri Jul 3 08:18:55 2015 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 03 Jul 2015 08:18:55 +0000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? Message-ID: Hi, First of all, I found it interesting that loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) I think mapM_ is used very commonly, why it's performance is even lower than a hand-written loop function? 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' updated so that I/O actions can be done in-order? ) Consider below function: f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () f3 u r i = let !v = u ! i in go (f31 v) i i where f31 v j = readArray r j >>= \v1 -> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) f31 :: Int -> Int -> IO () go g k s = when (k <= maxn) ( g k >> go g (s+k) s ) When call f3: loopM_ (f3 uu res) 1 1 1000000 Which will have blow profiling output: individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc ... loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 f3 Main 113 1000000 1.0 2.0 70.2 69.1 f3.go Main 116 14970034 32.7 67.1 68.8 67.1 f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 f3.f31 Main 114 0 0.3 0.0 0.4 0.0 f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 ... Why f3.go consumes so much space (67.1%)? The only reason I can think of is IO Monad chain (>>) isn't space free as I thought. Did I get something fundamentally wrong? Thanks baojun -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Fri Jul 3 09:34:32 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Fri, 3 Jul 2015 19:34:32 +1000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: I recall having this issue also, and I eventually ending up concluding that GHC didn't optimise away the list in "mapM_". Try with GHC 7.10 though, it seems to be better with optimising lists into simple loops. On Fri, Jul 3, 2015 at 6:18 PM, Baojun Wang wrote: > Hi, > > First of all, I found it interesting that > > loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) > > loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) > > I think mapM_ is used very commonly, why it's performance is even lower > than a hand-written loop function? > > 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, it > still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' > updated so that I/O actions can be done in-order? ) > > Consider below function: > > f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () > f3 u r i = let !v = u ! i > in go (f31 v) i i > where f31 v j = readArray r j >>= \v1 -> > writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) > f31 :: Int -> Int -> IO () > go g k s = when (k <= maxn) ( > g k >> go g (s+k) s ) > > When call f3: > > loopM_ (f3 uu res) 1 1 1000000 > > Which will have blow profiling output: > > individual inherited > COST CENTRE MODULE no. entries %time %alloc %time %alloc > > > ... > loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 > f3 Main 113 1000000 1.0 2.0 70.2 69.1 > f3.go Main 116 14970034 32.7 67.1 68.8 67.1 > f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 > f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 > f3.f31 Main 114 0 0.3 0.0 0.4 0.0 > f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 > ... > Why f3.go consumes so much space (67.1%)? The only reason I can think of > is IO Monad chain (>>) isn't space free as I thought. > > Did I get something fundamentally wrong? > > Thanks > baojun > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Jul 3 09:50:28 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 3 Jul 2015 10:50:28 +0100 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: <20150703095028.GB6716@weber> On Fri, Jul 03, 2015 at 08:18:55AM +0000, Baojun Wang wrote: > Consider below function: > > f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () > f3 u r i = let !v = u ! i > in go (f31 v) i i > where f31 v j = readArray r j >>= \v1 -> > writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) > f31 :: Int -> Int -> IO () > go g k s = when (k <= maxn) ( > g k >> go g (s+k) s ) > > When call f3: > > loopM_ (f3 uu res) 1 1 1000000 Could you provide complete working code (including definitions of uu and res) and I will have a go at diagnosing. (My first guess is that you need to force (v1 + (fromIntegral i) * (fromIntegral v)).) Tom From wangbj at gmail.com Fri Jul 3 16:06:45 2015 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 03 Jul 2015 16:06:45 +0000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: <20150703095028.GB6716@weber> References: <20150703095028.GB6716@weber> Message-ID: Full source code: https://github.com/wangbj/haskell/blob/master/lcmsum.hs I build the program with: ghc -O2 --make -rtsopts -prof -auto-all lcmsum and run it with: echo -ne '5\n100\n1000\n10000\n100000\n1000000\n' | ./lcmsum +RTS -sstderr -p I've tried use ``let !ret = (v1+(fromIntegral i) * (fromIntegral v)) in r'' instead, however it didn't make any difference per profiling. (both Array are Unboxed). Thanks baojun On Fri, Jul 3, 2015 at 2:50 AM Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Jul 03, 2015 at 08:18:55AM +0000, Baojun Wang wrote: > > Consider below function: > > > > f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () > > f3 u r i = let !v = u ! i > > in go (f31 v) i i > > where f31 v j = readArray r j >>= \v1 -> > > writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) > > f31 :: Int -> Int -> IO () > > go g k s = when (k <= maxn) ( > > g k >> go g (s+k) s ) > > > > When call f3: > > > > loopM_ (f3 uu res) 1 1 1000000 > > Could you provide complete working code (including definitions of uu and > res) and I will have a go at diagnosing. (My first guess is that you need > to force (v1 + (fromIntegral i) * (fromIntegral v)).) > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangbj at gmail.com Fri Jul 3 16:16:03 2015 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 03 Jul 2015 16:16:03 +0000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: <20150703095028.GB6716@weber> Message-ID: few more points: - In function f2/f3 I use a local function ``go'' instead of loopM_, it turns out that local ``go'' function is much faster than loopM_ (loopM_ is still faster than mapM_); - If I add a signature for loopM_ ( loopM_ :: (Int -> IO ()) -> Int -> Int -> Int -> IO () ), then the program runs noticeable slower even profiling is turned off; These really looks odd to me, and I think it really makes optimization painful. On Fri, Jul 3, 2015 at 9:06 AM Baojun Wang wrote: > Full source code: > > https://github.com/wangbj/haskell/blob/master/lcmsum.hs > > I build the program with: > > ghc -O2 --make -rtsopts -prof -auto-all lcmsum > > and run it with: > > echo -ne '5\n100\n1000\n10000\n100000\n1000000\n' | ./lcmsum +RTS > -sstderr -p > > I've tried use > > ``let !ret = (v1+(fromIntegral i) * (fromIntegral v)) in r'' instead, > however it didn't make any difference per profiling. (both Array are > Unboxed). > > Thanks > baojun > > > On Fri, Jul 3, 2015 at 2:50 AM Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> On Fri, Jul 03, 2015 at 08:18:55AM +0000, Baojun Wang wrote: >> > Consider below function: >> > >> > f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () >> > f3 u r i = let !v = u ! i >> > in go (f31 v) i i >> > where f31 v j = readArray r j >>= \v1 -> >> > writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) >> > f31 :: Int -> Int -> IO () >> > go g k s = when (k <= maxn) ( >> > g k >> go g (s+k) s ) >> > >> > When call f3: >> > >> > loopM_ (f3 uu res) 1 1 1000000 >> >> Could you provide complete working code (including definitions of uu and >> res) and I will have a go at diagnosing. (My first guess is that you need >> to force (v1 + (fromIntegral i) * (fromIntegral v)).) >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Jul 3 16:52:22 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 3 Jul 2015 17:52:22 +0100 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: <20150703095028.GB6716@weber> Message-ID: <20150703165221.GE6716@weber> On Fri, Jul 03, 2015 at 04:06:45PM +0000, Baojun Wang wrote: > Full source code: > > https://github.com/wangbj/haskell/blob/master/lcmsum.hs > > I build the program with: > > ghc -O2 --make -rtsopts -prof -auto-all lcmsum > > and run it with: > > echo -ne '5\n100\n1000\n10000\n100000\n1000000\n' | ./lcmsum +RTS -sstderr > -p > > I've tried use > > ``let !ret = (v1+(fromIntegral i) * (fromIntegral v)) in r'' instead, > however it didn't make any difference per profiling. (both Array are > Unboxed). Correct, since they're unboxed forcing the thunk is done automatically. I'm puzzled. What output are you seeing and what were you expecting? I see "13 MB total memory in use". That doesn't sound like a lot when you are allocating two arrays of size 10^6. There's a lot of *allocation*, but not so much peak memory usage. I get the same result on GHC 7.6.3 and 7.8.4. My complete output: % ghc -O2 --make -rtsopts -prof -auto-all lcmsum [1 of 1] Compiling Main ( lcmsum.hs, lcmsum.o ) lcmsum.hs:48:9: Warning: In the use of `unsafeFreeze' (imported from Data.Array.IO, but defined in Data.Array.MArray): Deprecated: "Please import from Data.Array.Unsafe instead; This will be removed in the next release" lcmsum.hs:51:3: Warning: In the use of `unsafeFreeze' (imported from Data.Array.IO, but defined in Data.Array.MArray): Deprecated: "Please import from Data.Array.Unsafe instead; This will be removed in the next release" Linking lcmsum ... % echo -ne '5\n100\n1000\n10000\n100000\n1000000\n' | ./lcmsum +RTS -sstderr -p 152935099400 1529628080000 278320460000 277913417200000 277811686426000000 2,273,379,656 bytes allocated in the heap 233,104 bytes copied during GC 12,002,728 bytes maximum residency (3 sample(s)) 580,184 bytes maximum slop 13 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4350 colls, 0 par 0.02s 0.02s 0.0000s 0.0000s Gen 1 3 colls, 0 par 0.00s 0.00s 0.0003s 0.0005s INIT time 0.00s ( 0.00s elapsed) MUT time 2.66s ( 2.65s elapsed) GC time 0.02s ( 0.02s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 2.67s ( 2.67s elapsed) %GC time 0.6% (0.6% elapsed) Alloc rate 856,218,428 bytes per MUT second Productivity 99.4% of total user, 99.5% of total elapsed From stefan.reich.maker.of.eye at googlemail.com Fri Jul 3 17:11:30 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 3 Jul 2015 19:11:30 +0200 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: Here's a general question: Can the output of the Haskell compiler be inspected in some - readable - way? Stefan On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang wrote: > Hi, > > First of all, I found it interesting that > > loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) > > loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) > > I think mapM_ is used very commonly, why it's performance is even lower > than a hand-written loop function? > > 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, it > still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' > updated so that I/O actions can be done in-order? ) > > Consider below function: > > f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () > f3 u r i = let !v = u ! i > in go (f31 v) i i > where f31 v j = readArray r j >>= \v1 -> > writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) > f31 :: Int -> Int -> IO () > go g k s = when (k <= maxn) ( > g k >> go g (s+k) s ) > > When call f3: > > loopM_ (f3 uu res) 1 1 1000000 > > Which will have blow profiling output: > > individual inherited > COST CENTRE MODULE no. entries %time %alloc %time %alloc > > > ... > loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 > f3 Main 113 1000000 1.0 2.0 70.2 69.1 > f3.go Main 116 14970034 32.7 67.1 68.8 67.1 > f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 > f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 > f3.f31 Main 114 0 0.3 0.0 0.4 0.0 > f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 > ... > Why f3.go consumes so much space (67.1%)? The only reason I can think of > is IO Monad chain (>>) isn't space free as I thought. > > Did I get something fundamentally wrong? > > Thanks > baojun > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Fri Jul 3 17:19:14 2015 From: danburton.email at gmail.com (Dan Burton) Date: Fri, 3 Jul 2015 10:19:14 -0700 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: It can, if you know the correct magic incantations to give ghc (which I don't, but I know the knowledge is out there). The phrase to Google is "reading ghc core", where "core" refers to an intermediate language that still resembles Haskell. On Friday, July 3, 2015, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Here's a general question: Can the output of the Haskell compiler be > inspected in some - readable - way? > > Stefan > > On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang > wrote: > >> Hi, >> >> First of all, I found it interesting that >> >> loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) >> >> loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) >> >> I think mapM_ is used very commonly, why it's performance is even lower >> than a hand-written loop function? >> >> 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, >> it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' >> updated so that I/O actions can be done in-order? ) >> >> Consider below function: >> >> f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () >> f3 u r i = let !v = u ! i >> in go (f31 v) i i >> where f31 v j = readArray r j >>= \v1 -> >> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) >> f31 :: Int -> Int -> IO () >> go g k s = when (k <= maxn) ( >> g k >> go g (s+k) s ) >> >> When call f3: >> >> loopM_ (f3 uu res) 1 1 1000000 >> >> Which will have blow profiling output: >> >> individual inherited >> COST CENTRE MODULE no. entries %time %alloc %time %alloc >> >> >> ... >> loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 >> f3 Main 113 1000000 1.0 2.0 70.2 69.1 >> f3.go Main 116 14970034 32.7 67.1 68.8 67.1 >> f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 >> f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 >> f3.f31 Main 114 0 0.3 0.0 0.4 0.0 >> f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 >> ... >> Why f3.go consumes so much space (67.1%)? The only reason I can think of >> is IO Monad chain (>>) isn't space free as I thought. >> >> Did I get something fundamentally wrong? >> >> Thanks >> baojun >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -- -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jul 3 17:23:46 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 3 Jul 2015 13:23:46 -0400 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: On Fri, Jul 3, 2015 at 1:11 PM, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Here's a general question: Can the output of the Haskell compiler be > inspected in some - readable - way? > ghc -ddump-simpl (meaning output of the simplifier pass, commonly known as Core) There at least used to be a package "ghc-core" which would do this and syntax highlight the result, etc. to help with reading it. -- 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 tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Jul 3 17:23:52 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 3 Jul 2015 18:23:52 +0100 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: <20150703172352.GF6716@weber> Probably easiest to just use the ghc-core package: http://hackage.haskell.org/package/ghc-core On Fri, Jul 03, 2015 at 10:19:14AM -0700, Dan Burton wrote: > It can, if you know the correct magic incantations to give ghc (which I > don't, but I know the knowledge is out there). The phrase to Google is > "reading ghc core", where "core" refers to an intermediate language that > still resembles Haskell. > > On Friday, July 3, 2015, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > > > Here's a general question: Can the output of the Haskell compiler be > > inspected in some - readable - way? > > > > Stefan > > > > On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang > > wrote: > > > >> Hi, > >> > >> First of all, I found it interesting that > >> > >> loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) > >> > >> loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) > >> > >> I think mapM_ is used very commonly, why it's performance is even lower > >> than a hand-written loop function? > >> > >> 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, > >> it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' > >> updated so that I/O actions can be done in-order? ) > >> > >> Consider below function: > >> > >> f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () > >> f3 u r i = let !v = u ! i > >> in go (f31 v) i i > >> where f31 v j = readArray r j >>= \v1 -> > >> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) > >> f31 :: Int -> Int -> IO () > >> go g k s = when (k <= maxn) ( > >> g k >> go g (s+k) s ) > >> > >> When call f3: > >> > >> loopM_ (f3 uu res) 1 1 1000000 > >> > >> Which will have blow profiling output: > >> > >> individual inherited > >> COST CENTRE MODULE no. entries %time %alloc %time %alloc > >> > >> > >> ... > >> loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 > >> f3 Main 113 1000000 1.0 2.0 70.2 69.1 > >> f3.go Main 116 14970034 32.7 67.1 68.8 67.1 > >> f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 > >> f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 > >> f3.f31 Main 114 0 0.3 0.0 0.4 0.0 > >> f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 > >> ... > >> Why f3.go consumes so much space (67.1%)? The only reason I can think of > >> is IO Monad chain (>>) isn't space free as I thought. > >> > >> Did I get something fundamentally wrong? > >> > >> Thanks > >> baojun > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> > > > > -- > -- Dan Burton > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From stefan.reich.maker.of.eye at googlemail.com Fri Jul 3 17:27:42 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Fri, 3 Jul 2015 19:27:42 +0200 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: I see... ok, it's interesting, but seems to require a long time of studying just to understand it. ^^ I am looking for something to solve computer science's complexity problem. I believe we should have simple structures at every level, from high-level to low-level. btw I am redefining the levels like this: Top-level: Your thoughts Medium level: Shortened pseudo-code Low level: A formerly called "high-level" language like Haskell or Java So we're then two levels higher than before. ^^ Cheers On Fri, Jul 3, 2015 at 7:19 PM, Dan Burton wrote: > It can, if you know the correct magic incantations to give ghc (which I > don't, but I know the knowledge is out there). The phrase to Google is > "reading ghc core", where "core" refers to an intermediate language that > still resembles Haskell. > > > On Friday, July 3, 2015, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Here's a general question: Can the output of the Haskell compiler be >> inspected in some - readable - way? >> >> Stefan >> >> On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang wrote: >> >>> Hi, >>> >>> First of all, I found it interesting that >>> >>> loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) >>> >>> loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) >>> >>> I think mapM_ is used very commonly, why it's performance is even lower >>> than a hand-written loop function? >>> >>> 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, >>> it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' >>> updated so that I/O actions can be done in-order? ) >>> >>> Consider below function: >>> >>> f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () >>> f3 u r i = let !v = u ! i >>> in go (f31 v) i i >>> where f31 v j = readArray r j >>= \v1 -> >>> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) >>> f31 :: Int -> Int -> IO () >>> go g k s = when (k <= maxn) ( >>> g k >> go g (s+k) s ) >>> >>> When call f3: >>> >>> loopM_ (f3 uu res) 1 1 1000000 >>> >>> Which will have blow profiling output: >>> >>> individual inherited >>> COST CENTRE MODULE no. entries %time %alloc %time %alloc >>> >>> >>> ... >>> loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 >>> f3 Main 113 1000000 1.0 2.0 70.2 69.1 >>> f3.go Main 116 14970034 32.7 67.1 68.8 67.1 >>> f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 >>> f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 >>> f3.f31 Main 114 0 0.3 0.0 0.4 0.0 >>> f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 >>> ... >>> Why f3.go consumes so much space (67.1%)? The only reason I can think of >>> is IO Monad chain (>>) isn't space free as I thought. >>> >>> Did I get something fundamentally wrong? >>> >>> Thanks >>> baojun >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> > > -- > -- Dan Burton > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangbj at gmail.com Fri Jul 3 18:00:48 2015 From: wangbj at gmail.com (Baojun Wang) Date: Fri, 03 Jul 2015 18:00:48 +0000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: My concerns is ~80% alloc happens in f3, but both array is allocated by newArray? Since I'm using unboxed array I'm not expecting this kind of laziness. And the speed of local go (loopM_ equivalent) > loopM_ > mapM_ really surprised me, even profiling is turned off. On Fri, Jul 3, 2015 at 10:27 AM Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > I see... ok, it's interesting, but seems to require a long time of > studying just to understand it. ^^ > > I am looking for something to solve computer science's complexity problem. > I believe we should have simple structures at every level, from high-level > to low-level. > > btw I am redefining the levels like this: > > Top-level: Your thoughts > Medium level: Shortened pseudo-code > Low level: A formerly called "high-level" language like Haskell or Java > > So we're then two levels higher than before. ^^ > > Cheers > > On Fri, Jul 3, 2015 at 7:19 PM, Dan Burton > wrote: > >> It can, if you know the correct magic incantations to give ghc (which I >> don't, but I know the knowledge is out there). The phrase to Google is >> "reading ghc core", where "core" refers to an intermediate language that >> still resembles Haskell. >> >> >> On Friday, July 3, 2015, Stefan Reich < >> stefan.reich.maker.of.eye at googlemail.com> wrote: >> >>> Here's a general question: Can the output of the Haskell compiler be >>> inspected in some - readable - way? >>> >>> Stefan >>> >>> On Fri, Jul 3, 2015 at 10:18 AM, Baojun Wang wrote: >>> >>>> Hi, >>>> >>>> First of all, I found it interesting that >>>> >>>> loopM_ f k n s = when (k <= n) (f k >> loopM_ f (s+k) n s) >>>> >>>> loopM_ seems faster than mapM_ ( mapM_ f [k, k+s..n])) >>>> >>>> I think mapM_ is used very commonly, why it's performance is even lower >>>> than a hand-written loop function? >>>> >>>> 2nd, even I replace mapM_ with loopM_ from above, when chain IO action, >>>> it still can leak space. ( Because IO Monad (>>) need keep ``RealWorld s'' >>>> updated so that I/O actions can be done in-order? ) >>>> >>>> Consider below function: >>>> >>>> f3 :: UArray Int Int -> IOUArray Int Int64 -> Int -> IO () >>>> f3 u r i = let !v = u ! i >>>> in go (f31 v) i i >>>> where f31 v j = readArray r j >>= \v1 -> >>>> writeArray r j (v1 + (fromIntegral i) * (fromIntegral v)) >>>> f31 :: Int -> Int -> IO () >>>> go g k s = when (k <= maxn) ( >>>> g k >> go g (s+k) s ) >>>> >>>> When call f3: >>>> >>>> loopM_ (f3 uu res) 1 1 1000000 >>>> >>>> Which will have blow profiling output: >>>> >>>> individual inherited >>>> COST CENTRE MODULE no. entries %time %alloc %time %alloc >>>> >>>> >>>> ... >>>> loopM_ Main 104 4000002 7.4 10.1 100.0 99.3 >>>> f3 Main 113 1000000 1.0 2.0 70.2 69.1 >>>> f3.go Main 116 14970034 32.7 67.1 68.8 67.1 >>>> f3.f31 Main 117 13970034 34.5 0.0 36.1 0.0 >>>> f3.f31.\ Main 118 13970034 1.7 0.0 1.7 0.0 >>>> f3.f31 Main 114 0 0.3 0.0 0.4 0.0 >>>> f3.f31.\ Main 115 0 0.1 0.0 0.1 0.0 >>>> ... >>>> Why f3.go consumes so much space (67.1%)? The only reason I can think >>>> of is IO Monad chain (>>) isn't space free as I thought. >>>> >>>> Did I get something fundamentally wrong? >>>> >>>> Thanks >>>> baojun >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> >> -- >> -- Dan Burton >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Jul 3 21:41:45 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 3 Jul 2015 22:41:45 +0100 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: Message-ID: <20150703214145.GG6716@weber> On Fri, Jul 03, 2015 at 06:00:48PM +0000, Baojun Wang wrote: > My concerns is ~80% alloc happens in f3, but both array is allocated by > newArray? Since I'm using unboxed array I'm not expecting this kind of > laziness. I see. You seem to be asking why it is allocating *at all*. That's not a phenomenon that normally falls under the terminology of "space leak", hence my confusion. I'm not an expert at reading Core, but I spent some time looking at it without seeing anywhere that would obviously allocate a lot. Eventually I decided to supply the profiling options to ghc-core and lo and behold the output changed dramatically! Unless I am very much misunderstanding how cost centre annotations work, the amount of allocation without -auto-all is only 10% of the amount with it. Please check and let me know if you concur that it is the profiling itself that is the root cause of all the allocation! Tom From mwm at mired.org Fri Jul 3 23:26:03 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 03 Jul 2015 23:26:03 +0000 Subject: [Haskell-cafe] List-based ini parser? Message-ID: Ok,I've looked at the packages google and hackage found (ini, hsini & ConfigFile), and can't use any of them for dealing with the ini files I'm being handed. The problem is they all parse the config file into Maps, and that doesn't seem to be an option. I need lists, because I have multiple sections with the same name that turn into a list of objects, as well as sections that can have multiple options with the same name that turn into multiple objects. Any chance I overlooked a parser? Or maybe some parsing options in ConfigFile? Any other advice on a library to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sat Jul 4 01:24:27 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 4 Jul 2015 03:24:27 +0200 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: References: Message-ID: <20150704012427.GA4563@casa.casa> On Fri, Jul 03, 2015 at 11:26:03PM +0000, Mike Meyer wrote: > Ok,I've looked at the packages google and hackage found (ini, hsini & > ConfigFile), and can't use any of them for dealing with the ini files I'm > being handed. > > The problem is they all parse the config file into Maps, and that doesn't > seem to be an option. I need lists, because I have multiple sections with > the same name that turn into a list of objects, as well as sections that > can have multiple options with the same name that turn into multiple > objects. > > Any chance I overlooked a parser? Or maybe some parsing options in > ConfigFile? > > Any other advice on a library to do this? Hello Mike, I am pretty sure multiple options with the same name are illegal or undefined behaviour in .ini files, so I wouldn't bet on any of the libraries supporting that. Have you thought writing your own little Parsec parser? Probably not the answer you were wishing for, but you could cannibalise this weirdly written .ini parser [1] and change the upper level functions to suit your needs. From mwm at mired.org Sat Jul 4 01:41:16 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 04 Jul 2015 01:41:16 +0000 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: <20150704012427.GA4563@casa.casa> References: <20150704012427.GA4563@casa.casa> Message-ID: On Fri, Jul 3, 2015 at 8:24 PM Francesco Ariis wrote: > On Fri, Jul 03, 2015 at 11:26:03PM +0000, Mike Meyer wrote: > > Ok,I've looked at the packages google and hackage found (ini, hsini & > > ConfigFile), and can't use any of them for dealing with the ini files I'm > > being handed. > > > > The problem is they all parse the config file into Maps, and that doesn't > > seem to be an option. I need lists, because I have multiple sections with > > the same name that turn into a list of objects, as well as sections that > > can have multiple options with the same name that turn into multiple > > objects. > > > > Any chance I overlooked a parser? Or maybe some parsing options in > > ConfigFile? > > > > Any other advice on a library to do this? > > Hello Mike, > I am pretty sure multiple options with the same name are illegal or > undefined behaviour in .ini files, so I wouldn't bet on any of the > libraries supporting that. > Is there a standard, specification or even some MS document that defines what is and is not legal? I couldn't find one. Nor do I know of any system that uses them for data interchange. Mostly they seem to be read & written solely by the program that uses them for configuration info, and edited by hand, so whatever the program accepts is legal. That's the case for the ones I'm dealing with. Since changing the program format - at least not without writing a converter - isn't an option, even having an ISO standard wouldn't matter. I've gotta deal with what we have, one way or another. Have you thought writing your own little Parsec parser? Probably not > the answer you were wishing for, but you could cannibalise this weirdly > written .ini parser [1] and change the upper level functions to suit > your needs. > Was there a link in there? I didn't see one. And yes, I've thought of writing my own parser for it. I figured I'd make one last check for a library before doing that. Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sat Jul 4 01:45:05 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 4 Jul 2015 03:45:05 +0200 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: References: <20150704012427.GA4563@casa.casa> Message-ID: <20150704014505.GA5620@casa.casa> On Sat, Jul 04, 2015 at 01:41:16AM +0000, Mike Meyer wrote: > Have you thought writing your own little Parsec parser? Probably not > > the answer you were wishing for, but you could cannibalise this weirdly > > written .ini parser [1] and change the upper level functions to suit > > your needs. > > > > Was there a link in there? I didn't see one. And yes, I've thought of > writing my own parser for it. I figured I'd make one last check for a > library before doing that. Meh, silly me, here's the link http://codereview.stackexchange.com/questions/2253/ini-file-parser-in-haskell From wangbj at gmail.com Sat Jul 4 06:17:06 2015 From: wangbj at gmail.com (Baojun Wang) Date: Sat, 04 Jul 2015 06:17:06 +0000 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: <20150703214145.GG6716@weber> References: <20150703214145.GG6716@weber> Message-ID: Appreciate for the prompt reply, sorry for that I assumed the allocations was caused by space leak. I guess profiling with -auto-all really has huge impact on allocations. without profiling, haskell version runs about 50% slower than equivalent C version (both with -O2). Maybe that's as much as one could expect. On Fri, Jul 3, 2015 at 2:41 PM Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Jul 03, 2015 at 06:00:48PM +0000, Baojun Wang wrote: > > My concerns is ~80% alloc happens in f3, but both array is allocated by > > newArray? Since I'm using unboxed array I'm not expecting this kind of > > laziness. > > I see. You seem to be asking why it is allocating *at all*. That's not > a phenomenon that normally falls under the terminology of "space leak", > hence my confusion. > > I'm not an expert at reading Core, but I spent some time looking at it > without seeing anywhere that would obviously allocate a lot. Eventually I > decided to supply the profiling options to ghc-core and lo and behold the > output changed dramatically! > > Unless I am very much misunderstanding how cost centre annotations work, > the > amount of allocation without -auto-all is only 10% of the amount with it. > Please check and let me know if you concur that it is the profiling itself > that is the root cause of all the allocation! > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doaitse at swierstra.net Sat Jul 4 07:37:50 2015 From: doaitse at swierstra.net (S. Doaitse Swierstra) Date: Sat, 4 Jul 2015 09:37:50 +0200 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: References: Message-ID: <39F892D8-7A17-4183-972A-51CAB3EF3C52@swierstra.net> Maybe you can get some inspiration form the uu-options package. It uses the interleaved parsers from uu-parsinglib/uu-interleaved and easily handles options which are ?distributed? over a several individual entries. It is directed towards command line options, but changing it so it works for similar formats should not be a problem. The included Demo file shows its capabilities, and the error messages you get in case the input is incorrect. Note how the various integers are collected automatically, and how the order of the fileds in the input does not matter either, Doaitse data Prefers = Agda | Haskell deriving Show <> <>data Address = Address { city_ :: String <> , street_ :: String} <> deriving Show <> <>data Name = Name { name_:: String <> , prefers_:: Prefers <> , ints_ :: [Int] <> , address_ :: Address} <> deriving Show <> <>$(deriveLenses ''Name) <>$(deriveLenses ''Address) <> <> <>instance ShowParserType Prefers where <> showType p = " " <> <> <>-- The next thing to do is to specify a initial record containing the default values: <>defaults = Name "Atze" Haskell [] <> (Address "Utrecht" <> "Princetonplein") <> <>-- Next we define the parser for the options, by specifying for each field what may be specified: <> <> <>oName = <> name `option` ("name", pString, "Name") <> <> ints `options` ("ints", pNaturalRaw, "A couple of numbers") <> <> prefers `choose` [("agda", Agda, "in case you prefer Agda") <> ,("haskell", Haskell, "in case you prefer Haskell") <> ] <> <> address `field` <> ( city `option` ("city", pString, "Home city") <> <> street `option` ("street" ,pString, "Home Street" ) <> ) <>{- <>-- | The function `main` may serve as a template for your own option handling. You can also use this module to see what the effectis of the various ways of passing options <>-- >>> ./Demo -i1 --ints 2 --street=Zandlust -a -nDoaitse -i3 --ints=4 --city=Tynaarlo <>-- Name {name_ = "Doaitse", prefers_ = Agda, ints_ = [1,2,3,4], address_ = Address {city_ = "Tynaarlo", street_ = "Zandlust"}} <>-- <>-- >>> ./Demo -i1 --ints 2 --street=Zandlust --name Doaitse -i3 --ints=4 --city=Tynaarlo <>-- --name [Char] optional Name <>-- --ints Int recurring A couple of numbers <>-- Choose at least one from( <>-- --agda required In case you prefer Agda <>-- --haskell required In case you prefer Haskell <>-- ) <>-- --city [Char] optional Home city <>-- --street [Char] optional Home Street <>-- -- <>-- -- Correcting steps: <>-- -- Inserted "-a" at position 70 expecting one of ["--agda", "--agda=", "--haskell", "--haskell=", "--ints=", "--ints", "-i", "-h", "-a"] <>-- -- Inserted "\EOT" at position 70 expecting "\EOT" <> <> <>main ::IO () <>main = do args <- getArgs <> case run defaults oName (concat (map (++ "\EOT") args)) of <> Left a -> case a of <> Succes v -> print v <> Help t -> putStrLn t <> Right errors -> putStrLn errors <> <>-- | The function `demo` can be used from within ghci: <>-} <> <>-- >>> demo ["-i2", "--street=Zandlust", "--ints=5", "-nAtze", "--city=Houten", "--agda", "-i3"] <>-- Name {name_ = "Atze", prefers_ = Agda, ints_ = [2,5,3], address_ = Address {city_ = "Houten", street_ = "Zandlust"}} <> <> <>demo :: [[Char]] -> IO () <>demo args = case run defaults oName (concat (map (++ "\EOT") args)) of <> Left a -> case a of <> Succes v -> print v <> Help t -> putStrLn t <> Right errors -> putStr errors > On 04 Jul 2015, at 1:26 , Mike Meyer wrote: > > Ok,I've looked at the packages google and hackage found (ini, hsini & ConfigFile), and can't use any of them for dealing with the ini files I'm being handed. > > The problem is they all parse the config file into Maps, and that doesn't seem to be an option. I need lists, because I have multiple sections with the same name that turn into a list of objects, as well as sections that can have multiple options with the same name that turn into multiple objects. > > Any chance I overlooked a parser? Or maybe some parsing options in ConfigFile? > > Any other advice on a library to do this? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sat Jul 4 13:08:53 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 04 Jul 2015 15:08:53 +0200 Subject: [Haskell-cafe] Efficient records with arbitrarily many fields [was: Extensible states] References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Marcin Mrotek wrote: > Okay, perhaps I'm too newbie to understand the big picture, but it > seems to me you can get either: > > a) O(1) access to any, arbitrarily selected (at runtime) field > b) O(1) append > > I guess option a) is better performance-wise, as appending is usually > done less often than selecting (an O(1) slice is already possible with > independently typed regular Haskell records) but > dependently-typed-list-based implementation, or at the very least > Vinyl (I haven't ever used HList) has the advantage of being dead > simple in both implementation and usage. I mean, with Vinyl, you can > write manual recursion over Rec's like: > > foo :: Rec ... -> Rec ... > foo RNil = ... > foo (r :& rs) = ... > > whenever GHC's typechecker gives up and goes on a strike; and I dare > to say, with commonly used record sizes (have you ever used a record > with more than, let's say, 10 fields?) the speed tradeoff is not > noticeable. While more than 10 fields in a record is uncommon for typical library APIs and simple programs, real world projects can grow much larger records. One example is configuration data for complex programs (like Darcs or even GHC) with many options. It would be so nice if we could use record types for the configuration! Another application could in control system toolkits like EPICS [1], which currently has (actually: generates) C records with potentially hundreds of fields. If lookup is / remains linear we can never efficiently support these kinds of applications and that would be very sad. I think the most reasonable default is O(1) for lookup and O(n) for extension, like in Nikita Volkov's record package. It is quite unfortunate that this package limits the number of fields! If GHC would offer generic support for tuples of arbitrary size (with the same efficiency as today) this limitation could be avoided and all would be well. Cheers Ben [1] http://www.aps.anl.gov/epics/ -- "Make it so they have to reboot after every typo." ? Scott Adams From ben.franksen at online.de Sat Jul 4 13:38:04 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 04 Jul 2015 15:38:04 +0200 Subject: [Haskell-cafe] MVars and locks References: <20150506191904.GC19164@weber> Message-ID: Tom Ellis wrote: > In the following section of the book "Parallel and Concurrent Programming > in Haskell" > > http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook > > Simon Marlow explains that MVars can be used to implement something like > locks on shared functional state: "To acquire the lock, we take the MVar, > whereas, to update the variable and release the lock, we put the MVar." > > Am I right in thinking this only holds if we are careful to ensure both > those operations happen in the given order? > > For example, if I take the MVar (lock) and I am about to put something > back in (unlock) but someone else puts something in before I do, then the > lock > system becomes broken, doesn't it? So if we want to be sure we have a > robust lock system we have to wrap up MVars in another abstraction? You are absolutely right. It's exactly the same as with the more traditional semaphores, i.e. locking happens if and only if all involved parties adhere to the protocol (take lock; do something; give lock). It is usually best to enforce adherence to the protocol on the module level by not exporting anything that exposes the MVar itself (and using bracket or, even better, withMVar or modifyMVar internally). Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams From nukasu.kanaka at gmail.com Sat Jul 4 13:45:27 2015 From: nukasu.kanaka at gmail.com (Nikita Volkov) Date: Sat, 4 Jul 2015 16:45:27 +0300 Subject: [Haskell-cafe] Efficient records with arbitrarily many fields [was: Extensible states] In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: I somehow missed the preceding discussion, so I'll comment on what I've seen so far. > I think the most reasonable default is O(1) for lookup and O(n) for > extension, like in Nikita Volkov's record package. It is quite unfortunate > that this package limits the number of fields! If GHC would offer generic > support for tuples of arbitrary size (with the same efficiency as today) > this limitation could be avoided and all would be well. Currently "record" is limited to up to 24 fields. However it was just an arbitrary number that I've chosen. No part of GHC limits us to that number. The only reason I'm not introducing bigger arities is that unfortunately the compilation time of the "record" library grows exponentially in relation to the highest arity supported. I expect, that limitation could be lifted once/if the ideas behind the library get implemented as an extension to GHC. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Sat Jul 4 13:54:30 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sat, 4 Jul 2015 16:54:30 +0300 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: (forgot to reply to cafe list Hi. You can take a look at vector-fixed-hetero [1], that can act as anonymous structure with arbitrary number of fields, convertion to and from datatypes with the same structure and many more features. It's missing field names though and syntactic sugar that 'records' package have. If you like to reinvent a wheel, then you can use following appoach: introduce some typelevel info data a :? (b :: Symbol) data FieldName (t :: Symbol) = FieldName introduce generic structure for records with any number of fiels newtype ARec (m :: [*]) = ARec { unRec :: Array Any } type instance TProxy (ARec m) = m type instance VProxy (ARec m) = ARec rerec :: ARec a -> ARec b rerec = ARec . unRec indexRec :: (KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> ARec m -> a indexRec name v = unsafeCoerce $ indexArray (unRec v) (fromIntegral (natVal (indexProxy name v))) updateRec :: (KnownNat (Length m), KnownNat (FieldIndex name m), FieldType name m ~ a) => proxy name -> a -> ARec m -> ARec m updateRec name b v = runST $ do out <- newArray len undefined copyArray out 0 (unRec v) 0 len writeArray out idx (unsafeCoerce b) ARec <$> unsafeFreezeArray out where idx = fromIntegral (natVal (indexProxy name v)) len = fromIntegral (natVal (lengthProxy v)) you'll need some typelevel magic for that: type family FieldType (n :: Symbol) m where FieldType n ((a :? n) ': z) = a FieldType n (b ': z) = FieldType n z type family FieldIndex (n::Symbol) m :: Nat where FieldIndex n ((a :? n) ': z) = 0 FieldIndex n ( b ': z) = 1 + FieldIndex n z indexProxy :: (KnownNat c, FieldIndex n m ~ c) => proxy1 n -> proxy2 m -> Proxy c indexProxy _ _ = Proxy type family Length m where Length '[] = 0 Length (x ': xs) = 1 + Length xs lengthProxy :: (KnownNat c, Length n ~ c) => proxy n -> Proxy c lengthProxy _ = Proxy then you can implement lenses: instance (KnownNat (FieldIndex n m), KnownNat (Length m), FieldType n m ~ a) => HasField (n :: Symbol) (ARec m) a where getField = indexRec updateField p = flip (updateRec p) fieldLens' :: (HasField name z a, FieldType name (TProxy z) ~ a) => FieldName name -> Lens z z a a fieldLens' name = \f m -> fmap (updateField name m) (f $ getField name m) type family UpdateType (n :: Symbol) z a b where UpdateType n ((a :? n) ': z ) a b = (b :? n) ': z UpdateType n ( z ': zs) a b = z ': UpdateType n zs a b fieldLens :: ( ARec m ~ z, ARec m' ~ z', m' ~ UpdateType name m a b , FieldType name m ~ a, FieldType name m' ~ b , KnownNat (FieldIndex name m), KnownNat (FieldIndex name m') , KnownNat (Length m), KnownNat (Length m') ) => FieldName name -> Lens z z' a b fieldLens name = \f m -> fmap (updateField name (rerec m)) (f $ getField name m) this approach is more or less the same as records package with only one datastructure and almost the same syntactic sugar can be applied, the only missing thing is that pattern matching will be more difficult that with records. At this point it's not possible to write strict fields, but it can be easily extended. If someone is interested in this sort of wheel, I can prepare a package and some docs about and with coercion with other solutions like fixed-vector-hetero and records. [1] https://hackage.haskell.org/package/fixed-vector-hetero On Sat, Jul 4, 2015, 16:08 Ben Franksen wrote: > > Marcin Mrotek wrote: > > Okay, perhaps I'm too newbie to understand the big picture, but it > > seems to me you can get either: > > > > a) O(1) access to any, arbitrarily selected (at runtime) field > > b) O(1) append > > > > I guess option a) is better performance-wise, as appending is usually > > done less often than selecting (an O(1) slice is already possible with > > independently typed regular Haskell records) but > > dependently-typed-list-based implementation, or at the very least > > Vinyl (I haven't ever used HList) has the advantage of being dead > > simple in both implementation and usage. I mean, with Vinyl, you can > > write manual recursion over Rec's like: > > > > foo :: Rec ... -> Rec ... > > foo RNil = ... > > foo (r :& rs) = ... > > > > whenever GHC's typechecker gives up and goes on a strike; and I dare > > to say, with commonly used record sizes (have you ever used a record > > with more than, let's say, 10 fields?) the speed tradeoff is not > > noticeable. > > While more than 10 fields in a record is uncommon for typical library APIs > and simple programs, real world projects can grow much larger records. One > example is configuration data for complex programs (like Darcs or even GHC) > with many options. It would be so nice if we could use record types for the > configuration! Another application could in control system toolkits like > EPICS [1], which currently has (actually: generates) C records with > potentially hundreds of fields. > > If lookup is / remains linear we can never efficiently support these kinds > of applications and that would be very sad. > > I think the most reasonable default is O(1) for lookup and O(n) for > extension, like in Nikita Volkov's record package. It is quite unfortunate > that this package limits the number of fields! If GHC would offer generic > support for tuples of arbitrary size (with the same efficiency as today) > this limitation could be avoided and all would be well. > > Cheers > Ben > > [1] http://www.aps.anl.gov/epics/ > -- > "Make it so they have to reboot after every typo." ? Scott Adams > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alexander From ben.franksen at online.de Sat Jul 4 14:13:01 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 04 Jul 2015 16:13:01 +0200 Subject: [Haskell-cafe] Efficient records with arbitrarily many fields [was: Extensible states] References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Nikita Volkov wrote: > I somehow missed the preceding discussion, so I'll comment on what I've > seen so far. > >> I think the most reasonable default is O(1) for lookup and O(n) for >> extension, like in Nikita Volkov's record package. It is quite >> unfortunate that this package limits the number of fields! If GHC would >> offer generic support for tuples of arbitrary size (with the same >> efficiency as today) this limitation could be avoided and all would be >> well. > > > Currently "record" is limited to up to 24 fields. However it was just an > arbitrary number that I've chosen. No part of GHC limits us to that > number. > The only reason I'm not introducing bigger arities is that > unfortunately the compilation time of the "record" library grows > exponentially in relation to the highest arity supported. I expect, that > limitation could be lifted once/if the ideas behind the library get > implemented as an extension to GHC. Thanks for the clarification. So there is no hard limit in GHC, but we are (currently) limited by other factors. Some (more or less) minimal compiler support is, I guess, necessary to make any of the existing record libraries practical for real world programs. Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams From ben.franksen at online.de Sat Jul 4 14:19:17 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sat, 04 Jul 2015 16:19:17 +0200 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Thanks, I didn't know of vector-fixed-hetero. Quite interesting. Anyway, I am not so much interested in getting reasonable efficiency from any of the existing libraries right now, as I am in reaching consensus about what kind of compiler support would be needed to make any of them practical. Cheers Ben Alexander V Vershilov wrote: > (forgot to reply to cafe list > Hi. > > You can take a look at vector-fixed-hetero [1], > that can act as anonymous structure with arbitrary number of fields, > convertion to and from > > datatypes with the same structure and many more features. It's missing > field names though > and syntactic sugar that 'records' package have. If you like to > reinvent a wheel, then > > you can use following appoach: > > introduce some typelevel info > > data a :? (b :: Symbol) > > data FieldName (t :: Symbol) = FieldName > > introduce generic structure for records with any number of fiels > > newtype ARec (m :: [*]) = ARec { unRec :: Array Any } > type instance TProxy (ARec m) = m > type instance VProxy (ARec m) = ARec > > rerec :: ARec a -> ARec b > rerec = ARec . unRec > > indexRec :: (KnownNat (FieldIndex name m), FieldType name m ~ a) > => proxy name -> ARec m -> a > indexRec name v = unsafeCoerce $ > indexArray (unRec v) (fromIntegral (natVal (indexProxy name v))) > > updateRec :: (KnownNat (Length m), KnownNat (FieldIndex name m), > FieldType name m ~ a) > => proxy name -> a -> ARec m -> ARec m > updateRec name b v = runST $ do > out <- newArray len undefined > copyArray out 0 (unRec v) 0 len > writeArray out idx (unsafeCoerce b) > ARec <$> unsafeFreezeArray out > where > idx = fromIntegral (natVal (indexProxy name v)) > len = fromIntegral (natVal (lengthProxy v)) > > you'll need some typelevel magic for that: > type family FieldType (n :: Symbol) m where > FieldType n ((a :? n) ': z) = a > FieldType n (b ': z) = FieldType n z > > type family FieldIndex (n::Symbol) m :: Nat where > FieldIndex n ((a :? n) ': z) = 0 > FieldIndex n ( b ': z) = 1 + FieldIndex n z > > indexProxy :: (KnownNat c, FieldIndex n m ~ c) => proxy1 n -> proxy2 m > -> Proxy c > indexProxy _ _ = Proxy > > type family Length m where > Length '[] = 0 > Length (x ': xs) = 1 + Length xs > > lengthProxy :: (KnownNat c, Length n ~ c) => proxy n -> Proxy c > lengthProxy _ = Proxy > > then you can implement lenses: > > instance (KnownNat (FieldIndex n m), KnownNat (Length m), FieldType n m ~ > a) > => HasField (n :: Symbol) (ARec m) a where > getField = indexRec > updateField p = flip (updateRec p) > > > fieldLens' :: (HasField name z a, FieldType name (TProxy z) ~ a) > => FieldName name -> Lens z z a a > fieldLens' name = \f m -> fmap (updateField name m) > (f $ getField name m) > > > type family UpdateType (n :: Symbol) z a b where > UpdateType n ((a :? n) ': z ) a b = (b :? n) ': z > UpdateType n ( z ': zs) a b = z ': UpdateType n zs a b > > fieldLens :: ( ARec m ~ z, ARec m' ~ z', m' ~ UpdateType name m a b > , FieldType name m ~ a, FieldType name m' ~ b > , KnownNat (FieldIndex name m), KnownNat (FieldIndex name m') > , KnownNat (Length m), KnownNat (Length m') > ) => FieldName name -> Lens z z' a b > fieldLens name = \f m -> fmap (updateField name (rerec m)) > (f $ getField name m) > > this approach is more or less the same as records package with only one > datastructure and almost the same syntactic sugar can be applied, the > > only missing thing is that pattern matching will be more difficult that > with > > records. > > At this point it's not possible to write strict fields, but it can be > easily extended. > > If someone is interested in this sort of wheel, I can prepare a package > and some > > docs about and with coercion with other solutions like > fixed-vector-hetero and records. > > > > [1] https://hackage.haskell.org/package/fixed-vector-hetero > > > On Sat, Jul 4, 2015, 16:08 Ben Franksen wrote: >> >> Marcin Mrotek wrote: >> > Okay, perhaps I'm too newbie to understand the big picture, but it >> > seems to me you can get either: >> > >> > a) O(1) access to any, arbitrarily selected (at runtime) field >> > b) O(1) append >> > >> > I guess option a) is better performance-wise, as appending is usually >> > done less often than selecting (an O(1) slice is already possible with >> > independently typed regular Haskell records) but >> > dependently-typed-list-based implementation, or at the very least >> > Vinyl (I haven't ever used HList) has the advantage of being dead >> > simple in both implementation and usage. I mean, with Vinyl, you can >> > write manual recursion over Rec's like: >> > >> > foo :: Rec ... -> Rec ... >> > foo RNil = ... >> > foo (r :& rs) = ... >> > >> > whenever GHC's typechecker gives up and goes on a strike; and I dare >> > to say, with commonly used record sizes (have you ever used a record >> > with more than, let's say, 10 fields?) the speed tradeoff is not >> > noticeable. >> >> While more than 10 fields in a record is uncommon for typical library >> APIs and simple programs, real world projects can grow much larger >> records. One example is configuration data for complex programs (like >> Darcs or even GHC) with many options. It would be so nice if we could use >> record types for the configuration! Another application could in control >> system toolkits like EPICS [1], which currently has (actually: generates) >> C records with potentially hundreds of fields. >> >> If lookup is / remains linear we can never efficiently support these >> kinds of applications and that would be very sad. >> >> I think the most reasonable default is O(1) for lookup and O(n) for >> extension, like in Nikita Volkov's record package. It is quite >> unfortunate that this package limits the number of fields! If GHC would >> offer generic support for tuples of arbitrary size (with the same >> efficiency as today) this limitation could be avoided and all would be >> well. >> >> Cheers >> Ben >> >> [1] http://www.aps.anl.gov/epics/ >> -- >> "Make it so they have to reboot after every typo." ? Scott Adams >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- "Make it so they have to reboot after every typo." ? Scott Adams From magnus at therning.org Sat Jul 4 16:33:36 2015 From: magnus at therning.org (Magnus Therning) Date: Sat, 4 Jul 2015 18:33:36 +0200 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: References: Message-ID: <20150704163336.GA4116@tatooine> On Fri, Jul 03, 2015 at 11:26:03PM +0000, Mike Meyer wrote: > Ok,I've looked at the packages google and hackage found (ini, hsini & > ConfigFile), and can't use any of them for dealing with the ini files I'm > being handed. > > The problem is they all parse the config file into Maps, and that doesn't > seem to be an option. I need lists, because I have multiple sections with > the same name that turn into a list of objects, as well as sections that > can have multiple options with the same name that turn into multiple > objects. > > Any chance I overlooked a parser? Or maybe some parsing options in > ConfigFile? > > Any other advice on a library to do this? As the author of `hsini` I wouldn't mind if you created a bug report, explain the format you have (ideally you attach an example). Of course I can't promise any ETA, or even that it'll ever be done (you know how it's with FLOSS). I've pretty much used the "standard" described in the [INI article on Wikpedia](https://en.wikipedia.org/wiki/INI_file) and then picked the pieces I think make sense and have use for myself. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus Finagle's Fourth Law: Once a job is fouled up, anything done to improve it only makes it worse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From mwm at mired.org Sat Jul 4 17:23:52 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 04 Jul 2015 17:23:52 +0000 Subject: [Haskell-cafe] List-based ini parser? In-Reply-To: <20150704163336.GA4116@tatooine> References: <20150704163336.GA4116@tatooine> Message-ID: Done. See https://github.com/magthe/hsini/issues/16 for the issue about duplicate names, including a sample ini file. I've also opened https://github.com/magthe/hsini/issues/17 about spaces in option names. I didn't try section names, but I've seen them with spaces in them as well, where they were used for creating GUI elements. The wiki entry does mention the use of duplicate names for creating multi-valued options. It also mentioned duplicate section names, but not the specific use I'm dealing with. I suspect fixing this in any of the current packages would require a fundamental rewrite of the packages I've looked at, as they all store options as Maps to string values, and sections as Maps to option value maps. They either need to store lists instead of maps, or use maps to polymorphic values. For the record, I also created an issue for the in package https://github.com/chrisdone/ini/issues/6, as it just hands back an empty config structure for the example file. Values outside of sections aren't handled. On Sat, Jul 4, 2015 at 11:33 AM Magnus Therning wrote: > On Fri, Jul 03, 2015 at 11:26:03PM +0000, Mike Meyer wrote: > > Ok,I've looked at the packages google and hackage found (ini, hsini & > > ConfigFile), and can't use any of them for dealing with the ini files I'm > > being handed. > > > > The problem is they all parse the config file into Maps, and that doesn't > > seem to be an option. I need lists, because I have multiple sections with > > the same name that turn into a list of objects, as well as sections that > > can have multiple options with the same name that turn into multiple > > objects. > > > > Any chance I overlooked a parser? Or maybe some parsing options in > > ConfigFile? > > > > Any other advice on a library to do this? > > As the author of `hsini` I wouldn't mind if you created a bug report, > explain the format you have (ideally you attach an example). > > Of course I can't promise any ETA, or even that it'll ever be done > (you know how it's with FLOSS). > > I've pretty much used the "standard" described in the [INI article on > Wikpedia](https://en.wikipedia.org/wiki/INI_file) and then picked the > pieces I think make sense and have use for myself. > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: magnus at therning.org jabber: magnus at therning.org > twitter: magthe http://therning.org/magnus > > Finagle's Fourth Law: > Once a job is fouled up, anything done to improve it only makes it > worse. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Sat Jul 4 19:45:48 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sat, 4 Jul 2015 22:45:48 +0300 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Not sure that it will make sense for a cafe level, but here is my understanding of the current state. For the problem of "anonymous records", i.e. some datatype that may have different fields and their types we have following appoaches: 1. vinyl/hlist/etc. i.e. GADT base heterogeneous list. This one have O(N) random access and may not be a good fit for "anonymous record" use case 2. records: polymorphic data structures with type-level information about field names. Here we have a lot of datastructures one per number of fields multiply on 2 (lazy and strict variant). This one has O(1) random access. 3. fixed-vector-hetero/"wheel above". array based structures has O(1) access. I call code above a "wheel" because there were a number of similar implementations here and there. I'm not the author or contributor of any libraries above, so I may miss something, but here is my view: (let's not take a hlist into the scope, because it should be used in different scenarios). record provides a good approach + nice syntactic sugar (based on TH or preprocessor or possibly compiler). The downside here is that we have O(N) internal structures and exponential number of instances. You could take a look at records haddock page, use 10% zoom for the best feeling :). array-based approach have only one structure and 1 instance for any number of fields, and this is a benefit. But there is a cost as records could be used even without syntactic sugar (e.g. pattern matching), and with fixed vector it will be a bit tricker (if possible), for example my approach above as it stands will not be usable without syntactic sugar similar to the records one. There is one more problem, library heavily uses `unsafeCoerce` so it should be a part of the trusted base, of cause this is totally safe as typechecker checks that, nevertheless it may be a concern for the users. my wheel could reuse fixed-vector-hetero, as this is basically tagged structure over fixed vector, I have not reused that because of 2 reasons: 1. I have not found a nice way to update fields in immutable vector (maybe I just missed that part of API) 2. I don't see a nice way to give user a choice to make fields strict, and in a wheel it's possible to introduce another typelevel variable that will be used as a strictness marker, and lens that we build will appreciate that. Btw, here we may have a solution that is better that "all-or-nothing" one in the records package. this solution may well cope with solution for "overloaded records" that is worked on. 3. If fixed-vector will not be reused it's possible to convert structure in O(1). Anyway records have all required tooling around it, and seems like a best solution in this (anonymous records with O(1) field access) area at least for now. -- Alexander On 4 July 2015 at 17:19, Ben Franksen wrote: > Thanks, I didn't know of vector-fixed-hetero. Quite interesting. > > Anyway, I am not so much interested in getting reasonable efficiency from > any of the existing libraries right now, as I am in reaching consensus about > what kind of compiler support would be needed to make any of them practical. > > Cheers > Ben > > Alexander V Vershilov wrote: >> (forgot to reply to cafe list >> Hi. >> >> You can take a look at vector-fixed-hetero [1], >> that can act as anonymous structure with arbitrary number of fields, >> convertion to and from >> >> datatypes with the same structure and many more features. It's missing >> field names though >> and syntactic sugar that 'records' package have. If you like to >> reinvent a wheel, then >> >> you can use following appoach: >> >> introduce some typelevel info >> >> data a :? (b :: Symbol) >> >> data FieldName (t :: Symbol) = FieldName >> >> introduce generic structure for records with any number of fiels >> >> newtype ARec (m :: [*]) = ARec { unRec :: Array Any } >> type instance TProxy (ARec m) = m >> type instance VProxy (ARec m) = ARec >> >> rerec :: ARec a -> ARec b >> rerec = ARec . unRec >> >> indexRec :: (KnownNat (FieldIndex name m), FieldType name m ~ a) >> => proxy name -> ARec m -> a >> indexRec name v = unsafeCoerce $ >> indexArray (unRec v) (fromIntegral (natVal (indexProxy name v))) >> >> updateRec :: (KnownNat (Length m), KnownNat (FieldIndex name m), >> FieldType name m ~ a) >> => proxy name -> a -> ARec m -> ARec m >> updateRec name b v = runST $ do >> out <- newArray len undefined >> copyArray out 0 (unRec v) 0 len >> writeArray out idx (unsafeCoerce b) >> ARec <$> unsafeFreezeArray out >> where >> idx = fromIntegral (natVal (indexProxy name v)) >> len = fromIntegral (natVal (lengthProxy v)) >> >> you'll need some typelevel magic for that: >> type family FieldType (n :: Symbol) m where >> FieldType n ((a :? n) ': z) = a >> FieldType n (b ': z) = FieldType n z >> >> type family FieldIndex (n::Symbol) m :: Nat where >> FieldIndex n ((a :? n) ': z) = 0 >> FieldIndex n ( b ': z) = 1 + FieldIndex n z >> >> indexProxy :: (KnownNat c, FieldIndex n m ~ c) => proxy1 n -> proxy2 m >> -> Proxy c >> indexProxy _ _ = Proxy >> >> type family Length m where >> Length '[] = 0 >> Length (x ': xs) = 1 + Length xs >> >> lengthProxy :: (KnownNat c, Length n ~ c) => proxy n -> Proxy c >> lengthProxy _ = Proxy >> >> then you can implement lenses: >> >> instance (KnownNat (FieldIndex n m), KnownNat (Length m), FieldType n m ~ >> a) >> => HasField (n :: Symbol) (ARec m) a where >> getField = indexRec >> updateField p = flip (updateRec p) >> >> >> fieldLens' :: (HasField name z a, FieldType name (TProxy z) ~ a) >> => FieldName name -> Lens z z a a >> fieldLens' name = \f m -> fmap (updateField name m) >> (f $ getField name m) >> >> >> type family UpdateType (n :: Symbol) z a b where >> UpdateType n ((a :? n) ': z ) a b = (b :? n) ': z >> UpdateType n ( z ': zs) a b = z ': UpdateType n zs a b >> >> fieldLens :: ( ARec m ~ z, ARec m' ~ z', m' ~ UpdateType name m a b >> , FieldType name m ~ a, FieldType name m' ~ b >> , KnownNat (FieldIndex name m), KnownNat (FieldIndex name m') >> , KnownNat (Length m), KnownNat (Length m') >> ) => FieldName name -> Lens z z' a b >> fieldLens name = \f m -> fmap (updateField name (rerec m)) >> (f $ getField name m) >> >> this approach is more or less the same as records package with only one >> datastructure and almost the same syntactic sugar can be applied, the >> >> only missing thing is that pattern matching will be more difficult that >> with >> >> records. >> >> At this point it's not possible to write strict fields, but it can be >> easily extended. >> >> If someone is interested in this sort of wheel, I can prepare a package >> and some >> >> docs about and with coercion with other solutions like >> fixed-vector-hetero and records. >> >> >> >> [1] https://hackage.haskell.org/package/fixed-vector-hetero >> >> >> On Sat, Jul 4, 2015, 16:08 Ben Franksen wrote: >>> >>> Marcin Mrotek wrote: >>> > Okay, perhaps I'm too newbie to understand the big picture, but it >>> > seems to me you can get either: >>> > >>> > a) O(1) access to any, arbitrarily selected (at runtime) field >>> > b) O(1) append >>> > >>> > I guess option a) is better performance-wise, as appending is usually >>> > done less often than selecting (an O(1) slice is already possible with >>> > independently typed regular Haskell records) but >>> > dependently-typed-list-based implementation, or at the very least >>> > Vinyl (I haven't ever used HList) has the advantage of being dead >>> > simple in both implementation and usage. I mean, with Vinyl, you can >>> > write manual recursion over Rec's like: >>> > >>> > foo :: Rec ... -> Rec ... >>> > foo RNil = ... >>> > foo (r :& rs) = ... >>> > >>> > whenever GHC's typechecker gives up and goes on a strike; and I dare >>> > to say, with commonly used record sizes (have you ever used a record >>> > with more than, let's say, 10 fields?) the speed tradeoff is not >>> > noticeable. >>> >>> While more than 10 fields in a record is uncommon for typical library >>> APIs and simple programs, real world projects can grow much larger >>> records. One example is configuration data for complex programs (like >>> Darcs or even GHC) with many options. It would be so nice if we could use >>> record types for the configuration! Another application could in control >>> system toolkits like EPICS [1], which currently has (actually: generates) >>> C records with potentially hundreds of fields. >>> >>> If lookup is / remains linear we can never efficiently support these >>> kinds of applications and that would be very sad. >>> >>> I think the most reasonable default is O(1) for lookup and O(n) for >>> extension, like in Nikita Volkov's record package. It is quite >>> unfortunate that this package limits the number of fields! If GHC would >>> offer generic support for tuples of arbitrary size (with the same >>> efficiency as today) this limitation could be avoided and all would be >>> well. >>> >>> Cheers >>> Ben >>> >>> [1] http://www.aps.anl.gov/epics/ >>> -- >>> "Make it so they have to reboot after every typo." ? Scott Adams >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -- > "Make it so they have to reboot after every typo." ? Scott Adams > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alexander From capn.freako at gmail.com Sun Jul 5 15:52:37 2015 From: capn.freako at gmail.com (David Banas) Date: Sun, 5 Jul 2015 08:52:37 -0700 Subject: [Haskell-cafe] Posted code snippet for Ex. 12 of Ch. 5 of "Fun w/ Phantom Types". Message-ID: Hi all, I?ve spent the last few days working on Exercise 12, at the end of Chapter 5 of Ralf Hinze?s paper, ?Fun with Phantom Types?. (Thanks, Conal, for all the help!) I thought I?d share my code, in case anyone else happens to be in the same Haskell space-time as me, right now. :) https://github.com/capn-freako/Haskell_Misc/blob/master/norm_by_eval.hs I hope everyone is enjoying their weekend. Cheers, -db From silvio.frischi at gmail.com Sun Jul 5 20:54:43 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sun, 05 Jul 2015 22:54:43 +0200 Subject: [Haskell-cafe] stm onCommit Message-ID: <55999993.1030106@gmail.com> I need a onCommit functionality for stm. I know there is the stm-io-hooks [1] package. But it seems so big for such a small thing and then I have to translate everything to their monad. lift lift lift ... So I thought of a little hack to solve the issue and I'm wondering if this is safe to use. My understanding of stm internals is very limited. It's basically just a TChan with IO actions in it and there is another thread waiting to execute anything inserted into it. import Control.Concurrent.STM.TChan onCommitChan :: TChan (IO ()) {-# NOINLINE onCommit #-} onCommitChan = unsafePerformIO $ do chan <- newTChanIO forkIO $ forever $ atomically $ readTChan chan return chan onCommit :: IO () -> STM () onCommit = writeTChan onCommitChan It would be cool if an onCommit hook could be directly added to the stm package. Silvio [1] https://hackage.haskell.org/package/stm-io-hooks-1.0.1 From silvio.frischi at gmail.com Sun Jul 5 21:07:21 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sun, 05 Jul 2015 23:07:21 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: Message-ID: <55999C89.6040502@gmail.com> > add :: LabelName -> a -> State () > gets :: LabelName -> State (Maybe a) I think that's more or less what STRef does. No extendable records though. Cheers Silvio From silvio.frischi at gmail.com Sun Jul 5 21:33:05 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Sun, 05 Jul 2015 23:33:05 +0200 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <55999993.1030106@gmail.com> References: <55999993.1030106@gmail.com> Message-ID: <5599A291.10600@gmail.com> Sorry the line with fork in it should have been forkIO $ forever $ join $ atomically $ readTChan chan of course. Silvio From marcin.jan.mrotek at gmail.com Sun Jul 5 21:49:57 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Sun, 5 Jul 2015 23:49:57 +0200 Subject: [Haskell-cafe] ANN: zoom-refs - zoom and pairing for mutable references Message-ID: Hello, I've just uploaded my package zoom-refs: http://hackage.haskell.org/package/zoom-refs-0.0.0.0 It's a "port" of State monad zoom (from lens) to mutable references: zoomTVar :: Lens' a b -> TVar a -> TVar b These TVars aren't actually the raw TVars from STM, but wrappers that provide the same functionality. Similar functions are provided for STRefs and IORefs. Additionally, TVars and STRefs can be paired to create composite references: pairTVars :: TVar a -> TVar b -> TVar (a,b) No such functionality is provided for IORefs, as there would be no way to guarantee atomicity of operations on the underlying references. Together. mutable references can be used sort of like Functors and Applicatives, though one needs to use lenses rather than plain functons to map them. Finally, there are multiple references that use traversals instead of lenses to zoom: readMultiTVar :: Monoid a -> MultiTVar a -> STM a readMultiTVarList :: MultiTVar a -> STM [a] readMultiTVarHead :: MultiTVar a -> STM (Maybe a) Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Jul 5 22:33:33 2015 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 06 Jul 2015 00:33:33 +0200 Subject: [Haskell-cafe] Symmetric Difference for Data.Set and Data.IntSet? References: Message-ID: Zemyla wrote: > Could this be implemented as a primitive? I know it can be made from union > and difference, or doing toList on both of them, taking the symmetric > difference, and using fromDistinctAscList on the result, but it'd probably > be much faster if it could be done natively, like can be done with > Data.Map.mergeWithKey. +1 > Alternatively, could we get a merge interface for Set and IntSet roughly > matching Map and IntMap? -- "Make it so they have to reboot after every typo." ? Scott Adams From manny at fpcomplete.com Sun Jul 5 23:19:39 2015 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Sun, 5 Jul 2015 16:19:39 -0700 Subject: [Haskell-cafe] ANN: stack-0.1.2.0 Message-ID: New release of stack, a build tool. Changes: https://github.com/commercialhaskell/stack/releases/tag/v0.1.2.0 General information and download links (now with package repositories for CentOS, Fedora, and Debian): https://github.com/commercialhaskell/stack#readme If you already have stack-0.1.1.0, you can upgrade using: stack upgrade --git && stack upgrade [normally just 'stack upgrade' will suffice, but due to my flub in the last release we ended up with a stack-9.9.9 on hackage which can't be removed (see https://github.com/haskell/hackage-server/issues/382), and you have to get the stack version that knows to ignore it first] -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at fstaals.net Mon Jul 6 07:51:45 2015 From: frank at fstaals.net (Frank Staals) Date: Mon, 06 Jul 2015 09:51:45 +0200 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] In-Reply-To: (Alexander V. Vershilov's message of "Sat, 4 Jul 2015 22:45:48 +0300") References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: <87r3olg1v2.fsf@Shanna.FStaals.net> Alexander V Vershilov writes: > Not sure that it will make sense for a cafe level, but here is my > understanding of the current state. For the problem of "anonymous > records", i.e. some datatype that may have different fields and their > types we have following appoaches: > > 1. vinyl/hlist/etc. i.e. GADT base heterogeneous list. This one have > O(N) random access and may not be a good fit for "anonymous record" > use case > > 2. records: polymorphic data structures with type-level information > about field names. Here we have a lot of datastructures one per number > of fields multiply on 2 (lazy and strict variant). This one has O(1) random > access. > > 3. fixed-vector-hetero/"wheel above". array based structures has O(1) access. > I call code above a "wheel" because there were a number of similar > implementations here and there. Somehow I feel the most promissing approach is missing from this list: The 'Just do it while compiling!' paper[1] describes how to get O(log n) query and update, by essentially using heterogeneous binomial trees. I think I also saw some haskell implementation in a github gist somewhere, but I could not find the link at the momement. Having said that. I think the Big-O notation used here is misleading, since in 99.999% of all cases we have constant-sized records. Therefore, all approaches give O(1) access/update in these cases. If one really want to know what is fastest benchmarking is the only way to go here. Regards, [1] http://www.fing.edu.uy/~mviera/papers/pepm13.pdf -- - Frank From alexander.vershilov at gmail.com Mon Jul 6 08:15:20 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Mon, 6 Jul 2015 11:15:20 +0300 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] In-Reply-To: <87r3olg1v2.fsf@Shanna.FStaals.net> References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> <87r3olg1v2.fsf@Shanna.FStaals.net> Message-ID: On 6 July 2015 at 10:51, Frank Staals wrote: > Alexander V Vershilov writes: > >> Not sure that it will make sense for a cafe level, but here is my >> understanding of the current state. For the problem of "anonymous >> records", i.e. some datatype that may have different fields and their >> types we have following appoaches: >> >> 1. vinyl/hlist/etc. i.e. GADT base heterogeneous list. This one have >> O(N) random access and may not be a good fit for "anonymous record" >> use case >> >> 2. records: polymorphic data structures with type-level information >> about field names. Here we have a lot of datastructures one per number >> of fields multiply on 2 (lazy and strict variant). This one has O(1) random >> access. >> >> 3. fixed-vector-hetero/"wheel above". array based structures has O(1) access. >> I call code above a "wheel" because there were a number of similar >> implementations here and there. > > Somehow I feel the most promissing approach is missing from this list: > The 'Just do it while compiling!' paper[1] describes how to get O(log n) > query and update, by essentially using heterogeneous binomial trees. I > think I also saw some haskell implementation in a github gist somewhere, > but I could not find the link at the momement. Yes, I tend to agree that this approach should be noted, I just was unaware of that article. As it seems it's better fit for functional paradigm that the "array" based and may have better properties when there are many updates and no fusion was implemented. > Having said that. I think the Big-O notation used here is misleading, > since in 99.999% of all cases we have constant-sized records. Therefore, > all approaches give O(1) access/update in these cases. If one really > want to know what is fastest benchmarking is the only way to go here. Benchmarking in the current case is always the answer, as for some use-cases memory overhead and locality may matter. And vector/data-structure approaches will give better results > Regards, > > [1] http://www.fing.edu.uy/~mviera/papers/pepm13.pdf > > -- > > - Frank -- Alexander From mathijs at bluescreen303.nl Mon Jul 6 11:12:59 2015 From: mathijs at bluescreen303.nl (Mathijs Kwik) Date: Mon, 06 Jul 2015 13:12:59 +0200 Subject: [Haskell-cafe] SPJ's Venn diagram on type-correctness Message-ID: <87si91sfno.fsf@bluescreen303.nl> Hi all, Sometime in the past, I came across a presentation from SPJ in which he showed a Venn diagram showing "programs that compile" and "programs that are correct". Unfortunately, I cannot remember the exact wording and I'm unable to find the slides/talk on google/youtube. Does anyone remember the exact details of the diagram? Or the title of the talk? Is there still a link to it? Thanks, Mathijs From lanablack at amok.cc Mon Jul 6 11:49:42 2015 From: lanablack at amok.cc (Lana Black) Date: Mon, 6 Jul 2015 11:49:42 +0000 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <55999993.1030106@gmail.com> References: <55999993.1030106@gmail.com> Message-ID: <20150706114942.GA1852@rhea> On 22:54 Sun 05 Jul , Silvio Frischknecht wrote: > I need a onCommit functionality for stm. I know there is the > stm-io-hooks [1] package. But it seems so big for such a small thing and > then I have to translate everything to their monad. > lift lift lift ... > > So I thought of a little hack to solve the issue and I'm wondering if > this is safe to use. My understanding of stm internals is very limited. > It's basically just a TChan with IO actions in it and there is another > thread waiting to execute anything inserted into it. > > import Control.Concurrent.STM.TChan > > onCommitChan :: TChan (IO ()) > {-# NOINLINE onCommit #-} > onCommitChan = unsafePerformIO $ do > chan <- newTChanIO > forkIO $ forever $ atomically $ readTChan chan > return chan > > onCommit :: IO () -> STM () > onCommit = writeTChan onCommitChan > > It would be cool if an onCommit hook could be directly added to the stm > package. > > > Silvio > > > [1] https://hackage.haskell.org/package/stm-io-hooks-1.0.1 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe You can't use atomically inside unsafePerformIO. From silvio.frischi at gmail.com Mon Jul 6 11:55:59 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 06 Jul 2015 13:55:59 +0200 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <20150706114942.GA1852@rhea> References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> Message-ID: <559A6CCF.20004@gmail.com> > You can't use atomically inside unsafePerformIO. It's not really inside unsafePerformIO. It's in a separate thread spawned by unsafePerformIO. Anyway, it seems to work correctly. Silvio From ben.ford at baml.com Mon Jul 6 12:27:02 2015 From: ben.ford at baml.com (Ford, Ben) Date: Mon, 06 Jul 2015 12:27:02 +0000 Subject: [Haskell-cafe] SPJ's Venn diagram on type-correctness In-Reply-To: <87si91sfno.fsf@bluescreen303.nl> References: <87si91sfno.fsf@bluescreen303.nl> Message-ID: <4BE6D556240AFE488AAB90F9535FAD57A4582E@smtp_mail.bankofamerica.com> Wasn't that his talk on GADTS and type functions? http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/fun-with-type-funs/FunWithTypeFuns-Apr09.pdf -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mathijs Kwik Sent: 06 July 2015 12:13 To: haskell-cafe at haskell.org Subject: [Haskell-cafe] SPJ's Venn diagram on type-correctness Hi all, Sometime in the past, I came across a presentation from SPJ in which he showed a Venn diagram showing "programs that compile" and "programs that are correct". Unfortunately, I cannot remember the exact wording and I'm unable to find the slides/talk on google/youtube. Does anyone remember the exact details of the diagram? Or the title of the talk? Is there still a link to it? Thanks, Mathijs _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From fryguybob at gmail.com Mon Jul 6 12:34:43 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Mon, 6 Jul 2015 08:34:43 -0400 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <559A6CCF.20004@gmail.com> References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> <559A6CCF.20004@gmail.com> Message-ID: Right, it looks like the atomically is inside unsafePerformIO, but it is in the fork. This is part of why it is better to avoid the unsafePerformIO here. Anything it buys is at great cost to clarity. On Mon, Jul 6, 2015 at 7:55 AM, Silvio Frischknecht < silvio.frischi at gmail.com> wrote: > > You can't use atomically inside unsafePerformIO. > > It's not really inside unsafePerformIO. It's in a separate thread > spawned by unsafePerformIO. Anyway, it seems to work correctly. > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathijs at bluescreen303.nl Mon Jul 6 13:01:42 2015 From: mathijs at bluescreen303.nl (Mathijs Kwik) Date: Mon, 06 Jul 2015 15:01:42 +0200 Subject: [Haskell-cafe] SPJ's Venn diagram on type-correctness In-Reply-To: <4BE6D556240AFE488AAB90F9535FAD57A4582E@smtp_mail.bankofamerica.com> (Ben Ford's message of "Mon, 06 Jul 2015 12:27:02 +0000") References: <87si91sfno.fsf@bluescreen303.nl> <4BE6D556240AFE488AAB90F9535FAD57A4582E@smtp_mail.bankofamerica.com> Message-ID: <87oajpsamh.fsf@bluescreen303.nl> "Ford, Ben" writes: > Wasn't that his talk on GADTS and type functions? > > http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/fun-with-type-funs/FunWithTypeFuns-Apr09.pdf Very nice :) Thanks! > > -----Original Message----- > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mathijs Kwik > Sent: 06 July 2015 12:13 > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] SPJ's Venn diagram on type-correctness > > Hi all, > > Sometime in the past, I came across a presentation from SPJ in which > he showed a Venn diagram showing "programs that compile" and "programs > that are correct". > > Unfortunately, I cannot remember the exact wording and I'm unable to find the slides/talk on google/youtube. > > Does anyone remember the exact details of the diagram? > Or the title of the talk? Is there still a link to it? > > Thanks, > Mathijs > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > ---------------------------------------------------------------------- > This message, and any attachments, is for the intended recipient(s) > only, may contain information that is privileged, confidential and/or > proprietary and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the > intended recipient, please delete this message. From silvio.frischi at gmail.com Mon Jul 6 14:40:19 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 06 Jul 2015 16:40:19 +0200 Subject: [Haskell-cafe] stm onCommit In-Reply-To: References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> <559A6CCF.20004@gmail.com> Message-ID: <559A9353.7010001@gmail.com> > Right, it looks like the atomically is inside unsafePerformIO, but it is > in the fork. This is part of why it is better to avoid the > unsafePerformIO here. Anything it buys is at great cost to clarity. How would you start the thread without using unsafePerformIO? From marcin.jan.mrotek at gmail.com Mon Jul 6 14:48:46 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Mon, 6 Jul 2015 16:48:46 +0200 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <559A9353.7010001@gmail.com> References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> <559A6CCF.20004@gmail.com> <559A9353.7010001@gmail.com> Message-ID: Hello, Isn't using unsafePerformIO to create toplevel variables/channels/whatever considered okay by the docs? https://hackage.haskell.org/package/stm-2.4.4/docs/Control-Concurrent-STM-TChan.html Best regards, Marcin Mrotek From fryguybob at gmail.com Mon Jul 6 14:49:57 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Mon, 6 Jul 2015 10:49:57 -0400 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <559A9353.7010001@gmail.com> References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> <559A6CCF.20004@gmail.com> <559A9353.7010001@gmail.com> Message-ID: Explicitly pass the TChan that handles on commit actions requiring that it is initialized at some point prior. On Mon, Jul 6, 2015 at 10:40 AM, Silvio Frischknecht wrote: > > > Right, it looks like the atomically is inside unsafePerformIO, but it is > > in the fork. This is part of why it is better to avoid the > > unsafePerformIO here. Anything it buys is at great cost to clarity. > > How would you start the thread without using unsafePerformIO? From fryguybob at gmail.com Mon Jul 6 14:51:25 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Mon, 6 Jul 2015 10:51:25 -0400 Subject: [Haskell-cafe] stm onCommit In-Reply-To: References: <55999993.1030106@gmail.com> <20150706114942.GA1852@rhea> <559A6CCF.20004@gmail.com> <559A9353.7010001@gmail.com> Message-ID: Yes, but in my opinion passing variables is clearer and more robust then global variables. On Mon, Jul 6, 2015 at 10:48 AM, Marcin Mrotek wrote: > Hello, > > Isn't using unsafePerformIO to create toplevel > variables/channels/whatever considered okay by the docs? > https://hackage.haskell.org/package/stm-2.4.4/docs/Control-Concurrent-STM-TChan.html > > Best regards, > Marcin Mrotek From sean at functionaljobs.com Mon Jul 6 16:00:02 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 6 Jul 2015 12:00:02 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <559aa6040969d@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Senior Developer at Elsen, Inc. http://functionaljobs.com/jobs/8840-senior-developer-at-elsen-inc Cheers, Sean Murphy FunctionalJobs.com From leza.ml at fecrd.cujae.edu.cu Mon Jul 6 17:20:13 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Mon, 6 Jul 2015 13:20:13 -0400 Subject: [Haskell-cafe] Problems with type families Message-ID: <559AB8CD.2020003@fecrd.cujae.edu.cu> Hi All! Consider the following definitions: type family TFunIn t e type family TFunOut t e data IdT data ComposeT t1 t2 -- etc... type instance TFunIn (ComposeT t1 t2) e = TFunIn t2 e type instance TFunOut (ComposeT t1 t2) e = TFunOut t1 e -- etc... class SignalT t e where transform :: t -> TFunIn t e -> TFunOut t e instance (SignalT t1 e, SignalT t2 e) => SignalT (ComposeT t1 t2) e where transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x Due to the `TFunIn` and `TFunOut` type families instances for [(ComposeT t1 t2) e], the `transform` function for [(ComposeT t1 t2) e] instance of SignalT should be inferred as: transform :: t -> TFunIn (ComposeT t1 t2) e -> TFunOut (ComposeT t1 t2) e <==> :: t -> TFunIn t2 e -> TFunOut t1 e But I cannot figure out why it does not compile. Any ideas? Thanks. -- Leza Morais Lutonda, Lemol-C http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From ben.franksen at online.de Mon Jul 6 18:08:43 2015 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 06 Jul 2015 20:08:43 +0200 Subject: [Haskell-cafe] Fwd: Efficient records with arbitrarily many fields [was: Extensible states] References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> <87r3olg1v2.fsf@Shanna.FStaals.net> Message-ID: Alexander V Vershilov wrote: > On 6 July 2015 at 10:51, Frank Staals wrote: >> Alexander V Vershilov writes: >> >>> Not sure that it will make sense for a cafe level, but here is my >>> understanding of the current state. For the problem of "anonymous >>> records", i.e. some datatype that may have different fields and their >>> types we have following appoaches: >>> >>> 1. vinyl/hlist/etc. i.e. GADT base heterogeneous list. This one have >>> O(N) random access and may not be a good fit for "anonymous record" >>> use case >>> >>> 2. records: polymorphic data structures with type-level information >>> about field names. Here we have a lot of datastructures one per number >>> of fields multiply on 2 (lazy and strict variant). This one has O(1) >>> random access. >>> >>> 3. fixed-vector-hetero/"wheel above". array based structures has O(1) >>> access. I call code above a "wheel" because there were a number of >>> similar implementations here and there. >> >> Somehow I feel the most promissing approach is missing from this list: >> The 'Just do it while compiling!' paper[1] describes how to get O(log n) >> query and update, by essentially using heterogeneous binomial trees. I >> think I also saw some haskell implementation in a github gist somewhere, >> but I could not find the link at the momement. > > Yes, I tend to agree that this approach should be noted, I just was > unaware of that article. As it seems it's better fit for functional > paradigm that the "array" based and may have better properties > when there are many updates and no fusion was implemented. > >> Having said that. I think the Big-O notation used here is misleading, >> since in 99.999% of all cases we have constant-sized records. Therefore, >> all approaches give O(1) access/update in these cases. If one really >> want to know what is fastest benchmarking is the only way to go here. > > Benchmarking in the current case is always the answer, as for some > use-cases memory overhead and locality may matter. And > vector/data-structure approaches will give better results I have read the paper. Of course whatever we can do at compile time we should do. They can't perform any magic, though, and neither do they promise any. If you want O(1) access you have to buy it with O(n) extension. Anyway, asymptotic behavior is really not the issue here. I guess we can safely assume that the large majority of use cases will be with less than 10 members and perhaps 99.9% will have less than 100. Penalizing those 99.9% of usages with high constant factors only so that a record with, say, 100000 members has reasonable performance would be a mistake, IMO. This is a situation quite different from the one for finite maps, which we expect to work reasonably fast with large amounts of keys. My guess is that the O(log(n)) tree solution in the paper is a bit too complex to have really good constant factors, but that's no more than a gut feeling. I agree that benchmarking is the only way to be sure. So, instead of taking about O(1), let me restate and say that I would prefer to have records with "array-like" performance for the basic operations. I could live with "tree-like" if the constant factors are small enough. Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams From leza.ml at fecrd.cujae.edu.cu Mon Jul 6 18:10:30 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Mon, 6 Jul 2015 14:10:30 -0400 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559AB8CD.2020003@fecrd.cujae.edu.cu> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> Message-ID: <559AC496.3060406@fecrd.cujae.edu.cu> On 07/06/2015 01:20 PM, Leza Morais Lutonda wrote: > instance (SignalT t1 e, SignalT t2 e) => SignalT (ComposeT t1 t2) e > where > transform _ x = (transform (undefined :: t1) . transform > (undefined :: t2)) x Sorry for a typo: instance (SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e) => SignalT (ComposeT t1 t2) e where transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x but still not compile. -- Leza Morais Lutonda, Lemol-C Electronic and Telecommunication Engineer Software Development and Architecture Enthusiast http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From brucker at spamfence.net Mon Jul 6 18:12:10 2015 From: brucker at spamfence.net (Achim D. Brucker) Date: Mon, 6 Jul 2015 20:12:10 +0200 Subject: [Haskell-cafe] OCL 2015: Final Call for Papers - Only 10 Days Left Message-ID: <20150706181210.GA5940@fujikawa.home.brucker.ch> (Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now prepare your submission for the OCL workshop! CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. Topics of interest include (but are not limited to) =================================================== - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for -- validation, verification, and testing, -- model transformation and code generation, -- meta-modeling and DSLs, and -- query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports -- usage of textual modeling languages and tools in complex domains, -- usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing tools that support - in a very broad sense - textual modeling languages (if you have implemented OCL.js to run OCL in a web browser, this is the right workshop to present your work) as well as textual model transformations. Venue ===== The workshop will be organized as a part of MODELS 2015 Conference in Ottawa, Canada. It continues the series of OCL workshops held at UML/MODELS conferences: York (2000), Toronto (2001), San Francisco (2003), Lisbon (2004), Montego Bay (2005), Genova (2006), Nashville (2007), Toulouse (2008), Denver (2009), Oslo (2010), Zurich (2011, at the TOOLs conference), 2012 in Innsbruck, 2013 in Miami, and 2014 in Valencia, Spain. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. Workshop Format =============== The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. Submissions =========== Three types of papers will be considered: * short papers (between 6 and 8 pages) describing ideas, * tool papers (between 6 and 8 pages), and * full papers (between 12 and 16 pages) in LNCS format. Submissions should be uploaded to EasyChair (https://easychair.org/conferences/?conf=ocl20150). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a pre-conference edition of CEUR (http://www.ceur-ws.org). Important Dates =============== Submission of papers: July 17, 2015 Notification: August 21, 2015 Workshop date: September 28, 2015 Organizers ========== Achim D. Brucker, SAP SE, Germany Marina Egea, Indra Sistemas S.A., Spain Martin Gogolla, University of Bremen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Programme Committee =================== Mira Balaban, Ben-Gurion University of the Negev, Israel Tricia Balfe, Nomos Software, Ireland Achim D. Brucker, SAP SE, Germany Fabian Buettner, Inria - Ecole des Mines de Nantes, France Jordi Cabot, Inria - Ecole des Mines de Nantes, France Dan Chiorean, Babes-Bolyai University, Romania Robert Clariso, Universitat Oberta de Catalunya, Spain Tony Clark, Middlesex University, UK Manuel Clavel, IMDEA Software Institute, Spain Carolina Dania, IMDEA Software Institute, Spain Birgit Demuth, Technische Universitat Dresden, Germany Marina Egea, Indra Sistemas S.A., Spain Geri Georg, Colorado State University, USA Martin Gogolla, University of Bremen, Germany Shahar Maoz, Tel Aviv University, Israel Istvan Rath, Budapest University of Technology and Economics, Hungary Bernhard Rumpe, RWTH Aachen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Claas Wilke, Technische Universitat Dresden, Germany Edward Willink, Willink Transformations Ltd., UK Burkhart Wolff, Univ. Paris-Sud - LRI, France Steffen Zschaler, King's College, UK -- Dr. Achim D. Brucker, SAP SE, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/ From alan.zimm at gmail.com Mon Jul 6 18:42:52 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 6 Jul 2015 20:42:52 +0200 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin Message-ID: Hi all I am the author of language-javascript and its companion hjsmin. Unfortunately I do not use the libraries myself, and I am falling behind in maintaining them, all the more so with the new ECMASCRIPT spec out. So I am calling for volunteers to take over maintenance of these two packages. Regards Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From achudnov at gmail.com Mon Jul 6 18:57:57 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Mon, 06 Jul 2015 14:57:57 -0400 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: References: Message-ID: <559ACFB5.80706@gmail.com> Alan, I'm not volunteering (yet), but I have a few questions: 1) Could you sum up the status of the package? Is there complete ECMAScript 5.1 support? How comprehensive is the test suite? 2) Are you familiar with language-ecmascript (particularly, with the es5 branch https://github.com/jswebtools/language-ecmascript/tree/es5)? If so, what do you think are the main strengths of language-javascript compared to that package? 3) Do you think it would make sense to merge language-javascript and language-ecmascript and port hjsmin to that? /Andrey On 07/06/2015 02:42 PM, Alan & Kim Zimmerman wrote: > Hi all > > I am the author of language-javascript and its companion hjsmin. > Unfortunately I do not use the libraries myself, and I am falling > behind in maintaining them, all the more so with the new ECMASCRIPT > spec out. > > So I am calling for volunteers to take over maintenance of these two > packages. > > Regards > Alan > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Mon Jul 6 19:03:10 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 06 Jul 2015 21:03:10 +0200 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559AC496.3060406@fecrd.cujae.edu.cu> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> Message-ID: <559AD0EE.7050604@gmail.com> What's the error message? Is a bit hard without that. The problem is probably that you have to explicitly state everything. Maybe TFunIn (ComposeT t1 t2) e ~ TFunOut (SignalT t2 e) The problem with typefamilies is that often things can not be used as you would expect unless you state things explicitly. It is because the instance declaration can not know that TFunIn is always the same. You could import two different ones from different modules and thus convert one type into another. closed typefamilies can sometimes help too. Silvio From alan.zimm at gmail.com Mon Jul 6 19:16:19 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 6 Jul 2015 21:16:19 +0200 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: <559ACFB5.80706@gmail.com> References: <559ACFB5.80706@gmail.com> Message-ID: Hi Andrey 1. I did update it when ECMASCRIPT 5.1 when it came out for version 0.4.6 of language-javascript (according to the ChangeLog). The test suite is very comprehensive. 2. I am not familiar with language-ecmascript. The main feature of language-javascript is that it is written using lex/alex, so is pretty fast. That said, the AST itself could be improved, I was learning when I did it. 3. I think a merge could definitely make sense. I know hjsmin is very intimately tied to language-javascript, so a port might be quite tricky. There are also lots of tests on hjsmin. I would obviously be prepared to guide anyone taking over this role, and to answer questions about the code. Alan On Mon, Jul 6, 2015 at 8:57 PM, Andrey Chudnov wrote: > Alan, > I'm not volunteering (yet), but I have a few questions: > 1) Could you sum up the status of the package? Is there complete > ECMAScript 5.1 support? How comprehensive is the test suite? > 2) Are you familiar with language-ecmascript (particularly, with the es5 > branch https://github.com/jswebtools/language-ecmascript/tree/es5)? If > so, what do you think are the main strengths of language-javascript > compared to that package? > 3) Do you think it would make sense to merge language-javascript and > language-ecmascript and port hjsmin to that? > > /Andrey > > > On 07/06/2015 02:42 PM, Alan & Kim Zimmerman wrote: > > Hi all > > I am the author of language-javascript and its companion hjsmin. > Unfortunately I do not use the libraries myself, and I am falling behind in > maintaining them, all the more so with the new ECMASCRIPT spec out. > > So I am calling for volunteers to take over maintenance of these two > packages. > > Regards > Alan > > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leza.ml at fecrd.cujae.edu.cu Mon Jul 6 19:20:11 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Mon, 6 Jul 2015 15:20:11 -0400 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559AD0EE.7050604@gmail.com> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> <559AD0EE.7050604@gmail.com> Message-ID: <559AD4EB.1@fecrd.cujae.edu.cu> Hi Silvio, thanks for the answer. > What's the error message? Is a bit hard without that. The error message is: (the source code is attached) src/DSP/Sig.hs:41:25: Could not deduce (TFunOut t1 e ~ TFunOut t1 e0) from the context (SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e) bound by the instance declaration at src/DSP/Sig.hs:39:10-95 NB: ?TFunOut? is a type function, and may not be injective The type variable ?e0? is ambiguous Expected type: TFunOut (ComposeT t1 t2) e Actual type: TFunOut t1 e0 Relevant bindings include x :: TFunIn (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:21) transform :: ComposeT t1 t2 -> TFunIn (ComposeT t1 t2) e -> TFunOut (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:9) In the expression: (transform (undefined :: t1) . transform (undefined :: t2)) x In an equation for ?transform?: transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x src/DSP/Sig.hs:41:26: Could not deduce (TFunIn t1 e0 ~ TFunOut t2 e1) from the context (SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e) bound by the instance declaration at src/DSP/Sig.hs:39:10-95 The type variables ?e0?, ?e1? are ambiguous Expected type: TFunOut t2 e1 -> TFunOut t1 e0 Actual type: TFunIn t1 e0 -> TFunOut t1 e0 Relevant bindings include x :: TFunIn (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:21) transform :: ComposeT t1 t2 -> TFunIn (ComposeT t1 t2) e -> TFunOut (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:9) In the first argument of ?(.)?, namely ?transform (undefined :: t1)? In the expression: transform (undefined :: t1) . transform (undefined :: t2) src/DSP/Sig.hs:41:56: Could not deduce (TFunIn t2 e1 ~ TFunIn t2 e) from the context (SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e) bound by the instance declaration at src/DSP/Sig.hs:39:10-95 NB: ?TFunIn? is a type function, and may not be injective The type variable ?e1? is ambiguous Expected type: TFunIn t2 e -> TFunOut t2 e1 Actual type: TFunIn t2 e1 -> TFunOut t2 e1 Relevant bindings include x :: TFunIn (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:21) transform :: ComposeT t1 t2 -> TFunIn (ComposeT t1 t2) e -> TFunOut (ComposeT t1 t2) e (bound at src/DSP/Sig.hs:41:9) In the second argument of ?(.)?, namely ?transform (undefined :: t2)? In the expression: transform (undefined :: t1) . transform (undefined :: t2) Failed, modules loaded: none. > > The problem is probably that you have to explicitly state everything. > > Maybe > > TFunIn (ComposeT t1 t2) e ~ TFunOut (SignalT t2 e) > > The problem with typefamilies is that often things can not be used as > you would expect unless you state things explicitly. > > It is because the instance declaration can not know that TFunIn is > always the same. You could import two different ones from different > modules and thus convert one type into another. > > closed typefamilies can sometimes help too. -- Leza Morais Lutonda, Lemol-C Electronic and Telecommunication Engineer Software Development and Architecture Enthusiast http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu -------------- next part -------------- A non-text attachment was scrubbed... Name: Sig.hs Type: text/x-haskell Size: 1031 bytes Desc: not available URL: From achudnov at gmail.com Mon Jul 6 19:27:41 2015 From: achudnov at gmail.com (Andrey Chudnov) Date: Mon, 06 Jul 2015 15:27:41 -0400 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: References: <559ACFB5.80706@gmail.com> Message-ID: <559AD6AD.10402@gmail.com> Thank you, Alan, I'll have a look at the tests in hjsmin. AFAIK, you are using alex and happy for the parser. Does that cause any issues with Automatic Semicolon Insertion? On 07/06/2015 03:16 PM, Alan & Kim Zimmerman wrote: > Hi Andrey > > 1. I did update it when ECMASCRIPT 5.1 when it came out for version > 0.4.6 of language-javascript (according to the ChangeLog). The test > suite is very comprehensive. > > 2. I am not familiar with language-ecmascript. The main feature of > language-javascript is that it is written using lex/alex, so is pretty > fast. That said, the AST itself could be improved, I was learning when > I did it. > > 3. I think a merge could definitely make sense. I know hjsmin is very > intimately tied to language-javascript, so a port might be quite > tricky. There are also lots of tests on hjsmin. > > I would obviously be prepared to guide anyone taking over this role, > and to answer questions about the code. > > Alan > > > On Mon, Jul 6, 2015 at 8:57 PM, Andrey Chudnov > wrote: > > Alan, > I'm not volunteering (yet), but I have a few questions: > 1) Could you sum up the status of the package? Is there complete > ECMAScript 5.1 support? How comprehensive is the test suite? > 2) Are you familiar with language-ecmascript (particularly, with > the es5 branch > https://github.com/jswebtools/language-ecmascript/tree/es5)? If > so, what do you think are the main strengths of > language-javascript compared to that package? > 3) Do you think it would make sense to merge language-javascript > and language-ecmascript and port hjsmin to that? > > /Andrey > > > On 07/06/2015 02:42 PM, Alan & Kim Zimmerman wrote: >> Hi all >> >> I am the author of language-javascript and its companion hjsmin. >> Unfortunately I do not use the libraries myself, and I am falling >> behind in maintaining them, all the more so with the new >> ECMASCRIPT spec out. >> >> So I am calling for volunteers to take over maintenance of these >> two packages. >> >> Regards >> Alan >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Jul 6 19:29:44 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 6 Jul 2015 21:29:44 +0200 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: <559AD6AD.10402@gmail.com> References: <559ACFB5.80706@gmail.com> <559AD6AD.10402@gmail.com> Message-ID: No, but I had to do some tap dancing, if I recall. On Mon, Jul 6, 2015 at 9:27 PM, Andrey Chudnov wrote: > Thank you, Alan, > I'll have a look at the tests in hjsmin. AFAIK, you are using alex and > happy for the parser. Does that cause any issues with Automatic Semicolon > Insertion? > > > On 07/06/2015 03:16 PM, Alan & Kim Zimmerman wrote: > > Hi Andrey > > 1. I did update it when ECMASCRIPT 5.1 when it came out for version 0.4.6 > of language-javascript (according to the ChangeLog). The test suite is very > comprehensive. > > 2. I am not familiar with language-ecmascript. The main feature of > language-javascript is that it is written using lex/alex, so is pretty > fast. That said, the AST itself could be improved, I was learning when I > did it. > > 3. I think a merge could definitely make sense. I know hjsmin is very > intimately tied to language-javascript, so a port might be quite tricky. > There are also lots of tests on hjsmin. > > I would obviously be prepared to guide anyone taking over this role, and > to answer questions about the code. > > Alan > > > On Mon, Jul 6, 2015 at 8:57 PM, Andrey Chudnov wrote: > >> Alan, >> I'm not volunteering (yet), but I have a few questions: >> 1) Could you sum up the status of the package? Is there complete >> ECMAScript 5.1 support? How comprehensive is the test suite? >> 2) Are you familiar with language-ecmascript (particularly, with the es5 >> branch https://github.com/jswebtools/language-ecmascript/tree/es5)? If >> so, what do you think are the main strengths of language-javascript >> compared to that package? >> 3) Do you think it would make sense to merge language-javascript and >> language-ecmascript and port hjsmin to that? >> >> /Andrey >> >> >> On 07/06/2015 02:42 PM, Alan & Kim Zimmerman wrote: >> >> Hi all >> >> I am the author of language-javascript and its companion hjsmin. >> Unfortunately I do not use the libraries myself, and I am falling behind in >> maintaining them, all the more so with the new ECMASCRIPT spec out. >> >> So I am calling for volunteers to take over maintenance of these two >> packages. >> >> Regards >> Alan >> >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Jul 6 20:32:56 2015 From: adam at well-typed.com (Adam Gundry) Date: Mon, 6 Jul 2015 21:32:56 +0100 Subject: [Haskell-cafe] stm onCommit In-Reply-To: <55999993.1030106@gmail.com> References: <55999993.1030106@gmail.com> Message-ID: <559AE5F8.5010300@well-typed.com> On 05/07/15 21:54, Silvio Frischknecht wrote: > I need a onCommit functionality for stm. I know there is the > stm-io-hooks [1] package. But it seems so big for such a small thing and > then I have to translate everything to their monad. > lift lift lift ... > > So I thought of a little hack to solve the issue and I'm wondering if > this is safe to use. My understanding of stm internals is very limited. > It's basically just a TChan with IO actions in it and there is another > thread waiting to execute anything inserted into it. > > import Control.Concurrent.STM.TChan > > onCommitChan :: TChan (IO ()) > {-# NOINLINE onCommit #-} > onCommitChan = unsafePerformIO $ do > chan <- newTChanIO > forkIO $ forever $ atomically $ readTChan chan > return chan > > onCommit :: IO () -> STM () > onCommit = writeTChan onCommitChan Leaving aside the question of unsafePerformIO, which is a bad idea, this will more-or-less work, but I suppose the question is what you mean by "safe to use". You might want to think about exception safety: for example, if one of the IO actions written to the channel throws an exception, it will bring down the worker thread, and subsequent onCommit actions will be silently lost. Or if an IO action blocks (or just runs slowly) other actions may be arbitrarily delayed. Depending on your application, this may or may not be acceptable. Hope this helps, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From silvio.frischi at gmail.com Mon Jul 6 23:29:30 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Tue, 07 Jul 2015 01:29:30 +0200 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559AD4EB.1@fecrd.cujae.edu.cu> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> <559AD0EE.7050604@gmail.com> <559AD4EB.1@fecrd.cujae.edu.cu> Message-ID: <559B0F5A.7000802@gmail.com> looks like the problem are the 'e's. you can see it from Could not deduce (TFunOut t1 e ~ TFunOut t1 e0) the e0 comes from the output of TFunIn/TFunOut and the instance does not know that it is the same as the e variable you use. I don't know exactly what your program does. but if e is just a phantom/security parameter you can do it like this. type family TFunIn t :: * -> * type instance TFunIn IdT = Signal type instance TFunIn (ComposeT t1 t2) = TFunIn t2 instance (SignalT t1 e, SignalT t2 e, TFunOut t2 ~ TFunIn t1) => SignalT (ComposeT t1 t2) e where transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x Otherwise you will have to find a way to prove that the 'e's are the same Cheers Silvio From winterkoninkje at gmail.com Tue Jul 7 00:28:54 2015 From: winterkoninkje at gmail.com (wren romano) Date: Mon, 6 Jul 2015 20:28:54 -0400 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs Message-ID: Hi all, In my latest project I've been using a bunch of GADTs, which unfortunately disables let-polymorphism (i.e., where-polymorphism) in the most annoying way. For the most part I've been able to hack around that limitation via judicious use of ScopedTypeVariables, but I've run into an issue that I can't for the life of me figure out why GHC doesn't like it. I have something like the following function, where @a@ and @b@ happen to be GADTs: foo :: (A a, B b) => a i -> M (b i) foo a = case view a of ... SomePattern a1 a2 -> do b1 <- foo a1 b2 <- foo a2 return . unview $ SomePattern b1 b2 It seems to me that the recursive calls should work just fine, using the same @b@ as we'll ultimately be returning. However, for some reason GHC complains about the recursive calls using some other @b0@ can can't deduce @B b0@ from @B b at . Why doesn't GHC unify these two types? How can I force them to unify without adding type annotations at every recursive call? -- Live well, ~wren From kmill31415 at gmail.com Tue Jul 7 04:54:38 2015 From: kmill31415 at gmail.com (Kyle Miller) Date: Mon, 6 Jul 2015 21:54:38 -0700 Subject: [Haskell-cafe] GHC Memory Management wiki page Message-ID: I have been studying the garbage collection algorithms used in GHC, and it appears to me that section two of [1] is misleading, since thunks permit controlled mutation of the heap, and so objects in older generations may point to younger objects. In fact, the RTS maintains "remembered sets" to keep track of these relations. A Haskell could in principle be implemented in the way described (and execute in surprising complexity classes), but this does not seem to match reality. [1] https://wiki.haskell.org/GHC/Memory_Management Should the wiki be modified? Regards, Kyle Miller -------------- next part -------------- An HTML attachment was scrubbed... URL: From mle+hs at mega-nerd.com Tue Jul 7 06:36:13 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Tue, 7 Jul 2015 16:36:13 +1000 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: References: Message-ID: <20150707163613.932b3aec77053ce8f4c1d8f7@mega-nerd.com> Alan & Kim Zimmerman wrote: > So I am calling for volunteers to take over maintenance of these two > packages. I;d like to stick my hand up for these. I still have a plans to drastically improve the AST, something like in my new-ast branch: https://github.com/erikd/language-javascript/tree/new-ast Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From marco.vax91 at gmail.com Tue Jul 7 08:42:41 2015 From: marco.vax91 at gmail.com (Marco Vassena) Date: Tue, 7 Jul 2015 10:42:41 +0200 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: Message-ID: <086F1423-AAB7-4480-9D6E-7716D1457E8E@gmail.com> Hi Wren, I think that the ambiguity comes from the fact that the type variable b is mentioned only in the constraints and in the result type. Crucially the instance B b selected determines the result b, and this in general leads to ambiguity because instances are chosen automatically behind the scenes. A standard way to fix this is to include the ambiguous type b among the types of the arguments. With this trick it is possible to drive the instance choice to select the correct one passing the right argument, avoiding any ambiguity. For example you can use a Proxy b [1], to force the recursive calls to reuse the same b. foo :: (A a, B b) => a i -> Proxy b -> M (b i) foo a p = case view a of ... SomePattern a1 a2 -> do b1 <- foo p a1 b2 <- foo p a2 return . unview $ SomePattern b1 b2 I hope this helps. All the best, Marco [1] https://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Proxy.html On 07/lug/2015, at 02.28, wren romano wrote: > Hi all, > > In my latest project I've been using a bunch of GADTs, which > unfortunately disables let-polymorphism (i.e., where-polymorphism) in > the most annoying way. For the most part I've been able to hack around > that limitation via judicious use of ScopedTypeVariables, but I've run > into an issue that I can't for the life of me figure out why GHC > doesn't like it. > > I have something like the following function, where @a@ and @b@ happen > to be GADTs: > > foo :: (A a, B b) => a i -> M (b i) > foo a = > case view a of > ... > SomePattern a1 a2 -> do > b1 <- foo a1 > b2 <- foo a2 > return . unview $ SomePattern b1 b2 > > It seems to me that the recursive calls should work just fine, using > the same @b@ as we'll ultimately be returning. However, for some > reason GHC complains about the recursive calls using some other @b0@ > can can't deduce @B b0@ from @B b at . Why doesn't GHC unify these two > types? How can I force them to unify without adding type annotations > at every recursive call? > > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Tue Jul 7 12:36:00 2015 From: tonymorris at gmail.com (Tony Morris) Date: Tue, 7 Jul 2015 22:36:00 +1000 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: <20150707163613.932b3aec77053ce8f4c1d8f7@mega-nerd.com> References: <20150707163613.932b3aec77053ce8f4c1d8f7@mega-nerd.com> Message-ID: <559BC7B0.8060107@gmail.com> I will assist Erik as needed. On 07/07/15 16:36, Erik de Castro Lopo wrote: > Alan & Kim Zimmerman wrote: > >> So I am calling for volunteers to take over maintenance of these two >> packages. > > I;d like to stick my hand up for these. I still have a plans to drastically > improve the AST, something like in my new-ast branch: > > https://github.com/erikd/language-javascript/tree/new-ast > > Cheers, > Erik > From winterkoninkje at gmail.com Tue Jul 7 16:05:59 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 7 Jul 2015 12:05:59 -0400 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Tue, Jul 7, 2015 at 3:35 AM, Simon Peyton Jones wrote: > If you post a repro case someone (even me) might help. The devil is always in the details. The smallest repro I can come up with (which is still related to the actual problem) is as follows. In case it matters for the solution, there are a number of important bits I've erased. Most importantly, the inferType function is actually mutually recursive with a checkType function, though that doesn't seem to be the cause of the problem. {-# LANGUAGE DataKinds, PolyKinds, GADTs #-} data Type = Fun Type Type data Sing :: Type -> * where SFun :: Sing i -> Sing j -> Sing (Fun i j) data AST :: (Type -> *) -> Type -> * where App :: ast (Fun a b) -> ast a -> AST ast b class ABT (abt :: Type -> *) where view :: abt a -> AST abt a unview :: AST abt a -> abt a class WellTypedABT (abt :: Type -> *) where unviewWT :: Sing a -> AST abt a -> abt a typeOf :: abt a -> Sing a data TypeCheckMonad a = TCM { unTCM :: a } instance Functor TypeCheckMonad where fmap f = TCM . f . unTCM instance Applicative TypeCheckMonad where pure = TCM TCM f <*> TCM x = TCM (f x) instance Monad TypeCheckMonad where return = pure TCM x >>= k = k x inferType :: (ABT abt, WellTypedABT abt') => abt a -> TypeCheckMonad (abt' a) inferType e0 = case view e0 of App e1 e2 -> do e1' <- inferType e1 case typeOf e1' of SFun typ2 typ3 -> do e2' <- inferType e2 return . unviewWT typ3 $ App e1' e2' -- Live well, ~wren From winterkoninkje at gmail.com Tue Jul 7 16:15:33 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 7 Jul 2015 12:15:33 -0400 Subject: [Haskell-cafe] Symmetric Difference for Data.Set and Data.IntSet? In-Reply-To: References: Message-ID: On Sun, Jul 5, 2015 at 6:33 PM, Ben Franksen wrote: > Zemyla wrote: >> Could this be implemented as a primitive? I know it can be made from union >> and difference, or doing toList on both of them, taking the symmetric >> difference, and using fromDistinctAscList on the result, but it'd probably >> be much faster if it could be done natively, like can be done with >> Data.Map.mergeWithKey. > > +1 I'm also very +1. -- Live well, ~wren From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 17:39:13 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 19:39:13 +0200 Subject: [Haskell-cafe] You know, I am tired of it. Message-ID: Whatever "community" I go, they all pretend like their old shit is SO important. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Jul 7 17:40:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 7 Jul 2015 13:40:05 -0400 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: On Tue, Jul 7, 2015 at 1:39 PM, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Whatever "community" I go, they all pretend like their old shit is SO > important. > I assume you've never had to support anyone but yourself, then. -- 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 stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 17:41:16 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 19:41:16 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: Once again, a nonsense response? On Tue, Jul 7, 2015 at 7:40 PM, Brandon Allbery wrote: > On Tue, Jul 7, 2015 at 1:39 PM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Whatever "community" I go, they all pretend like their old shit is SO >> important. >> > > I assume you've never had to support anyone but yourself, then. > > -- > 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 6yearold at gmail.com Tue Jul 7 17:45:01 2015 From: 6yearold at gmail.com (Gleb Popov) Date: Tue, 7 Jul 2015 20:45:01 +0300 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Whatever "community" I go, they all pretend like their old shit is SO > important. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > If everyone around are bad, then the root of the problem is within you, don't you think? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 17:47:38 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 19:47:38 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: Why is that? You're just a liar. On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: > > > On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Whatever "community" I go, they all pretend like their old shit is SO >> important. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > If everyone around are bad, then the root of the problem is within you, > don't you think? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 17:48:11 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 19:48:11 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: Just because you say this - doesn't make it true. I'm still saying the truth here. Cheers On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: > > > On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Whatever "community" I go, they all pretend like their old shit is SO >> important. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > If everyone around are bad, then the root of the problem is within you, > don't you think? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 17:52:38 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 19:52:38 +0200 Subject: [Haskell-cafe] The sad thing is, you don't see the new stuff. Message-ID: Haskell was - maybe - the most elegant mathematical logic-oriented language out there. It's why I used it. Now there is my approach, which is reciprocal simplification of the programming process. THAT is elegant. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From petite.abeille at gmail.com Tue Jul 7 17:55:49 2015 From: petite.abeille at gmail.com (Petite Abeille) Date: Tue, 7 Jul 2015 19:55:49 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: <74C06EB2-4488-4BCD-BA37-F65228F41F09@gmail.com> > On Jul 7, 2015, at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: > > If everyone around are bad, then the root of the problem is within you, don't you think? Congrats to Haskell Cafe for patiently looking after Stefan, who has made numerous appearances across various other language mailing lists around the interweb. Thanks Haskell Cafe! From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 18:20:13 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 20:20:13 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: <74C06EB2-4488-4BCD-BA37-F65228F41F09@gmail.com> References: <74C06EB2-4488-4BCD-BA37-F65228F41F09@gmail.com> Message-ID: Once again you're trying to label ME insane? Some day it just ain't gonna work no more. You're from Lua-L, right? The insane place? Am 07.07.2015 19:56 schrieb "Petite Abeille" : > > > On Jul 7, 2015, at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: > > > > If everyone around are bad, then the root of the problem is within you, > don't you think? > > Congrats to Haskell Cafe for patiently looking after Stefan, who has made > numerous appearances across various other language mailing lists around the > interweb. Thanks Haskell Cafe! > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gladstein at gladstein.com Tue Jul 7 18:20:30 2015 From: gladstein at gladstein.com (David Gladstein) Date: Tue, 7 Jul 2015 11:20:30 -0700 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: Regarding the time-varying importance of shit: A few years back Blender (www.blender.org) had a major release that broke everything. The UI changed, so all the tutorials were suddenly wrong As in, five minutes in you were lost, trying to find nonexistent panels on your screen. I'd been trying to learn Blender off and on over the years, and when I finally decided to make a serious run at it, it was impossible. I gave up and came back a few more times, and finally the tutorials got updated and I was off and running. I noticed a few aspects of Blender that were absolutely brilliant compared to Maya. I wondered, that's so obviously the right thing, why doesn't Autodesk do that in Maya? And then it hit me. They simply can't. They get thousands of dollars per seat for their product, and studios depend on it being backward-compatible. The studios are VERY conservative about upgrading, they're often a release or two behind the ones everyone else uses. Blender is free, and if you want any version since 1.0, it's available. If you want all of them at once, you can have that. It's just a program. Something broke for you in a certain version? Just use the version that works. It's like version control, it doesn't prevent mistakes, but it allows you to go back to when things were working. I'm pleased to note that the Haskell wiki has versions of the platform going back five years, so hopefully we're in the position of making well-thought-out breaking changes rather than maintaining compatibility forever. (I have no idea what this thread is about, so forgive me if I'm coming down on the wrong side of the argument. I like my story anyway.) On Tue, Jul 7, 2015 at 10:48 AM, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Just because you say this - doesn't make it true. I'm still saying the > truth here. > > Cheers > > On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: > >> >> >> On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < >> stefan.reich.maker.of.eye at googlemail.com> wrote: >> >>> Whatever "community" I go, they all pretend like their old shit is SO >>> important. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> If everyone around are bad, then the root of the problem is within you, >> don't you think? >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 18:25:26 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 20:25:26 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: So you basically say that open sourcing is very good. It is :) I always work like this now, everything I do in my db (snippets.tinybrain.de) is versioned publicly. Basically, nothing ever breaks, with a little effort. On Tue, Jul 7, 2015 at 8:20 PM, David Gladstein wrote: > Regarding the time-varying importance of shit: > > A few years back Blender (www.blender.org) had a major release that broke > everything. The UI changed, so all the tutorials were suddenly wrong As in, > five minutes in you were lost, trying to find nonexistent panels on your > screen. I'd been trying to learn Blender off and on over the years, and > when I finally decided to make a serious run at it, it was impossible. I > gave up and came back a few more times, and finally the tutorials got > updated and I was off and running. > > I noticed a few aspects of Blender that were absolutely brilliant compared > to Maya. I wondered, that's so obviously the right thing, why doesn't > Autodesk do that in Maya? And then it hit me. They simply can't. They get > thousands of dollars per seat for their product, and studios depend on it > being backward-compatible. The studios are VERY conservative about > upgrading, they're often a release or two behind the ones everyone else > uses. Blender is free, and if you want any version since 1.0, it's > available. If you want all of them at once, you can have that. It's just a > program. Something broke for you in a certain version? Just use the version > that works. It's like version control, it doesn't prevent mistakes, but it > allows you to go back to when things were working. > > I'm pleased to note that the Haskell wiki has versions of the platform > going back five years, so hopefully we're in the position of making > well-thought-out breaking changes rather than maintaining compatibility > forever. > > (I have no idea what this thread is about, so forgive me if I'm coming > down on the wrong side of the argument. I like my story anyway.) > > On Tue, Jul 7, 2015 at 10:48 AM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> Just because you say this - doesn't make it true. I'm still saying the >> truth here. >> >> Cheers >> >> On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: >> >>> >>> >>> On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < >>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>> >>>> Whatever "community" I go, they all pretend like their old shit is SO >>>> important. >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> If everyone around are bad, then the root of the problem is within you, >>> don't you think? >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Tue Jul 7 18:28:08 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Tue, 7 Jul 2015 20:28:08 +0200 Subject: [Haskell-cafe] The world actually IS insane. Message-ID: So if I think "hey, these people are insane and I'm not" - I'm actually right. Because I woke up from insanity. Come join me, it's better here. You lose the pain. Cheers Stefan PS: Somebody now tell me that "this list is only for Haskell!!11!!!", once again proving your insanity. :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Tue Jul 7 18:36:19 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 7 Jul 2015 20:36:19 +0200 Subject: [Haskell-cafe] The world actually IS insane. In-Reply-To: References: Message-ID: On 07/07/2015 08:28 PM, Stefan Reich wrote: > So if I think "hey, these people are insane and I'm not" - I'm actually > right. Because I woke up from insanity. Come join me, it's better here. You > lose the pain. > > Cheers > Stefan > > PS: Somebody now tell me that "this list is only for Haskell!!11!!!", once > again proving your insanity. :) > This list is not your personal blog, nor twitter. Please stop spamming. Regards, From alan.zimm at gmail.com Tue Jul 7 18:40:12 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 7 Jul 2015 20:40:12 +0200 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: <559BC7B0.8060107@gmail.com> References: <20150707163613.932b3aec77053ce8f4c1d8f7@mega-nerd.com> <559BC7B0.8060107@gmail.com> Message-ID: Having heard from Andrey Chudnov, who also showed interest, it looks like the new maintainers will be Erik de Castro Lopo and Tony Morris. Andrey has offered to assist if there is even an intent to merge language-javascript with language-ecmascript. Thanks everyone. Regards Alan On Tue, Jul 7, 2015 at 2:36 PM, Tony Morris wrote: > I will assist Erik as needed. > > On 07/07/15 16:36, Erik de Castro Lopo wrote: > > Alan & Kim Zimmerman wrote: > > > >> So I am calling for volunteers to take over maintenance of these two > >> packages. > > > > I;d like to stick my hand up for these. I still have a plans to > drastically > > improve the AST, something like in my new-ast branch: > > > > https://github.com/erikd/language-javascript/tree/new-ast > > > > Cheers, > > Erik > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexispraga at mailoo.org Tue Jul 7 20:07:22 2015 From: alexispraga at mailoo.org (Alexis Praga) Date: Tue, 7 Jul 2015 22:07:22 +0200 Subject: [Haskell-cafe] References on haskellwiki In-Reply-To: References: <20150311162110.GA44822@alex.alexdebian> Message-ID: <20150707200722.GB3898@localhost.localdomain> It works fine. I've updated the list of references on this page as an example : https://wiki.haskell.org/The_Monad.Reader/Issue2/FunWithLinearImplicitParameters Thanks again On Mon, Jun 15, 2015 at 10:54:24PM -0400, Gershom B wrote: > Just added this extension. Let me know if it works. > > ?Gershom > > > On March 11, 2015 at 12:21:24 PM, Alexis Praga (alexispraga at mailoo.org) wrote: > > Hi, > > > > I've begun to do some formatting on old Monad Readers editions on > > Haskell Wiki. Unfortunately, there is no support for proper references > > support. > > > > Can the admin add the "Cite" extension ? It would help a lot. > > > > Thanks > > > > -- > > Alexis Praga, PhD Student (CERFACS) > > GPG key : AD4A AF6D BB5C 042F 9422 1223 06E1 C1BF E287 65D0 > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -- Alexis Praga GPG key : AD4A AF6D BB5C 042F 9422 1223 06E1 C1BF E287 65D0 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From K.Bleijenberg at lijbrandt.nl Wed Jul 8 08:02:51 2015 From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg) Date: Wed, 8 Jul 2015 10:02:51 +0200 Subject: [Haskell-cafe] ambiguous module name Network.URI Message-ID: <000001d0b954$7d19d220$774d7660$@lijbrandt.nl> If i import these 2 packages in a project: import Network.HTTP import qualified Network.URI as NU I get: testNetw.hs:7:18: Ambiguous module name `Network.URI': it was found in multiple packages: network-uri-2.6.0.3 network-2.4.2.3 I'am using the latest 32 bits haskell platform on Windows 7 64 bits. I need the NU.parseURI function. What can I do? Kees -------------- next part -------------- An HTML attachment was scrubbed... URL: From creichert07 at gmail.com Wed Jul 8 08:20:03 2015 From: creichert07 at gmail.com (Christopher Reichert) Date: Wed, 08 Jul 2015 03:20:03 -0500 Subject: [Haskell-cafe] ambiguous module name Network.URI In-Reply-To: <000001d0b954$7d19d220$774d7660$@lijbrandt.nl> (Kees Bleijenberg's message of "Wed, 8 Jul 2015 10:02:51 +0200") References: <000001d0b954$7d19d220$774d7660$@lijbrandt.nl> Message-ID: <559cdd3a.04f3ca0a.2438.2462@mx.google.com> On Wed, Jul 08 2015, "Kees Bleijenberg" wrote: > If i import these 2 packages in a project: > > import Network.HTTP > > import qualified Network.URI as NU > > > > I get: > > testNetw.hs:7:18: > > Ambiguous module name `Network.URI': > > it was found in multiple packages: > > network-uri-2.6.0.3 network-2.4.2.3 > > > > I'am using the latest 32 bits haskell platform on Windows 7 64 bits. > > I need the NU.parseURI function. What can I do? > > Check out the Hackage page for network-uri: https://hackage.haskell.org/package/network-uri The parseURI function is in the version of network you are using already so there is no need to import modules from network-uri. > > Kees > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Christopher Reichert irc: creichert gpg: C81D 18C8 862A 3618 1376 FFA5 6BFC A992 9955 929B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From K.Bleijenberg at lijbrandt.nl Wed Jul 8 09:38:33 2015 From: K.Bleijenberg at lijbrandt.nl (Kees Bleijenberg) Date: Wed, 8 Jul 2015 11:38:33 +0200 Subject: [Haskell-cafe] ambiguous module name Network.URI Message-ID: <001201d0b961$db632ae0$922980a0$@lijbrandt.nl> Thanks Christopher, -----Oorspronkelijk bericht----- Check out the Hackage page for network-uri: https://hackage.haskell.org/package/network-uri The parseURI function is in the version of network you are using already so there is no need to import modules from network-uri. ---------------------------------------- If I remove the import of Network-URI and leave the import Network.Http and use parseURI, ghc complains: not in scope parseURI. Do I have to change someting in the packages? Kees From mle+hs at mega-nerd.com Wed Jul 8 10:24:09 2015 From: mle+hs at mega-nerd.com (Erik de Castro Lopo) Date: Wed, 8 Jul 2015 20:24:09 +1000 Subject: [Haskell-cafe] Request for maintainer(s) : language-javascript / hjsmin In-Reply-To: References: <20150707163613.932b3aec77053ce8f4c1d8f7@mega-nerd.com> <559BC7B0.8060107@gmail.com> Message-ID: <20150708202409.5d54ac56a73922daed8582e4@mega-nerd.com> Alan & Kim Zimmerman wrote: > Having heard from Andrey Chudnov, who also showed interest, it looks like > the new maintainers will be Erik de Castro Lopo and Tony Morris. > > Andrey has offered to assist if there is even an intent to merge > language-javascript with language-ecmascript. Thanks Alan for your hard work so far on that package. I'll try and do a new minor release on the weekend that does little more than update the maintainers in the cabal file. I will then work to merge the work I have in a branch to improve the AST. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From tmorris at tmorris.net Wed Jul 8 12:57:04 2015 From: tmorris at tmorris.net (Tony Morris) Date: Wed, 8 Jul 2015 22:57:04 +1000 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: You're awesome. I wish I could be like you. Have you tried Scala? On Wed, Jul 8, 2015 at 4:25 AM, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > So you basically say that open sourcing is very good. It is :) I always > work like this now, everything I do in my db (snippets.tinybrain.de) is > versioned publicly. Basically, nothing ever breaks, with a little effort. > > On Tue, Jul 7, 2015 at 8:20 PM, David Gladstein > wrote: > >> Regarding the time-varying importance of shit: >> >> A few years back Blender (www.blender.org) had a major release that >> broke everything. The UI changed, so all the tutorials were suddenly wrong >> As in, five minutes in you were lost, trying to find nonexistent panels on >> your screen. I'd been trying to learn Blender off and on over the years, >> and when I finally decided to make a serious run at it, it was impossible. >> I gave up and came back a few more times, and finally the tutorials got >> updated and I was off and running. >> >> I noticed a few aspects of Blender that were absolutely brilliant >> compared to Maya. I wondered, that's so obviously the right thing, why >> doesn't Autodesk do that in Maya? And then it hit me. They simply can't. >> They get thousands of dollars per seat for their product, and studios >> depend on it being backward-compatible. The studios are VERY conservative >> about upgrading, they're often a release or two behind the ones everyone >> else uses. Blender is free, and if you want any version since 1.0, it's >> available. If you want all of them at once, you can have that. It's just a >> program. Something broke for you in a certain version? Just use the version >> that works. It's like version control, it doesn't prevent mistakes, but it >> allows you to go back to when things were working. >> >> I'm pleased to note that the Haskell wiki has versions of the platform >> going back five years, so hopefully we're in the position of making >> well-thought-out breaking changes rather than maintaining compatibility >> forever. >> >> (I have no idea what this thread is about, so forgive me if I'm coming >> down on the wrong side of the argument. I like my story anyway.) >> >> On Tue, Jul 7, 2015 at 10:48 AM, Stefan Reich < >> stefan.reich.maker.of.eye at googlemail.com> wrote: >> >>> Just because you say this - doesn't make it true. I'm still saying the >>> truth here. >>> >>> Cheers >>> >>> On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < >>>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>>> >>>>> Whatever "community" I go, they all pretend like their old shit is SO >>>>> important. >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> If everyone around are bad, then the root of the problem is within you, >>>> don't you think? >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From creichert07 at gmail.com Wed Jul 8 14:10:23 2015 From: creichert07 at gmail.com (Christopher Reichert) Date: Wed, 08 Jul 2015 09:10:23 -0500 Subject: [Haskell-cafe] ambiguous module name Network.URI In-Reply-To: <001201d0b961$db632ae0$922980a0$@lijbrandt.nl> (Kees Bleijenberg's message of "Wed, 8 Jul 2015 11:38:33 +0200") References: <001201d0b961$db632ae0$922980a0$@lijbrandt.nl> Message-ID: <559d2f54.c966ca0a.cbabd.3aa6@mx.google.com> On Wed, Jul 08 2015, "Kees Bleijenberg" wrote: > Thanks Christopher, > > > -----Oorspronkelijk bericht----- > > Check out the Hackage page for network-uri: > https://hackage.haskell.org/package/network-uri > > The parseURI function is in the version of network you are using already so > there is no need to import modules from network-uri. > > ---------------------------------------- > > If I remove the import of Network-URI and leave the import Network.Http and > use parseURI, ghc complains: not in scope parseURI. > Do I have to change someting in the packages? > You should leave the import of Network.URI. Are you trying to build a cabal project? Did you install the network-uri package yourself? If you're creating a cabal project try adding: build-depends: network-uri < 2.6, network < 2.6 Otherwise, can you describe the install steps you are taking? > Kees > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Christopher Reichert irc: creichert gpg: C81D 18C8 862A 3618 1376 FFA5 6BFC A992 9955 929B -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From k-bx at k-bx.com Wed Jul 8 14:10:47 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Wed, 8 Jul 2015 17:10:47 +0300 Subject: [Haskell-cafe] GHC Memory Management wiki page In-Reply-To: References: Message-ID: I would suggest posting this to ghc-devs. 7 ???. 2015 07:54 "Kyle Miller" ????: > I have been studying the garbage collection algorithms used in GHC, and it > appears to me that section two of [1] is misleading, since thunks permit > controlled mutation of the heap, and so objects in older generations may > point to younger objects. In fact, the RTS maintains "remembered sets" to > keep track of these relations. A Haskell could in principle be implemented > in the way described (and execute in surprising complexity classes), but > this does not seem to match reality. > > [1] https://wiki.haskell.org/GHC/Memory_Management > > Should the wiki be modified? > > Regards, > Kyle Miller > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Jul 8 14:47:52 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 8 Jul 2015 10:47:52 -0400 Subject: [Haskell-cafe] GHC Memory Management wiki page In-Reply-To: References: Message-ID: Yep. The wiki should be modified ? it is pretty clearly an old page in error. Good eye on spotting it. There is some extremely detailed material on the GHC developers wiki:?https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC I would hope that the material on the main Haskell Wiki could be at an ?intermediate? level ? a bit of high-level overview, with pointers to other good material. Cheers, Gershom On July 8, 2015 at 10:11:47 AM, Kostiantyn Rybnikov (k-bx at k-bx.com) wrote: > I would suggest posting this to ghc-devs. > 7 ???. 2015 07:54 "Kyle Miller" ????: > > > I have been studying the garbage collection algorithms used in GHC, and it > > appears to me that section two of [1] is misleading, since thunks permit > > controlled mutation of the heap, and so objects in older generations may > > point to younger objects. In fact, the RTS maintains "remembered sets" to > > keep track of these relations. A Haskell could in principle be implemented > > in the way described (and execute in surprising complexity classes), but > > this does not seem to match reality. > > > > [1] https://wiki.haskell.org/GHC/Memory_Management > > > > Should the wiki be modified? > > > > Regards, > > Kyle Miller > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From silvio.frischi at gmail.com Wed Jul 8 18:54:33 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 08 Jul 2015 20:54:33 +0200 Subject: [Haskell-cafe] Announcing: monadic FRP using stm Message-ID: <559D71E9.6060406@gmail.com> Hi Haskellers, I know there are already a lot of FRP libraries out there, but still. This is my take on it. It's a very simple library. There are portable Signals that are basically TVars with some update Notifiers. Then you can combine them using a continuation like monad. Because you have a Monad and not only Applicative it's very intuitive and powerful. Check it out. github: https://github.com/yokto/Updater hackage: https://hackage.haskell.org/package/Updater Be warned though. There are probably still some bugs around, but the basics seem to work and there is an example program. Silvio From agocorona at gmail.com Wed Jul 8 19:07:58 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed, 8 Jul 2015 21:07:58 +0200 Subject: [Haskell-cafe] Announcing: monadic FRP using stm In-Reply-To: <559D71E9.6060406@gmail.com> References: <559D71E9.6060406@gmail.com> Message-ID: Seems to be similar to Transient: https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 2015-07-08 20:54 GMT+02:00 Silvio Frischknecht : > Hi Haskellers, > > I know there are already a lot of FRP libraries out there, but still. > This is my take on it. > > It's a very simple library. There are portable Signals that are > basically TVars with some update Notifiers. Then you can combine them > using a continuation like monad. > > Because you have a Monad and not only Applicative it's very intuitive > and powerful. > > Check it out. > > github: https://github.com/yokto/Updater > hackage: https://hackage.haskell.org/package/Updater > > Be warned though. There are probably still some bugs around, but the > basics seem to work and there is an example program. > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Wed Jul 8 19:25:43 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 08 Jul 2015 21:25:43 +0200 Subject: [Haskell-cafe] Announcing: monadic FRP using stm In-Reply-To: References: <559D71E9.6060406@gmail.com> Message-ID: <559D7937.90507@gmail.com> > Seems to be similar to Transient: > > https://www.fpcomplete.com/user/agocorona/monad-reactive-programming-2 Yeah I found that too once I had started programming. The idea seems pretty similar. I think they have their signals in a lookup table and my signals are TVars. I don't think they have a package on hackage. What is really cool about my version is that because of the nature of STM you can share signals anyway you want. The creation and use of them are completely independent. Of course you could achieve the same with a global lock. Silvio From silvio.frischi at gmail.com Wed Jul 8 19:30:10 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 08 Jul 2015 21:30:10 +0200 Subject: [Haskell-cafe] Announcing: monadic FRP using stm In-Reply-To: <559D7937.90507@gmail.com> References: <559D71E9.6060406@gmail.com> <559D7937.90507@gmail.com> Message-ID: <559D7A42.8000906@gmail.com> sed -e "s_they_you" I see you're the same person :) Silvio From stefan.reich.maker.of.eye at googlemail.com Wed Jul 8 20:31:50 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 8 Jul 2015 22:31:50 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: I know you want to be like me. You will be. Haha Scala is complex without a purpose. JavaX is the answer. Am 08.07.2015 14:57 schrieb "Tony Morris" : > You're awesome. I wish I could be like you. > > Have you tried Scala? > > On Wed, Jul 8, 2015 at 4:25 AM, Stefan Reich < > stefan.reich.maker.of.eye at googlemail.com> wrote: > >> So you basically say that open sourcing is very good. It is :) I always >> work like this now, everything I do in my db (snippets.tinybrain.de) is >> versioned publicly. Basically, nothing ever breaks, with a little effort. >> >> On Tue, Jul 7, 2015 at 8:20 PM, David Gladstein >> wrote: >> >>> Regarding the time-varying importance of shit: >>> >>> A few years back Blender (www.blender.org) had a major release that >>> broke everything. The UI changed, so all the tutorials were suddenly wrong >>> As in, five minutes in you were lost, trying to find nonexistent panels on >>> your screen. I'd been trying to learn Blender off and on over the years, >>> and when I finally decided to make a serious run at it, it was impossible. >>> I gave up and came back a few more times, and finally the tutorials got >>> updated and I was off and running. >>> >>> I noticed a few aspects of Blender that were absolutely brilliant >>> compared to Maya. I wondered, that's so obviously the right thing, why >>> doesn't Autodesk do that in Maya? And then it hit me. They simply can't. >>> They get thousands of dollars per seat for their product, and studios >>> depend on it being backward-compatible. The studios are VERY conservative >>> about upgrading, they're often a release or two behind the ones everyone >>> else uses. Blender is free, and if you want any version since 1.0, it's >>> available. If you want all of them at once, you can have that. It's just a >>> program. Something broke for you in a certain version? Just use the version >>> that works. It's like version control, it doesn't prevent mistakes, but it >>> allows you to go back to when things were working. >>> >>> I'm pleased to note that the Haskell wiki has versions of the platform >>> going back five years, so hopefully we're in the position of making >>> well-thought-out breaking changes rather than maintaining compatibility >>> forever. >>> >>> (I have no idea what this thread is about, so forgive me if I'm coming >>> down on the wrong side of the argument. I like my story anyway.) >>> >>> On Tue, Jul 7, 2015 at 10:48 AM, Stefan Reich < >>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>> >>>> Just because you say this - doesn't make it true. I'm still saying the >>>> truth here. >>>> >>>> Cheers >>>> >>>> On Tue, Jul 7, 2015 at 7:45 PM, Gleb Popov <6yearold at gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jul 7, 2015 at 8:39 PM, Stefan Reich < >>>>> stefan.reich.maker.of.eye at googlemail.com> wrote: >>>>> >>>>>> Whatever "community" I go, they all pretend like their old shit is SO >>>>>> important. >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> If everyone around are bad, then the root of the problem is within >>>>> you, don't you think? >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Wed Jul 8 20:45:31 2015 From: mwm at mired.org (Mike Meyer) Date: Wed, 08 Jul 2015 20:45:31 +0000 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: > > JavaX is the answer. > I guess the question must have been "How can we minimize developer productivity?" > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Wed Jul 8 20:50:31 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 8 Jul 2015 22:50:31 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: Please explain. Are you insane or something? Am 08.07.2015 22:45 schrieb "Mike Meyer" : > JavaX is the answer. >> > > I guess the question must have been "How can we minimize developer > productivity?" > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Wed Jul 8 20:53:44 2015 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 8 Jul 2015 22:53:44 +0200 Subject: [Haskell-cafe] The Internet is insane Message-ID: They thumb up the shit and destroy the good stuff. I am really, seriously, interested how anyone can even try to explain how JavaX is supposedly worse (??) than Java. Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Wed Jul 8 21:00:42 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed, 8 Jul 2015 23:00:42 +0200 Subject: [Haskell-cafe] Announcing: monadic FRP using stm In-Reply-To: <559D7A42.8000906@gmail.com> References: <559D71E9.6060406@gmail.com> <559D7937.90507@gmail.com> <559D7A42.8000906@gmail.com> Message-ID: In my case I use transient for a different purpose. It is not intended for FRP specifically. The link is about a preliminary version. Now signals are generated by IO computations (that may wait for some input, for example, from the keyboard, a file download completion, a TVar update etc). 2015-07-08 21:30 GMT+02:00 Silvio Frischknecht : > sed -e "s_they_you" > > I see you're the same person :) > > Silvio > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Jul 8 21:14:20 2015 From: gershomb at gmail.com (Gershom B) Date: Wed, 8 Jul 2015 17:14:20 -0400 Subject: [Haskell-cafe] List Moderation Message-ID: Stefan Reich has been removed as a member from this list due to a stream of unapologetically off-topic posts. Best, Gershom From stefan.reich at secure-mail.cc Wed Jul 8 21:58:40 2015 From: stefan.reich at secure-mail.cc (Stefan Reich) Date: Wed, 08 Jul 2015 23:58:40 +0200 Subject: [Haskell-cafe] The evil of "mailing list removals" - and Microsoft-sponsored s**t ^^ Message-ID: <2188b7635db8a16fdb8a443a0413bed8@mail.secure-mail.biz> An HTML attachment was scrubbed... URL: From stefan.reich at secure-mail.cc Wed Jul 8 22:03:30 2015 From: stefan.reich at secure-mail.cc (Stefan Reich) Date: Thu, 09 Jul 2015 00:03:30 +0200 Subject: [Haskell-cafe] They scrubbed my link?? Message-ID: <88159bec87b81249de374a9cfac3043d@mail.secure-mail.biz> An HTML attachment was scrubbed... URL: From stefan.reich at secure-mail.cc Wed Jul 8 22:04:40 2015 From: stefan.reich at secure-mail.cc (Stefan Reich) Date: Thu, 09 Jul 2015 00:04:40 +0200 Subject: [Haskell-cafe] tinybrain.blog.de/2015/07/08/the-evil-of-mailing-list-removals-20645305/ Message-ID: An HTML attachment was scrubbed... URL: From spam at scientician.net Wed Jul 8 23:26:34 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 9 Jul 2015 01:26:34 +0200 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: On 07/08/2015 10:50 PM, Stefan Reich wrote: > Please explain. Are you insane or something? > Am 08.07.2015 22:45 schrieb "Mike Meyer" : > >> JavaX is the answer. >>> >> >> I guess the question must have been "How can we minimize developer >> productivity?" >> Guys/gals, can we please just end this thread? Don't feed the...? From spam at scientician.net Wed Jul 8 23:27:38 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 9 Jul 2015 01:27:38 +0200 Subject: [Haskell-cafe] List Moderation In-Reply-To: References: Message-ID: On 07/08/2015 11:14 PM, Gershom B wrote: > Stefan Reich has been removed as a member from this list due to a stream of unapologetically off-topic posts. > Thank you. (Not that I asked for it, but c'mon...) From marcin.jan.mrotek at gmail.com Wed Jul 8 23:38:14 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 9 Jul 2015 01:38:14 +0200 Subject: [Haskell-cafe] List Moderation In-Reply-To: References: Message-ID: +1 From cma at bitemyapp.com Wed Jul 8 23:42:04 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 8 Jul 2015 18:42:04 -0500 Subject: [Haskell-cafe] List Moderation In-Reply-To: References: Message-ID: +1 On Wed, Jul 8, 2015 at 6:27 PM, Bardur Arantsson wrote: > On 07/08/2015 11:14 PM, Gershom B wrote: > > Stefan Reich has been removed as a member from this list due to a stream > of unapologetically off-topic posts. > > > > Thank you. > > (Not that I asked for it, but c'mon...) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Jul 9 01:03:04 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 9 Jul 2015 11:03:04 +1000 Subject: [Haskell-cafe] The evil of "mailing list removals" - and Microsoft-sponsored s**t ^^ In-Reply-To: <2188b7635db8a16fdb8a443a0413bed8@mail.secure-mail.biz> References: <2188b7635db8a16fdb8a443a0413bed8@mail.secure-mail.biz> Message-ID: On 9 July 2015 at 07:58, Stefan Reich wrote: > http://tinybrain.blog.de/2015/07/08/the-evil-of-mailing-list-removals-20645305/ I don't see anything in there about Microsoft... ... or how your blog post (let alone your recent mailings on this list) have anything to do with the subject matter of this list... > Cheers wrong guys Just to be clear: are you only cheering on the "wrong guys" (defined by some unspecified criteria of yours) or are you calling all of us "wrong guys" just because we don't adhere to some unspecified criteria of yours? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From leza.ml at fecrd.cujae.edu.cu Thu Jul 9 01:12:07 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Wed, 8 Jul 2015 21:12:07 -0400 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559B0F5A.7000802@gmail.com> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> <559AD0EE.7050604@gmail.com> <559AD4EB.1@fecrd.cujae.edu.cu> <559B0F5A.7000802@gmail.com> Message-ID: <559DCA67.3010902@fecrd.cujae.edu.cu> On 07/06/2015 07:29 PM, Silvio Frischknecht wrote: > looks like the problem are the 'e's. you can see it from > > Could not deduce (TFunOut t1 e ~ TFunOut t1 e0) > > the e0 comes from the output of TFunIn/TFunOut and the instance does not > know that it is the same as the e variable you use. > > I don't know exactly what your program does. but if e is just a > phantom/security parameter you can do it like this. > > type family TFunIn t :: * -> * > > type instance TFunIn IdT = Signal > > type instance TFunIn (ComposeT t1 t2) = TFunIn t2 > > instance (SignalT t1 e, SignalT t2 e, TFunOut t2 ~ TFunIn t1) > => SignalT (ComposeT t1 t2) e where > transform _ x = (transform (undefined :: t1) . > transform (undefined :: t2)) x > > > Otherwise you will have to find a way to prove that the 'e's are the same > > Cheers Silvio > Hi Silvio, The `e` type is important. The problem with not including `e` in the `TFunIn` is that I will want to define: type instance TFunIn DoubleT e = (Signal e, Signal e) which I cannot express without specifying the `e` type parameter. And it cannot be a closed type family. So what can I prove that the `e`s are the same? The intuition I get from the instance declaration is that "they/it" are the same: instance (SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e) => SignalT (ComposeT t1 t2) e where transform _ x = (transform (undefined :: t1) . transform (undefined :: t2)) x Thanks. -- Leza Morais Lutonda, Lemol-C http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From eir at cis.upenn.edu Thu Jul 9 01:14:41 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Wed, 8 Jul 2015 21:14:41 -0400 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: I think GADTs are a red herring here -- this is the classic show/read ambiguity dressed up. In the code below, how should GHC determine the type of e1' or e2'? There's no way to know. Richard On Jul 7, 2015, at 12:05 PM, wren romano wrote: > On Tue, Jul 7, 2015 at 3:35 AM, Simon Peyton Jones > wrote: >> If you post a repro case someone (even me) might help. The devil is always in the details. > > The smallest repro I can come up with (which is still related to the > actual problem) is as follows. In case it matters for the solution, > there are a number of important bits I've erased. Most importantly, > the inferType function is actually mutually recursive with a checkType > function, though that doesn't seem to be the cause of the problem. > > > {-# LANGUAGE DataKinds, PolyKinds, GADTs #-} > > data Type = Fun Type Type > > data Sing :: Type -> * where > SFun :: Sing i -> Sing j -> Sing (Fun i j) > > data AST :: (Type -> *) -> Type -> * where > App :: ast (Fun a b) -> ast a -> AST ast b > > class ABT (abt :: Type -> *) where > view :: abt a -> AST abt a > unview :: AST abt a -> abt a > > class WellTypedABT (abt :: Type -> *) where > unviewWT :: Sing a -> AST abt a -> abt a > typeOf :: abt a -> Sing a > > data TypeCheckMonad a = TCM { unTCM :: a } > > instance Functor TypeCheckMonad where > fmap f = TCM . f . unTCM > > instance Applicative TypeCheckMonad where > pure = TCM > TCM f <*> TCM x = TCM (f x) > > instance Monad TypeCheckMonad where > return = pure > TCM x >>= k = k x > > inferType > :: (ABT abt, WellTypedABT abt') > => abt a > -> TypeCheckMonad (abt' a) > inferType e0 = > case view e0 of > App e1 e2 -> do > e1' <- inferType e1 > case typeOf e1' of > SFun typ2 typ3 -> do > e2' <- inferType e2 > return . unviewWT typ3 $ App e1' e2' > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From amindfv at gmail.com Thu Jul 9 01:57:10 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 8 Jul 2015 21:57:10 -0400 Subject: [Haskell-cafe] The evil of "mailing list removals" - and Microsoft-sponsored s**t ^^ In-Reply-To: References: <2188b7635db8a16fdb8a443a0413bed8@mail.secure-mail.biz> Message-ID: <7962E515-BB5C-4A35-B1CE-98066166400F@gmail.com> Plz don't engage, yall El Jul 8, 2015, a las 21:03, Ivan Lazar Miljenovic escribi?: > On 9 July 2015 at 07:58, Stefan Reich wrote: >> http://tinybrain.blog.de/2015/07/08/the-evil-of-mailing-list-removals-20645305/ > > I don't see anything in there about Microsoft... > > ... or how your blog post (let alone your recent mailings on this > list) have anything to do with the subject matter of this list... > >> Cheers wrong guys > > Just to be clear: are you only cheering on the "wrong guys" (defined > by some unspecified criteria of yours) or are you calling all of us > "wrong guys" just because we don't adhere to some unspecified criteria > of yours? > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From briand at aracnet.com Thu Jul 9 03:02:37 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Wed, 8 Jul 2015 20:02:37 -0700 Subject: [Haskell-cafe] You know, I am tired of it. In-Reply-To: References: Message-ID: <20150708200237.6b54e679@cedar.deldotd.com> On Thu, 9 Jul 2015 01:26:34 +0200 Bardur Arantsson wrote: > On 07/08/2015 10:50 PM, Stefan Reich wrote: > > Please explain. Are you insane or something? > > Am 08.07.2015 22:45 schrieb "Mike Meyer" : > > > >> JavaX is the answer. > >>> > >> > >> I guess the question must have been "How can we minimize developer > >> productivity?" > >> > > Guys/gals, can we please just end this thread? Don't feed the...? > > What are you trying to say ? That you are, you know, tired of it ? From silvio.frischi at gmail.com Thu Jul 9 03:30:58 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 09 Jul 2015 05:30:58 +0200 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559DCA67.3010902@fecrd.cujae.edu.cu> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> <559AD0EE.7050604@gmail.com> <559AD4EB.1@fecrd.cujae.edu.cu> <559B0F5A.7000802@gmail.com> <559DCA67.3010902@fecrd.cujae.edu.cu> Message-ID: <559DEAF2.4060106@gmail.com> > type instance TFunIn DoubleT e = (Signal e, Signal e) I give up. I'm not sure it's possible to tell to the compiler that when using transform function (the IdT version in the implementation of ComposeT) that it should use the one with the same e. Not sure it's possible. Anyway a workaround would be. class SignalT t e where transform :: e -> t -> TFunIn t e -> TFunOut t e instance ( SignalT t1 e, SignalT t2 e, TFunOut t2 e ~ TFunIn t1 e ) => SignalT (ComposeT t1 t2) e where transform _ _ x = (transform (undefined :: e) (undefined :: t1)) (transform (undefined :: e) (undefined :: t2)) (x :: TFunIn (ComposeT t1 t2) e) But you could save your self a lot of hurt by just using newtype DoubleSignal a = DoubleSignal (Signal a, Signal a) you could even remove the e from the SignalT class. Silvio From leza.ml at fecrd.cujae.edu.cu Thu Jul 9 04:40:17 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Thu, 9 Jul 2015 00:40:17 -0400 Subject: [Haskell-cafe] Problems with type families In-Reply-To: <559DEAF2.4060106@gmail.com> References: <559AB8CD.2020003@fecrd.cujae.edu.cu> <559AC496.3060406@fecrd.cujae.edu.cu> <559AD0EE.7050604@gmail.com> <559AD4EB.1@fecrd.cujae.edu.cu> <559B0F5A.7000802@gmail.com> <559DCA67.3010902@fecrd.cujae.edu.cu> <559DEAF2.4060106@gmail.com> Message-ID: <559DFB31.3060603@fecrd.cujae.edu.cu> On 07/08/2015 11:30 PM, Silvio Frischknecht wrote: > Anyway a workaround would be. > > class SignalT t e > where > transform :: e -> t -> TFunIn t e -> TFunOut t e > > instance ( > SignalT t1 e, > SignalT t2 e, > TFunOut t2 e ~ TFunIn t1 e > ) => SignalT (ComposeT t1 t2) e > where > transform _ _ x = > (transform (undefined :: e) (undefined :: t1)) > (transform (undefined :: e) (undefined :: t2)) > (x :: TFunIn (ComposeT t1 t2) e) > I got it! This solution is nice for me, and helped me to understand how to tell the compiler about the `e` type. Thank you Silvio! -- Leza Morais Lutonda, Lemol-C http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Jul 9 08:12:53 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 9 Jul 2015 09:12:53 +0100 Subject: [Haskell-cafe] [GHC 7.8.4] IO Monad leak space? In-Reply-To: References: <20150703214145.GG6716@weber> Message-ID: <20150709081253.GJ14634@weber> On Sat, Jul 04, 2015 at 06:17:06AM +0000, Baojun Wang wrote: > Appreciate for the prompt reply, sorry for that I assumed the allocations > was caused by space leak. I guess profiling with -auto-all really has huge > impact on allocations. without profiling, haskell version runs about 50% > slower than equivalent C version (both with -O2). Maybe that's as much as > one could expect. 50% sounds like a good start, but I bet with some time and effort you can substantially improve on it. Specifically, the code is spending *loads* of time doing bounds checking. It checks on every array read and write. I suggest (for an experiment, not production code!) you replace the reads and writes with unsafe versions and see what speedup that gives you. I don't know how to do unsafe reads and writes with the array library, but for vectors the API is here: http://hackage.haskell.org/package/vector-0.10.12.3/docs/Data-Vector-Mutable.html#g:10 Tom From bogus@does.not.exist.com Thu Jul 9 14:30:25 2015 From: bogus@does.not.exist.com () Date: Thu, 09 Jul 2015 14:30:25 -0000 Subject: [Haskell-cafe] (no subject) Message-ID: From guillaumh at gmail.com Thu Jul 9 17:04:10 2015 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Thu, 9 Jul 2015 14:04:10 -0300 Subject: [Haskell-cafe] darcs 2.10.1 release Message-ID: Hi all, The darcs team is pleased to announce the release of darcs 2.10.1 ! # Downloading # The easiest way to install darcs 2.10.1 from source is by first installing the Haskell Platform (http://www.haskell.org/platform). If you have installed the Haskell Platform or cabal-install, you can install this release by doing: $ cabal update $ cabal install darcs-2.10.1 Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.10.1.tar.gz and build it by hand as explained in the README file. The 2.10 branch is also available as a darcs repository from http://darcs.net/releases/branch-2.10 # What's new in 2.10.1 (since 2.10.0) # - generalized doFastZip for darcsden support - support terminfo 0.4, network 2.6, zlib 0.6, quickcheck 2.8 and attoparsec 0.13 - errorDoc now prints a stack trace (if profiling was enabled) (Ben Franksen) - beautified error messages for command line and default files (Ben Franksen) - fixed the following bugs: - issue2449: test harness/shelly: need to handle mis-encoded/binary data (Ganesh Sittampalam) - issue2423: diff only respecting --diff-command when a diff.exe is present (Alain91) - issue2447: get contents of deleted file (Ben Franksen) - issue2307: add information about 'darcs help manpage' and 'darcs help markdown' (Dan Frumin) - issue2461: darcs log --repo=remoterepo creates and populates _darcs (Ben Franksen) - issue2459: cloning remote repo fails to use packs if cache is on a different partition (Ben Franksen) # Feedback # If you have an issue with darcs 2.10.0, you can report it on http://bugs.darcs.net/ . You can also report bugs by email to bugs at darcs.net, or come to #darcs on irc.freenode.net. # Known issues # - issue2269: rebase should warn about stolen patches at suspend, not unsuspend - issue2272: darcs rebase unsuspend should automate or semi-automate handling unrecorded changes - issue2276: darcs rebase unsuspend needs UI improvements for "You are not... Amend anyway?" - issue2359: convert --export mishandles Unicode filenames - issue2372: Please remove "HINT: I could not reach..." message - issue2436: rollback --patches takes ages before first prompt - issue2445: internal error if suspended patch is pulled into repository again From ben.gunton at gmail.com Thu Jul 9 20:17:50 2015 From: ben.gunton at gmail.com (Ben Gunton) Date: Thu, 9 Jul 2015 14:17:50 -0600 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls Message-ID: This is a simplified version of an issue I'm running into when timing some functions. In this example, the first putStr inside the replicateM_ takes far longer than subsequent putStrs. If I add in a putStr at the top (the commented line), each iteration takes the same. (Though I presume I just shifted the long execution to the putStr on top). The same thing happens on the first iterations of a function when I need to evaluate some state, or deepseq some value. putStr was just a simpler version that still showed the same issue. Relevant code: http://lpaste.net/136250 What's going on here? Thanks! import Control.Monadimport Data.Time.Clock main :: IO ()main = do -- putStr "" replicateM_ 5 $ do t1 <- getCurrentTime putStr "" t2 <- getCurrentTime print . round $ 1000 * 1000 * diffUTCTime t2 t1 {- Sample output: 49 1 1 1 2 -} -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Jul 9 20:24:13 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 9 Jul 2015 16:24:13 -0400 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 4:17 PM, Ben Gunton wrote: > In this example, the first putStr inside the replicateM_ takes far longer > than subsequent putStrs. If I add in a putStr at the top (the commented > line), each iteration takes the same. (Though I presume I just shifted the > long execution to the putStr on top). If I had to guess, delayed setup of the Handle associated with stdout. This will include setting up buffering (including querying the OS to find out whether output is a tty-like device or not, so as to enable or disable block buffering; note that this may be especially expensive on Windows, where there is IIRC no simple way to determine whether running in e.g. a cmd.exe window or not, as the OS has no concept of pseudo-ttys); also, setting up output encoding and such. Probably also other details. -- 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 ben.gunton at gmail.com Thu Jul 9 20:26:59 2015 From: ben.gunton at gmail.com (Ben Gunton) Date: Thu, 9 Jul 2015 14:26:59 -0600 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: References: Message-ID: The thing is, if I switch the "putStr """ in the replicateM to "evaluate $ force t1", the first iteration still takes way longer. Are there things to setup even with that? Is there a way to pre-setup all the things that need to be setup? This is also on Linux, with GHC 7.10.1, and no optimizations. On Thu, Jul 9, 2015 at 2:24 PM, Brandon Allbery wrote: > On Thu, Jul 9, 2015 at 4:17 PM, Ben Gunton wrote: > >> In this example, the first putStr inside the replicateM_ takes far longer >> than subsequent putStrs. If I add in a putStr at the top (the commented >> line), each iteration takes the same. (Though I presume I just shifted the >> long execution to the putStr on top). > > > If I had to guess, delayed setup of the Handle associated with stdout. > This will include setting up buffering (including querying the OS to find > out whether output is a tty-like device or not, so as to enable or disable > block buffering; note that this may be especially expensive on Windows, > where there is IIRC no simple way to determine whether running in e.g. a > cmd.exe window or not, as the OS has no concept of pseudo-ttys); also, > setting up output encoding and such. Probably also other details. > > -- > 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 ben.gunton at gmail.com Thu Jul 9 21:07:44 2015 From: ben.gunton at gmail.com (Ben Gunton) Date: Thu, 9 Jul 2015 15:07:44 -0600 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: References: Message-ID: Here is the same thing with no console usage, just forcing the time value. The first-iteration-delay seems to happen at the first IO-ish thing being evaluated. http://lpaste.net/136254 On Thu, Jul 9, 2015 at 2:26 PM, Ben Gunton wrote: > The thing is, if I switch the "putStr """ in the replicateM to "evaluate $ > force t1", the first iteration still takes way longer. Are there things to > setup even with that? Is there a way to pre-setup all the things that need > to be setup? > > This is also on Linux, with GHC 7.10.1, and no optimizations. > > On Thu, Jul 9, 2015 at 2:24 PM, Brandon Allbery > wrote: > >> On Thu, Jul 9, 2015 at 4:17 PM, Ben Gunton wrote: >> >>> In this example, the first putStr inside the replicateM_ takes far >>> longer than subsequent putStrs. If I add in a putStr at the top (the >>> commented line), each iteration takes the same. (Though I presume I just >>> shifted the long execution to the putStr on top). >> >> >> If I had to guess, delayed setup of the Handle associated with stdout. >> This will include setting up buffering (including querying the OS to find >> out whether output is a tty-like device or not, so as to enable or disable >> block buffering; note that this may be especially expensive on Windows, >> where there is IIRC no simple way to determine whether running in e.g. a >> cmd.exe window or not, as the OS has no concept of pseudo-ttys); also, >> setting up output encoding and such. Probably also other details. >> >> -- >> 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 omeragacan at gmail.com Thu Jul 9 21:45:22 2015 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 9 Jul 2015 17:45:22 -0400 Subject: [Haskell-cafe] idea: -latest URLs for Hackage Message-ID: It's very convenient to have a persistent URL linked to latest version. GHC user manual has this(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/) and you can create a bookmark with that URL and it stays up-to-date, it appears in first place in Google queries etc. I'm wondering why not implement this for Hackage too? For example, hackage.haskell.org/package/base-latest, hackage.haskell.org/package/base-latest/docs/.html etc. Any ideas? From tikhon at jelv.is Thu Jul 9 21:54:57 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 9 Jul 2015 14:54:57 -0700 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: References: Message-ID: I believe Hackage already supports urls like that if you leave the version out: http://hackage.haskell.org/package/base/docs/Control-Monad.html This automatically redirects you to the latest version. The problem, then, is visibility both to users and to Google. Since it's an actual redirect, your URL bar will show the specific version when you follow the link. The version number will also show up if you copy the URL from one of the links on the contents page even if you got there without specifying a version. (By following http://hackage.haskell.org/package/base for example.) I'm not sure if this is an intentional design or just a quirk of the implementation. One thing to keep in mind: how would you handle "latest" URLs for modules that have since been removed from the package? Presumably, we'd still want something showing up in Google results or if people follow an old link, after all. On Jul 9, 2015 2:46 PM, "?mer Sinan A?acan" wrote: > It's very convenient to have a persistent URL linked to latest > version. GHC user manual has > this(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/) > and you can create a bookmark with that URL and it stays up-to-date, > it appears in first place in Google queries etc. > > I'm wondering why not implement this for Hackage too? For example, > hackage.haskell.org/package/base-latest, > hackage.haskell.org/package/base-latest/docs/.html etc. > > Any ideas? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.kolera at gmail.com Thu Jul 9 21:56:12 2015 From: ben.kolera at gmail.com (Ben Kolera) Date: Thu, 09 Jul 2015 21:56:12 +0000 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: References: Message-ID: This is already possible with hackage, I believe. See: https://hackage.haskell.org/package/base https://hackage.haskell.org/package/lens Cheers, Ben On Fri, 10 Jul 2015 at 07:46 ?mer Sinan A?acan wrote: > It's very convenient to have a persistent URL linked to latest > version. GHC user manual has > this(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/) > and you can create a bookmark with that URL and it stays up-to-date, > it appears in first place in Google queries etc. > > I'm wondering why not implement this for Hackage too? For example, > hackage.haskell.org/package/base-latest, > hackage.haskell.org/package/base-latest/docs/.html etc. > > Any ideas? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Jul 9 21:56:46 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 9 Jul 2015 17:56:46 -0400 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: References: Message-ID: On Thu, Jul 9, 2015 at 5:54 PM, Tikhon Jelvis wrote: > The problem, then, is visibility both to users and to Google. Since it's > an actual redirect, your URL bar will show the specific version when you > follow the link. The version number will also show up if you copy the URL > from one of the links on the contents page even if you got there without > specifying a version. (By following > http://hackage.haskell.org/package/base > > for example.) > > My understanding is that Hackage is using a link tag that Google claims should work... but in practice does not. I think latest urls are being actively considered as an alternative, if I understood the discussion properly. -- 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 roma at ro-che.info Thu Jul 9 23:45:21 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 10 Jul 2015 02:45:21 +0300 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: References: Message-ID: <559F0791.1040608@ro-che.info> This is a nice puzzle. However, I don't think it's related to IO. So far I've traced this to Data.Fixed methods. If you add evaluate $ floor (2/1 :: Fixed E12) before the loop, you'll find that the delay decreases significantly (although doesn't vanish entirely). How is this related to forcing a time value? Well, UTCTime represents the time of day as Fixed E12, and when you're evaluating the result of getCurrentTime, you're calling those methods, (/) and floor. Using other methods of Fixed E12 before the loop, or replacing E12 with E9, kills or at least hurts the effect. There might be some thunks referenced directly or indirectly by those methods, possibly involving specialization, but I don't see it so far. I'll let someone else to take it from here. On 10/07/15 00:07, Ben Gunton wrote: > Here is the same thing with no console usage, just forcing the time > value. The first-iteration-delay seems to happen at the first IO-ish > thing being evaluated. > > http://lpaste.net/136254 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From genial at alva.ro Fri Jul 10 00:23:43 2015 From: genial at alva.ro (Alvaro J. Genial) Date: Thu, 9 Jul 2015 20:23:43 -0400 Subject: [Haskell-cafe] [ANN] base91 Message-ID: Howdy, I'd like to announce a first version of base91 , a Haskell package to enable the encoding and decoding of data in Base91 format, as documented in its specification . The main benefits of said scheme are a good reduction in overhead (from 31% up to 58%) when compared to Base64 due to the clever use of two printable ASCII characters (consuming 16 bits) to encode 13 arbitrary bits, as well as neither need for nor ambiguity over padding or alphabets. It includes support for... - Plain Strings (module Codec.Binary.Base91.String) - Data.ByteString (module Codec.Binary.Base91.ByteString) - Data.Text (module Codec.Binary.Base91.Text) - The latter two combined (module Codec.Binary.Base91.Efficient) - Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy) - Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy) - The latter two combined (module Codec.Binary.Base91.Efficient.Lazy) ...which are all just concretely typed versions of the generic implementation in Codec.Binary.Base91. I had fun exploring some of the latest GHC extensions, as evidenced by Codec.Binary.Base91.Control, which relies on a certain amount of type trickery to reconcile the incongruence between monomorphic containers and the standard type classes. Anyway, suggestions are very welcome. In particular, I'm interested in: 1. Whether the generic decode and encode signatures can be simplified or improved elsehow. 2. Whether there already exist classes similar in purpose to Applicative' and Foldable'. 3. Whether it makes sense to offer decode and encode variants that use lazy (left) folds--currently folding is always strict, even with lazy types. (Testing comes nearly free courtesy of QuickCheck and the identity property of decode . encode, plus a couple of concrete examples. Please open an issue or otherwise let me know if you find a bug.) Thank you, Alvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.gunton at gmail.com Fri Jul 10 01:34:31 2015 From: ben.gunton at gmail.com (Ben Gunton) Date: Thu, 9 Jul 2015 19:34:31 -0600 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: <559F0791.1040608@ro-che.info> References: <559F0791.1040608@ro-che.info> Message-ID: When a module is imported, or used for the first time, are there things that are not fully evaluated? I see the same thing you do with the Data.Fixed methods (nice work by the way!), but I also see similar (albeit less drastic) behaviour with other datatypes, including some custom ones. It just always seems like the first call to a modules method is always slower than subsequent calls. But I can't for the life of me figure out why... On Thu, Jul 9, 2015 at 5:45 PM, Roman Cheplyaka wrote: > This is a nice puzzle. However, I don't think it's related to IO. > > So far I've traced this to Data.Fixed methods. If you add > > evaluate $ floor (2/1 :: Fixed E12) > > before the loop, you'll find that the delay decreases significantly > (although doesn't vanish entirely). > > How is this related to forcing a time value? Well, UTCTime represents > the time of day as Fixed E12, and when you're evaluating the result of > getCurrentTime, you're calling those methods, (/) and floor. > > Using other methods of Fixed E12 before the loop, or replacing E12 with > E9, kills or at least hurts the effect. > > There might be some thunks referenced directly or indirectly by those > methods, possibly involving specialization, but I don't see it so far. > > I'll let someone else to take it from here. > > > On 10/07/15 00:07, Ben Gunton wrote: > > Here is the same thing with no console usage, just forcing the time > > value. The first-iteration-delay seems to happen at the first IO-ish > > thing being evaluated. > > > > http://lpaste.net/136254 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri Jul 10 06:23:49 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 10 Jul 2015 09:23:49 +0300 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: References: <559F0791.1040608@ro-che.info> Message-ID: <559F64F5.7080208@ro-che.info> On 10/07/15 04:34, Ben Gunton wrote: > When a module is imported, or used for the first time, are there things > that are not fully evaluated? Evaluation isn't tied to modules in any way. Modules are namespaces; they are strictly compile-time entities. Imagine that in your module you define at the top level fac10 :: Integer fac10 = product [1..10] This is known as CAF, a constant applicative form. If you never demand the value of fac10 in your program, it will never get evaluated. If you do demand the value of fac10, it will be evaluated the first time, and then fac10 will be modified to point to the actual value instead of a thunk, so all the subsequent calls will be much faster. Now, I suspect that there may be something like fac10 in Data.Fixed or perhaps one of its dependencies. It doesn't even have to be defined in the code: during optimization, a lot of things become CAFs when ghc finds something that looks like a constant and floats it out to the top level. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From will.yager at gmail.com Fri Jul 10 07:01:28 2015 From: will.yager at gmail.com (William Yager) Date: Fri, 10 Jul 2015 00:01:28 -0700 Subject: [Haskell-cafe] Confusion with GeneralizedNewtypeDeriving + MultiParamTypeClasses Message-ID: Hello all, I have run into a bit of a strange case where I can't get `GeneralizedNewtypeDeriving` to work as I'd like. In the `vector` package, under `Data.Vector.Generic`, there is a generic vector typeclass of the form `Vector v a`, where `v` is the vector type and `a` is the type of items in the vector. I have a newtype wrapper of the form `newtype Neuron a = Neuron (Vector a)`. (Note that "Vector" here is a type "Vector", not the two-parameter constraint also called "Vector".) I would like to be able to use everything in `Data.Vector.Generic` on `Neuron`s. Using `GeneralizedNewtypeDeriving`, I immediately run up against the issue that the `Vector` typeclass doesn't have the correct form of `* -> Constraint`. According to section 7.5.5.1 of https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/deriving.html , we should be able to derive instances of multi-parameter type classes, provided the newtype is the last parameter of the typeclass. The problem here is that it's the first parameter. Using `ConstraintKinds` to make a constraint synonym (of the form `FlippedVectorClass a v`) so that I can do something like `newtype Neuron a = Neuron (Vector a) deriving (FlippedVectorClass a)` also doesn't seem to work. Does anyone have any advice for how to make this work? It's quite tempting just to make `type Neuron a = Vector a`, but I'd rather do a proper wrapper type. Cheers, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From anselm.scholl at tu-harburg.de Fri Jul 10 07:17:24 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Fri, 10 Jul 2015 09:17:24 +0200 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: <559F0791.1040608@ro-che.info> References: <559F0791.1040608@ro-che.info> Message-ID: <559F7184.60701@tu-harburg.de> If you look at the Fixed data type, it is implemented using the Integer type, which is again implemented using libgmp on my system. The first call to any function involving an Integer type thus needs to initialize libgmp first. Using ltrace it seems like libgmp first has to determine the processor it is running on and maybe set up other bookkeeping information. It could also be the case that libgmp itself has to be loaded at this point. Using strace it looks like it is mmapped into the memory, maybe linux is lazy and only reads the file on the disk at the moment it is accessed the first time (i.e. at the first call)? At least linux uses a similar approach for requested memory by a program. On 07/10/2015 01:45 AM, Roman Cheplyaka wrote: > This is a nice puzzle. However, I don't think it's related to IO. > > So far I've traced this to Data.Fixed methods. If you add > > evaluate $ floor (2/1 :: Fixed E12) > > before the loop, you'll find that the delay decreases significantly > (although doesn't vanish entirely). > > How is this related to forcing a time value? Well, UTCTime represents > the time of day as Fixed E12, and when you're evaluating the result of > getCurrentTime, you're calling those methods, (/) and floor. > > Using other methods of Fixed E12 before the loop, or replacing E12 with > E9, kills or at least hurts the effect. > > There might be some thunks referenced directly or indirectly by those > methods, possibly involving specialization, but I don't see it so far. > > I'll let someone else to take it from here. > > > On 10/07/15 00:07, Ben Gunton wrote: >> Here is the same thing with no console usage, just forcing the time >> value. The first-iteration-delay seems to happen at the first IO-ish >> thing being evaluated. >> >> http://lpaste.net/136254 > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From roma at ro-che.info Fri Jul 10 07:31:21 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 10 Jul 2015 10:31:21 +0300 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: <559F7184.60701@tu-harburg.de> References: <559F0791.1040608@ro-che.info> <559F7184.60701@tu-harburg.de> Message-ID: <559F74C9.4050601@ro-che.info> I considered that, but it doesn't seem to hold up. If you replace calling the Fixed functions with some operations on Integers, you won't reproduce the effect. On 10/07/15 10:17, Jonas Scholl wrote: > If you look at the Fixed data type, it is implemented using the Integer > type, which is again implemented using libgmp on my system. The first > call to any function involving an Integer type thus needs to initialize > libgmp first. Using ltrace it seems like libgmp first has to determine > the processor it is running on and maybe set up other bookkeeping > information. > > It could also be the case that libgmp itself has to be loaded at this > point. Using strace it looks like it is mmapped into the memory, maybe > linux is lazy and only reads the file on the disk at the moment it is > accessed the first time (i.e. at the first call)? At least linux uses a > similar approach for requested memory by a program. > > On 07/10/2015 01:45 AM, Roman Cheplyaka wrote: >> This is a nice puzzle. However, I don't think it's related to IO. >> >> So far I've traced this to Data.Fixed methods. If you add >> >> evaluate $ floor (2/1 :: Fixed E12) >> >> before the loop, you'll find that the delay decreases significantly >> (although doesn't vanish entirely). >> >> How is this related to forcing a time value? Well, UTCTime represents >> the time of day as Fixed E12, and when you're evaluating the result of >> getCurrentTime, you're calling those methods, (/) and floor. >> >> Using other methods of Fixed E12 before the loop, or replacing E12 with >> E9, kills or at least hurts the effect. >> >> There might be some thunks referenced directly or indirectly by those >> methods, possibly involving specialization, but I don't see it so far. >> >> I'll let someone else to take it from here. >> >> >> On 10/07/15 00:07, Ben Gunton wrote: >>> Here is the same thing with no console usage, just forcing the time >>> value. The first-iteration-delay seems to happen at the first IO-ish >>> thing being evaluated. >>> >>> http://lpaste.net/136254 >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nikita at karetnikov.org Fri Jul 10 07:48:40 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Fri, 10 Jul 2015 10:48:40 +0300 Subject: [Haskell-cafe] Confusion with GeneralizedNewtypeDeriving + MultiParamTypeClasses In-Reply-To: (William Yager's message of "Fri, 10 Jul 2015 00:01:28 -0700") References: Message-ID: <87fv4wzc4n.fsf@karetnikov.org> > Does anyone have any advice for how to make this work? It's quite tempting > just to make `type Neuron a = Vector a`, but I'd rather do a proper wrapper > type. Here's my attempt (no, I didn't succeed): {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE ExistentialQuantification #-} import qualified Data.Vector.Generic as Generic import Data.Vector newtype Neuron a = Neuron (Vector a) --deriving instance (Generic.Vector Neuron a) -- Can't make a derived instance of ?Generic.Vector Neuron a?: -- The last argument of the instance must be a data or newtype application -- In the stand-alone deriving instance for ?Generic.Vector Neuron a? newtype Any a = Any a --deriving instance (Generic.Vector Neuron (Any a)) {- Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] Var/Type length mismatch: [a_aGM] [] ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): tcTyVarDetails a_aGM Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -} -- data Foo = Foo -- deriving instance (Generic.Vector Neuron Foo) -- Ditto. -- data Bar = forall a. Bar a -- deriving instance (Generic.Vector Neuron Bar) -- Same error. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From agocorona at gmail.com Fri Jul 10 08:37:50 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 10 Jul 2015 10:37:50 +0200 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: <559F74C9.4050601@ro-che.info> References: <559F0791.1040608@ro-che.info> <559F7184.60701@tu-harburg.de> <559F74C9.4050601@ro-che.info> Message-ID: the C allocation functions (malloc etc) spend significantly more time in the first invocation. That may be related with this behaviour in libgmp, IO etc 2015-07-10 9:31 GMT+02:00 Roman Cheplyaka : > I considered that, but it doesn't seem to hold up. If you replace > calling the Fixed functions with some operations on Integers, you won't > reproduce the effect. > > On 10/07/15 10:17, Jonas Scholl wrote: > > If you look at the Fixed data type, it is implemented using the Integer > > type, which is again implemented using libgmp on my system. The first > > call to any function involving an Integer type thus needs to initialize > > libgmp first. Using ltrace it seems like libgmp first has to determine > > the processor it is running on and maybe set up other bookkeeping > > information. > > > > It could also be the case that libgmp itself has to be loaded at this > > point. Using strace it looks like it is mmapped into the memory, maybe > > linux is lazy and only reads the file on the disk at the moment it is > > accessed the first time (i.e. at the first call)? At least linux uses a > > similar approach for requested memory by a program. > > > > On 07/10/2015 01:45 AM, Roman Cheplyaka wrote: > >> This is a nice puzzle. However, I don't think it's related to IO. > >> > >> So far I've traced this to Data.Fixed methods. If you add > >> > >> evaluate $ floor (2/1 :: Fixed E12) > >> > >> before the loop, you'll find that the delay decreases significantly > >> (although doesn't vanish entirely). > >> > >> How is this related to forcing a time value? Well, UTCTime represents > >> the time of day as Fixed E12, and when you're evaluating the result of > >> getCurrentTime, you're calling those methods, (/) and floor. > >> > >> Using other methods of Fixed E12 before the loop, or replacing E12 with > >> E9, kills or at least hurts the effect. > >> > >> There might be some thunks referenced directly or indirectly by those > >> methods, possibly involving specialization, but I don't see it so far. > >> > >> I'll let someone else to take it from here. > >> > >> > >> On 10/07/15 00:07, Ben Gunton wrote: > >>> Here is the same thing with no console usage, just forcing the time > >>> value. The first-iteration-delay seems to happen at the first IO-ish > >>> thing being evaluated. > >>> > >>> http://lpaste.net/136254 > >> > >> > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edwards.benj at gmail.com Fri Jul 10 12:10:29 2015 From: edwards.benj at gmail.com (Benjamin Edwards) Date: Fri, 10 Jul 2015 12:10:29 +0000 Subject: [Haskell-cafe] [ANN] base91 In-Reply-To: References: Message-ID: Suggestion: I notice that you are using indexing into a list as a lookup table, you might want to switch to a vector + unsafe reads in the efficient version Ben On Fri, 10 Jul 2015 at 01:24 Alvaro J. Genial wrote: > Howdy, > > I'd like to announce a first version of base91 > , a Haskell package to enable > the encoding and decoding of data in Base91 format, as documented in its > specification . The main benefits of said > scheme are a good reduction in overhead (from 31% up to 58%) when compared > to Base64 due to the clever use of two printable ASCII characters > (consuming 16 bits) to encode 13 arbitrary bits, as well as neither need > for nor ambiguity over padding or alphabets. > > It includes support for... > > - Plain Strings (module Codec.Binary.Base91.String) > - Data.ByteString (module Codec.Binary.Base91.ByteString) > - Data.Text (module Codec.Binary.Base91.Text) > - The latter two combined (module Codec.Binary.Base91.Efficient) > - Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy) > - Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy) > - The latter two combined (module Codec.Binary.Base91.Efficient.Lazy) > > ...which are all just concretely typed versions of the generic > implementation in Codec.Binary.Base91. > > I had fun exploring some of the latest GHC extensions, as evidenced by > Codec.Binary.Base91.Control, which relies on a certain amount of type > trickery to reconcile the incongruence between monomorphic containers and > the standard type classes. > > Anyway, suggestions are very welcome. In particular, I'm interested in: > > 1. Whether the generic decode and encode signatures can be simplified or > improved elsehow. > 2. Whether there already exist classes similar in purpose to Applicative' > and Foldable'. > 3. Whether it makes sense to offer decode and encode variants that use > lazy (left) folds--currently folding is always strict, even with lazy types. > > (Testing comes nearly free courtesy of QuickCheck and the identity > property of decode . encode, plus a couple of concrete examples. Please > open an issue or otherwise let me know if you find a bug.) > > Thank you, > > Alvaro > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Fri Jul 10 13:46:09 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Fri, 10 Jul 2015 14:46:09 +0100 Subject: [Haskell-cafe] [ANN] base91 In-Reply-To: References: Message-ID: Take a look at mono-traversable . pure' is singleton and Foldable' is MonoFoldable. On Fri, Jul 10, 2015 at 1:23 AM, Alvaro J. Genial wrote: > Howdy, > > I'd like to announce a first version of base91 > , a Haskell package to enable > the encoding and decoding of data in Base91 format, as documented in its > specification . The main benefits of said > scheme are a good reduction in overhead (from 31% up to 58%) when compared > to Base64 due to the clever use of two printable ASCII characters > (consuming 16 bits) to encode 13 arbitrary bits, as well as neither need > for nor ambiguity over padding or alphabets. > > It includes support for... > > - Plain Strings (module Codec.Binary.Base91.String) > - Data.ByteString (module Codec.Binary.Base91.ByteString) > - Data.Text (module Codec.Binary.Base91.Text) > - The latter two combined (module Codec.Binary.Base91.Efficient) > - Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy) > - Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy) > - The latter two combined (module Codec.Binary.Base91.Efficient.Lazy) > > ...which are all just concretely typed versions of the generic > implementation in Codec.Binary.Base91. > > I had fun exploring some of the latest GHC extensions, as evidenced by > Codec.Binary.Base91.Control, which relies on a certain amount of type > trickery to reconcile the incongruence between monomorphic containers and > the standard type classes. > > Anyway, suggestions are very welcome. In particular, I'm interested in: > > 1. Whether the generic decode and encode signatures can be simplified or > improved elsehow. > 2. Whether there already exist classes similar in purpose to Applicative' > and Foldable'. > 3. Whether it makes sense to offer decode and encode variants that use > lazy (left) folds--currently folding is always strict, even with lazy types. > > (Testing comes nearly free courtesy of QuickCheck and the identity > property of decode . encode, plus a couple of concrete examples. Please > open an issue or otherwise let me know if you find a bug.) > > Thank you, > > Alvaro > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Fri Jul 10 13:47:59 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Fri, 10 Jul 2015 14:47:59 +0100 Subject: [Haskell-cafe] [ANN] base91 In-Reply-To: References: Message-ID: Actually Applicative' is MonoPointed . On Fri, Jul 10, 2015 at 2:46 PM, Patrick Chilton wrote: > Take a look at mono-traversable > . pure' is > singleton and Foldable' is MonoFoldable. > > On Fri, Jul 10, 2015 at 1:23 AM, Alvaro J. Genial wrote: > >> Howdy, >> >> I'd like to announce a first version of base91 >> , a Haskell package to enable >> the encoding and decoding of data in Base91 format, as documented in its >> specification . The main benefits of said >> scheme are a good reduction in overhead (from 31% up to 58%) when compared >> to Base64 due to the clever use of two printable ASCII characters >> (consuming 16 bits) to encode 13 arbitrary bits, as well as neither need >> for nor ambiguity over padding or alphabets. >> >> It includes support for... >> >> - Plain Strings (module Codec.Binary.Base91.String) >> - Data.ByteString (module Codec.Binary.Base91.ByteString) >> - Data.Text (module Codec.Binary.Base91.Text) >> - The latter two combined (module Codec.Binary.Base91.Efficient) >> - Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy) >> - Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy) >> - The latter two combined (module Codec.Binary.Base91.Efficient.Lazy) >> >> ...which are all just concretely typed versions of the generic >> implementation in Codec.Binary.Base91. >> >> I had fun exploring some of the latest GHC extensions, as evidenced by >> Codec.Binary.Base91.Control, which relies on a certain amount of type >> trickery to reconcile the incongruence between monomorphic containers and >> the standard type classes. >> >> Anyway, suggestions are very welcome. In particular, I'm interested in: >> >> 1. Whether the generic decode and encode signatures can be simplified or >> improved elsehow. >> 2. Whether there already exist classes similar in purpose to Applicative' >> and Foldable'. >> 3. Whether it makes sense to offer decode and encode variants that use >> lazy (left) folds--currently folding is always strict, even with lazy types. >> >> (Testing comes nearly free courtesy of QuickCheck and the identity >> property of decode . encode, plus a couple of concrete examples. Please >> open an issue or otherwise let me know if you find a bug.) >> >> Thank you, >> >> Alvaro >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From genial at alva.ro Fri Jul 10 19:11:42 2015 From: genial at alva.ro (Alvaro J. Genial) Date: Fri, 10 Jul 2015 15:11:42 -0400 Subject: [Haskell-cafe] [ANN] base91 In-Reply-To: References: Message-ID: On Fri, Jul 10, 2015 at 9:46 AM, Patrick Chilton wrote: > Take a look at mono-traversable > . pure' is > singleton and Foldable' is MonoFoldable. > On Fri, Jul 10, 2015 at 9:47 AM, Patrick Chilton wrote: > Actually Applicative' is MonoPointed > > . > Thank you! Indeed, I was able to re-implement the library deferring to MonoFoldable and MonoPointed and then collapse the whole thing to a single module with two functions that automatically work with all suitable input and output types. In terms of the package (and since I'll be bumping the major version) I don't think the specialized modules are needed any more, since they're just a small subset of the combinatorial input/output space. Or is there a tangible benefit to users in providing more concretely typed versions for those (unusual?) cases where the return type is ambiguous? So, given: type Input i e = (MonoFoldable i, Element i ~ e) type Output o e = (MonoPointed o, Element o ~ e, Monoid o) encode :: forall i o. (Input i Word8, Output o Char) => i -> o decode :: forall i o. (Input i Char, Output o Word8) => i -> o Does including and exposing the following... encodeToString :: Input i Word8 => i -> [Char] decodeToBytes :: Input i Char => i -> [Word8] encodeBytes :: Output o Char => [Word8] -> o decodeString :: Output o Word8 => [Char] -> o encodeBytesToString :: [Word8] -> [Char] decodeStringToBytes :: [Char] -> [Word8] ...add any value, being trivially defined as equal to the generic version? (Plus, the explosion doubles with another dimension like lazy vs. strict.) I don't see much advantage over e.g. (encode ws :: String) for the first case. Thanks again, Alvaro -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Fri Jul 10 22:49:16 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 11 Jul 2015 07:49:16 +0900 Subject: [Haskell-cafe] GHC Memory Management wiki page In-Reply-To: References: Message-ID: Hi Kyle, In addition to the wiki information, there are also the following documents. GHC?s Garbage Collector http://www.mm-net.org.uk/workshop190404/GHC's_Garbage_Collector.ppt The GHC Runtime System http://www.scs.stanford.edu/14sp-cs240h/slides/ghc-rts.pdf Here is related image. http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=63 Cheers, Takenobu 2015-07-08 23:47 GMT+09:00 Gershom B : > Yep. The wiki should be modified ? it is pretty clearly an old page in > error. Good eye on spotting it. > > There is some extremely detailed material on the GHC developers wiki: > https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC > > I would hope that the material on the main Haskell Wiki could be at an > ?intermediate? level ? a bit of high-level overview, with pointers to other > good material. > > Cheers, > Gershom > > > On July 8, 2015 at 10:11:47 AM, Kostiantyn Rybnikov (k-bx at k-bx.com) wrote: > > I would suggest posting this to ghc-devs. > > 7 ???. 2015 07:54 "Kyle Miller" ????: > > > > > I have been studying the garbage collection algorithms used in GHC, > and it > > > appears to me that section two of [1] is misleading, since thunks > permit > > > controlled mutation of the heap, and so objects in older generations > may > > > point to younger objects. In fact, the RTS maintains "remembered sets" > to > > > keep track of these relations. A Haskell could in principle be > implemented > > > in the way described (and execute in surprising complexity classes), > but > > > this does not seem to match reality. > > > > > > [1] https://wiki.haskell.org/GHC/Memory_Management > > > > > > Should the wiki be modified? > > > > > > Regards, > > > Kyle Miller > > > > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > Haskell-Cafe at haskell.org > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Jul 11 03:29:57 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 10 Jul 2015 23:29:57 -0400 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: References: Message-ID: <0CBE6E68-EFC5-42B9-90FC-ACD269D50909@gmail.com> I'd personally rather have a little link on all-but-latest package pages like "This is an older version. Jump to latest." This would solve the annoying "google shows old versions" problem and also would be convenient for when someone does actually want to link to a specific version, but don't want novices-of-the-future to not realize they're looking at old docs. Tom El Jul 9, 2015, a las 17:56, Brandon Allbery escribi?: > On Thu, Jul 9, 2015 at 5:54 PM, Tikhon Jelvis wrote: >> The problem, then, is visibility both to users and to Google. Since it's an actual redirect, your URL bar will show the specific version when you follow the link. The version number will also show up if you copy the URL from one of the links on the contents page even if you got there without specifying a version. (By following http://hackage.haskell.org/package/base >> >> for example.) > > My understanding is that Hackage is using a link tag that Google claims should work... but in practice does not. I think latest urls are being actively considered as an alternative, if I understood the discussion properly. > > -- > 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 > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sat Jul 11 03:37:45 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 10 Jul 2015 20:37:45 -0700 Subject: [Haskell-cafe] As reading, what are your favorite Haskell libraries? Message-ID: A wider question controls also for a library's applicability and (relative) absence of prerequisites, because the funnest reading is not only intrinsically fun, but also extrinsically rewarding and soon feasible (feasible to comprehend or to use). That is, I like simple, beautiful, powerful libraries that do not require me to first learn too many other things. I might value simplicity over power. I'm interested in answers to either question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Sat Jul 11 03:48:53 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Fri, 10 Jul 2015 23:48:53 -0400 Subject: [Haskell-cafe] As reading, what are your favorite Haskell libraries? In-Reply-To: References: Message-ID: <20150711034853.5296206.41439.9971@gsd.uwaterloo.ca> An HTML attachment was scrubbed... URL: From rasen.dubi at gmail.com Sat Jul 11 07:02:59 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Sat, 11 Jul 2015 10:02:59 +0300 Subject: [Haskell-cafe] First call to putStr takes far more time than subsequent calls In-Reply-To: <559F7184.60701@tu-harburg.de> References: <559F0791.1040608@ro-che.info> <559F7184.60701@tu-harburg.de> Message-ID: On Fri, Jul 10, 2015 at 10:17 AM, Jonas Scholl wrote: > It could also be the case that libgmp itself has to be loaded at this > point. Using strace it looks like it is mmapped into the memory, maybe > linux is lazy and only reads the file on the disk at the moment it is > accessed the first time (i.e. at the first call)? At least linux uses a > similar approach for requested memory by a program. I can confirm Linux is lazy in loading program's code. It maps it in memory space, but doesn't load yet. That's also true for mmap. From tim at utf8.me Sat Jul 11 07:30:46 2015 From: tim at utf8.me (Timothy Humphries) Date: Sat, 11 Jul 2015 17:30:46 +1000 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: <0CBE6E68-EFC5-42B9-90FC-ACD269D50909@gmail.com> References: <0CBE6E68-EFC5-42B9-90FC-ACD269D50909@gmail.com> Message-ID: <65AF7D6F-9B86-462C-9A4B-55E096E07CC9@utf8.me> I use the hackage-fu browser extension for this. It does a pretty good job, while we wait for a proper solution! https://chrome.google.com/webstore/detail/hackage-fu/ - Tim > On 11 Jul 2015, at 13:29, amindfv at gmail.com wrote: > > I'd personally rather have a little link on all-but-latest package pages like "This is an older version. Jump to latest." > > This would solve the annoying "google shows old versions" problem and also would be convenient for when someone does actually want to link to a specific version, but don't want novices-of-the-future to not realize they're looking at old docs. > > Tom > > > El Jul 9, 2015, a las 17:56, Brandon Allbery > escribi?: > >> On Thu, Jul 9, 2015 at 5:54 PM, Tikhon Jelvis > wrote: >> The problem, then, is visibility both to users and to Google. Since it's an actual redirect, your URL bar will show the specific version when you follow the link. The version number will also show up if you copy the URL from one of the links on the contents page even if you got there without specifying a version. (By following http://hackage.haskell.org/package/base for example.) >> >> >> My understanding is that Hackage is using a link tag that Google claims should work... but in practice does not. I think latest urls are being actively considered as an alternative, if I understood the discussion properly. >> >> -- >> 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 >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From grrwlf at gmail.com Sat Jul 11 17:54:10 2015 From: grrwlf at gmail.com (Sergey Mironov) Date: Sat, 11 Jul 2015 20:54:10 +0300 Subject: [Haskell-cafe] SQL database schema diff tool Message-ID: Hi, list! I wish I have a tool which would compare two database sachemas, where each schema is represented as a list of 'CREATE smth' instructions. The result of such a comparison would be a list of 'ALTER smth' instructions. This instruction set would change the database from first state to second, if the transition is possible without data losses. The 'hard' mode - to prepare the transition for any inputs, with minimal data losses. The database of interest is PostgreSQL. Does such a tool exist? If not, which package do I better use to build the AST of initial schemas? The example schema is in attach. Thanks in advance, Sergey -------------- next part -------------- A non-text attachment was scrubbed... Name: Etab.sql Type: application/sql Size: 1581 bytes Desc: not available URL: From grrwlf at gmail.com Sat Jul 11 19:17:58 2015 From: grrwlf at gmail.com (Sergey Mironov) Date: Sat, 11 Jul 2015 22:17:58 +0300 Subject: [Haskell-cafe] Fwd: SQL database schema diff tool In-Reply-To: References: <55A15ADD.6060709@kane.cx> Message-ID: ---------- Forwarded message ---------- From: Sergey Mironov Date: 2015-07-11 22:17 GMT+03:00 Subject: Re: [Haskell-cafe] SQL database schema diff tool To: David Kraeutmann Thanks for the answer, I've looked at simple-migrations application. Unfortunately, it doesn't look like the solution for me. Term 'migration' in PostgreSQL seems to mean 'movement of data from one server to another using the same schema', but I need to move the data from one schema to another as safely as possible having the definitions of both schemas. Regards, Sergey 2015-07-11 21:05 GMT+03:00 David Kraeutmann : > You could try https://github.com/ameingast/postgresql-simple-migration, but I haven't used it myself. "schema migration" seems to be what you want. > On 7/11/2015 7:54 PM, Sergey Mironov wrote: >> Hi, list! I wish I have a tool which would compare two database >> sachemas, where each schema is represented as a list of 'CREATE smth' >> instructions. The result of such a comparison would be a list of >> 'ALTER smth' instructions. This instruction set would change the >> database from first state to second, if the transition is possible >> without data losses. The 'hard' mode - to prepare the transition for >> any inputs, with minimal data losses. >> >> The database of interest is PostgreSQL. Does such a tool exist? If >> not, which package do I better use to build the AST of initial >> schemas? >> >> The example schema is in attach. >> Thanks in advance, >> Sergey >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > From joehillen at gmail.com Sun Jul 12 09:30:26 2015 From: joehillen at gmail.com (Joe Hillenbrand) Date: Sun, 12 Jul 2015 02:30:26 -0700 Subject: [Haskell-cafe] idea: -latest URLs for Hackage In-Reply-To: <65AF7D6F-9B86-462C-9A4B-55E096E07CC9@utf8.me> References: <0CBE6E68-EFC5-42B9-90FC-ACD269D50909@gmail.com> <65AF7D6F-9B86-462C-9A4B-55E096E07CC9@utf8.me> Message-ID: That link doesn't work. https://chrome.google.com/webstore/detail/hackage-fu/dnpldbohleinhdgfnhlkofpgkdcfcfmf On Sat, Jul 11, 2015 at 12:30 AM, Timothy Humphries wrote: > I use the hackage-fu browser extension for this. It does a pretty good job, > while we wait for a proper solution! > > https://chrome.google.com/webstore/detail/hackage-fu/ > > - Tim > > On 11 Jul 2015, at 13:29, amindfv at gmail.com wrote: > > I'd personally rather have a little link on all-but-latest package pages > like "This is an older version. Jump to latest." > > This would solve the annoying "google shows old versions" problem and also > would be convenient for when someone does actually want to link to a > specific version, but don't want novices-of-the-future to not realize > they're looking at old docs. > > Tom > > > El Jul 9, 2015, a las 17:56, Brandon Allbery escribi?: > > On Thu, Jul 9, 2015 at 5:54 PM, Tikhon Jelvis wrote: >> >> The problem, then, is visibility both to users and to Google. Since it's >> an actual redirect, your URL bar will show the specific version when you >> follow the link. The version number will also show up if you copy the URL >> from one of the links on the contents page even if you got there without >> specifying a version. (By following http://hackage.haskell.org/package/base >> >> >> for example.) >> > > My understanding is that Hackage is using a link tag that Google claims > should work... but in practice does not. I think latest urls are being > actively considered as an alternative, if I understood the discussion > properly. > > -- > 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 > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From kc1956 at gmail.com Sun Jul 12 17:28:09 2015 From: kc1956 at gmail.com (KC) Date: Sun, 12 Jul 2015 10:28:09 -0700 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... Message-ID: On Windows after I install the new cabal-install then when I do a cabal update it says there is a new cabal-install available. Yet cabal-install installed without any errors. Why do I get this message? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sun Jul 12 17:30:35 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 12 Jul 2015 17:30:35 +0000 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: You probably don't have $APPDATA\cabal\bin on your PATH On Sun, Jul 12, 2015 at 10:28 AM KC wrote: > On Windows after I install the new cabal-install then when I do a cabal > update it says there is a new cabal-install available. > > Yet cabal-install installed without any errors. > > Why do I get this message? > > -- > -- > > Sent from an expensive device which will be obsolete in a few months! :D > > Casey > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fr33domlover at riseup.net Sun Jul 12 19:09:34 2015 From: fr33domlover at riseup.net (fr33domlover) Date: Sun, 12 Jul 2015 22:09:34 +0300 Subject: [Haskell-cafe] Announcing libravatar @ hackage Message-ID: Hello! Libravatar - http://libravatar.org - is a free-as-in-freedom and decentralized avatar (profile image delivery service, a replacement of the centralized and proprietary grava7ar. There has been a Haskell library for grava7ar for some time, but not for Libravatar. I just finished writing one, and did a bit of testing which had good results. More testing and feedback etc. very very welcome! I also enourage you all to *integrate libravatar into your desktop/web applications and websites*! Support openness, decentralization and freedom by using Libravatar. --- fr33domlover GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From gladstein at gladstein.com Sun Jul 12 19:58:13 2015 From: gladstein at gladstein.com (David Gladstein) Date: Sun, 12 Jul 2015 12:58:13 -0700 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: I have C:\Users\David\AppData\Roaming\cabal\bin on my path, and I have the same problem. I think it's been that way for years. On Sun, Jul 12, 2015 at 10:30 AM, Michael Snoyman wrote: > You probably don't have $APPDATA\cabal\bin on your PATH > > On Sun, Jul 12, 2015 at 10:28 AM KC wrote: > >> On Windows after I install the new cabal-install then when I do a cabal >> update it says there is a new cabal-install available. >> >> Yet cabal-install installed without any errors. >> >> Why do I get this message? >> >> -- >> -- >> >> Sent from an expensive device which will be obsolete in a few months! :D >> >> Casey >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Sun Jul 12 20:49:38 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Sun, 12 Jul 2015 22:49:38 +0200 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: When you just run "cabal", it runs from some directory X; but it installs new cabal in some other directory Y. Sorry, I'm not an expert in Windows paths; but as of now you have two versions of cabal.exe installed: one old, which runs, and another, which is new. ?????????? ? iPad > 12 ???? 2015 ?., ? 21:58, David Gladstein ???????(?): > > I have C:\Users\David\AppData\Roaming\cabal\bin on my path, and I have the same problem. I think it's been that way for years. > >> On Sun, Jul 12, 2015 at 10:30 AM, Michael Snoyman wrote: >> You probably don't have $APPDATA\cabal\bin on your PATH >> >>> On Sun, Jul 12, 2015 at 10:28 AM KC wrote: >>> On Windows after I install the new cabal-install then when I do a cabal update it says there is a new cabal-install available. >>> >>> Yet cabal-install installed without any errors. >>> >>> Why do I get this message? >>> >>> -- >>> -- >>> >>> Sent from an expensive device which will be obsolete in a few months! :D >>> >>> Casey >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Sun Jul 12 21:44:25 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Sun, 12 Jul 2015 23:44:25 +0200 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: <55A2DFB9.5060302@informatik.uni-tuebingen.de> Hi, David Gladstein wrote: > I have C:\Users\David\AppData\Roaming\cabal\bin on my path, and I have > the same problem. I think it's been that way for years. Make sure that the order of directories on the path is correct, so that the first cabal.exe found is the one installed by cabal itself. To check that it worked, run "cabal --version" and compare with the version number from the output of "cabal install cabal-install". Tillmann From fr33domlover at riseup.net Sun Jul 12 23:13:51 2015 From: fr33domlover at riseup.net (fr33domlover) Date: Mon, 13 Jul 2015 02:13:51 +0300 Subject: [Haskell-cafe] Announcing libravatar @ hackage In-Reply-To: <20150712190734.E2147BCC8F@haskell.org> References: <20150712190734.E2147BCC8F@haskell.org> Message-ID: Forgot the link, just in case: http://hackage.haskell.org/package/libravatar On 2015-07-12 fr33domlover wrote: > Hello! > > Libravatar - http://libravatar.org - is a free-as-in-freedom and decentralized > avatar (profile image delivery service, a replacement of the centralized and > proprietary grava7ar. > > There has been a Haskell library for grava7ar for some time, but not for > Libravatar. I just finished writing one, and did a bit of testing which had > good results. > > More testing and feedback etc. very very welcome! I also enourage you all to > *integrate libravatar into your desktop/web applications and websites*! > Support openness, decentralization and freedom by using Libravatar. > > > > --- > fr33domlover > GPG key ID: 63E5E57D (size: 4096) > GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D --- fr33domlover GPG key ID: 63E5E57D (size: 4096) GPG key fingerprint: 6FEE C222 7323 EF85 A49D 5487 5252 C5C8 63E5 E57D From metaniklas at gmail.com Sun Jul 12 23:21:05 2015 From: metaniklas at gmail.com (Niklas Larsson) Date: Mon, 13 Jul 2015 01:21:05 +0200 Subject: [Haskell-cafe] On Windows after I install the new cabal-installthen when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: <55a2f662.ca39700a.4e56.2827@mx.google.com> The order of the paths matter, if the Haskell platform path is before the cabal one, any common programs will be shadowed. Run 'where.exe ' to find out the path of the program that is first in line. Niklas ----- Ursprungligt meddelande ----- Fr?n: "David Gladstein" Skickat: ?2015-?07-?12 21:58 Till: "Michael Snoyman" Kopia: "haskell-cafe" ?mne: Re: [Haskell-cafe] On Windows after I install the new cabal-installthen when I do a cabal update it says there is a new ... I have C:\Users\David\AppData\Roaming\cabal\bin on my path, and I have the same problem. I think it's been that way for years. On Sun, Jul 12, 2015 at 10:30 AM, Michael Snoyman wrote: You probably don't have $APPDATA\cabal\bin on your PATH On Sun, Jul 12, 2015 at 10:28 AM KC wrote: On Windows after I install the new cabal-install then when I do a cabal update it says there is a new cabal-install available. Yet cabal-install installed without any errors. Why do I get this message? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Jul 13 08:07:10 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 13 Jul 2015 18:07:10 +1000 Subject: [Haskell-cafe] To all users of FGL Message-ID: As you may now, for the past few months I've been (finally!) cleaning up FGL, adding tests, etc. One of the issues that has arisen with this is that the behaviour of the delLEdge [1] function is not well specified when dealing with multiple edges. Specifically, the documentation states that the purpose is to "Remove *an* LEdge from the Graph." (emphasis added)... but the behaviour when dealing with multiple edges is to remove *all* such edges from the graph. The current version on GitHub is to instead just delete a single such labelled edge, with a new function "delAllLEdge" that replicates the current behaviour. Before releasing this change, however, I wanted to make sure that I wouldn't break people's code if they rely upon this functionality; I did try and search through GitHub to see who - if anyone - is using this function, but primarily found various copies of fgl embedded into other people's repositories. As such, please check your code and let me know if this change in behaviour might affect you (if this is the case, I might let delLEdge keep the current behaviour and have a new function delete just one edge). [1]: http://hackage.haskell.org/package/fgl-5.5.1.0/docs/Data-Graph-Inductive-Graph.html#v:delLEdge -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ab at fmap.me Mon Jul 13 11:45:12 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 14:45:12 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? Message-ID: <55A3A4C8.3040309@fmap.me> Hi Cafe, Every now and then I'm in a need to check if a value satisfies pattern with a Bool result. So far I know several ways to do this: 1. Use lens: `has _Left` 2. Make a function: `isLeft (Left _) = True; isLeft _ = False` 3. (When you need a lambda) Use LambdaCase: `\case Left _ -> True; _ -> False` Usually I go for (1) because I use lens extensively anyway, but for one-time usage all the extra machinery seems too much. I don't like (2) when I don't have a library defining that for me, and also (3) -- they seem inelegant. Is there any syntactic trick that I'm missing that makes it look nicer? -- Nikolay. From nikita at karetnikov.org Mon Jul 13 12:02:07 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Mon, 13 Jul 2015 15:02:07 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3A4C8.3040309@fmap.me> (Nikolay Amiantov's message of "Mon, 13 Jul 2015 14:45:12 +0300") References: <55A3A4C8.3040309@fmap.me> Message-ID: <87a8v0p8ow.fsf@karetnikov.org> Looking at the instances defined for Bool and Either, I don't think there's a higher level way of doing it. But even if there's one, it'll probably be more obscure than isLeft, which is in base since 4.7.0.0. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From ab at fmap.me Mon Jul 13 13:04:50 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 16:04:50 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <87a8v0p8ow.fsf@karetnikov.org> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> Message-ID: <55A3B772.1010204@fmap.me> Yes, for standard data types like Either or Maybe the best way is to use library-defined functions -- I was more interested in a way to check for any given pattern, which would look nicer than a custom defined function or a LambdaCase. An example use case: partition (\case MyPat -> True; _ -> False) Anyway using lens for this is already very readable and concise, albeit needs makePrisms/Lens and stuff. On 07/13/2015 03:02 PM, Nikita Karetnikov wrote: > Looking at the instances defined for Bool and Either, I don't think > there's a higher level way of doing it. But even if there's one, it'll > probably be more obscure than isLeft, which is in base since 4.7.0.0. > -- Nikolay. From adam at bergmark.nl Mon Jul 13 13:24:40 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Mon, 13 Jul 2015 15:24:40 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3B772.1010204@fmap.me> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> Message-ID: Perhaps this is of interest to you, http://hackage.haskell.org/package/generic-maybe HTH, Adam On Mon, Jul 13, 2015 at 3:04 PM, Nikolay Amiantov wrote: > Yes, for standard data types like Either or Maybe the best way is to use > library-defined functions -- I was more interested in a way to check for > any given pattern, which would look nicer than a custom defined function > or a LambdaCase. An example use case: > > partition (\case MyPat -> True; _ -> False) > > Anyway using lens for this is already very readable and concise, albeit > needs makePrisms/Lens and stuff. > > On 07/13/2015 03:02 PM, Nikita Karetnikov wrote: > > Looking at the instances defined for Bool and Either, I don't think > > there's a higher level way of doing it. But even if there's one, it'll > > probably be more obscure than isLeft, which is in base since 4.7.0.0. > > > > -- > Nikolay. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ab at fmap.me Mon Jul 13 13:40:33 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 16:40:33 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> Message-ID: <55A3BFD1.5010007@fmap.me> A nice idea! It can be helpful in some cases, although usually I have more complex patterns, for example "get all DataDefinitions from a list of TopLevelDefinitions parsed from a .hs file" or "filter all KeyPresses directed to a particular window from an Event stream". On 07/13/2015 04:24 PM, Adam Bergmark wrote: > Perhaps this is of interest to > you, http://hackage.haskell.org/package/generic-maybe > > HTH, > Adam -- Nikolay. From hesselink at gmail.com Mon Jul 13 14:06:40 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 13 Jul 2015 16:06:40 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3BFD1.5010007@fmap.me> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> Message-ID: You can write a generic 'is constructor' function using GHC Generics, if you want: {-# LANGUAGE DeriveGeneric , FlexibleContexts , FlexibleInstances , FunctionalDependencies , MultiParamTypeClasses , UndecidableInstances #-} import GHC.Generics import Generics.Deriving.ConNames class SameType a b | b -> a where saturate :: b -> a instance SameType a a where saturate = id instance SameType a b => SameType a (c -> b) where saturate f = saturate (f undefined) is :: (ConNames (Rep a), Generic a, SameType a b) => b -> a -> Bool is ctor val = conNameOf val == conNameOf (saturate ctor) Now you can do things like: data Foo = A | B Int deriving (Show, Generic) *Main> is A A True *Main> is A (B 1) False *Main> is B A False *Main> is B (B 2) True Erik On Mon, Jul 13, 2015 at 3:40 PM, Nikolay Amiantov wrote: > A nice idea! It can be helpful in some cases, although usually I have > more complex patterns, for example "get all DataDefinitions from a list > of TopLevelDefinitions parsed from a .hs file" or "filter all KeyPresses > directed to a particular window from an Event stream". > > On 07/13/2015 04:24 PM, Adam Bergmark wrote: >> Perhaps this is of interest to >> you, http://hackage.haskell.org/package/generic-maybe >> >> HTH, >> Adam > > -- > Nikolay. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From ab at fmap.me Mon Jul 13 15:36:33 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 18:36:33 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> Message-ID: <55A3DB01.4010801@fmap.me> Very interesting trick, thanks, it feels closer to what I've imagined! Meanwhile I've played with quasi-quoters and TH a bit for the sake of experiment. As a result I got this: https://github.com/abbradar/isit/blob/master/src/Language/Haskell/IsIt.hs It allows one to do very nice-looking checks, like: ? filter [is|Left (Just 4)|] [Right "test", Left (Just 4), Left Nothing] [Left (Just 4)] ? let x = 4 ? filter [is|Left (Just x)|] [Right "test", Left (Just 4), Left Nothing] [Left (Just 4)] ? :t [is|Just _|] [is|Just _|] :: Maybe t -> Bool I doubt anyone including me would actually use this though -- it depends on haskell-src-{exts,meta} which you probably don't want as yet more dependencies for your project to do such a trivial task. On 07/13/2015 05:06 PM, Erik Hesselink wrote: > You can write a generic 'is constructor' function using GHC Generics, > if you want: > > {-# LANGUAGE > DeriveGeneric > , FlexibleContexts > , FlexibleInstances > , FunctionalDependencies > , MultiParamTypeClasses > , UndecidableInstances > #-} > > import GHC.Generics > import Generics.Deriving.ConNames > > class SameType a b | b -> a where > saturate :: b -> a > > instance SameType a a where > saturate = id > > instance SameType a b => SameType a (c -> b) where > saturate f = saturate (f undefined) > > is :: (ConNames (Rep a), Generic a, SameType a b) => b -> a -> Bool > is ctor val = conNameOf val == conNameOf (saturate ctor) > > Now you can do things like: > > data Foo = A | B Int > deriving (Show, Generic) > > *Main> is A A > True > *Main> is A (B 1) > False > *Main> is B A > False > *Main> is B (B 2) > True > > Erik -- Nikolay. From mikesteele81 at gmail.com Mon Jul 13 16:41:55 2015 From: mikesteele81 at gmail.com (Michael Steele) Date: Mon, 13 Jul 2015 09:41:55 -0700 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: On Windows the 'system' path variable always has precedence over the 'user' path variable (see [1]). You will need to rename, delete, or overwrite the version of cabal.exe installed globally for the one under %appdata% to be used. [1]: https://support.microsoft.com/en-us/kb/100843 On Sun, Jul 12, 2015 at 12:58 PM, David Gladstein wrote: > I have C:\Users\David\AppData\Roaming\cabal\bin on my path, and I have the > same problem. I think it's been that way for years. > > On Sun, Jul 12, 2015 at 10:30 AM, Michael Snoyman > wrote: > >> You probably don't have $APPDATA\cabal\bin on your PATH >> >> On Sun, Jul 12, 2015 at 10:28 AM KC wrote: >> >>> On Windows after I install the new cabal-install then when I do a cabal >>> update it says there is a new cabal-install available. >>> >>> Yet cabal-install installed without any errors. >>> >>> Why do I get this message? >>> >>> -- >>> -- >>> >>> Sent from an expensive device which will be obsolete in a few months! :D >>> >>> Casey >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Jul 13 16:49:25 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 13 Jul 2015 18:49:25 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3A4C8.3040309@fmap.me> References: <55A3A4C8.3040309@fmap.me> Message-ID: 2015-07-13 13:45 GMT+02:00 Nikolay Amiantov : > [...] > 1. Use lens: `has _Left` > 2. Make a function: `isLeft (Left _) = True; isLeft _ = False` > 3. (When you need a lambda) Use LambdaCase: `\case Left _ -> True; _ -> > False` > [...] > http://www.extremeprogramming.org/rules/simple.html ;-) So IMHO a simple, old-skool '\x -> case x of Left _ -> True; _ -> False' (probably item 2.5 in the list above) is by far the "best" way: It doesn't use any kind of extension, it doesn't pull in a dozen of packages for a trivial task, and is readable by anyone. My personal experience is that things which look very clever and advanced (like using meta/reflection facilities) only increase the WTF factor in the long run. Those facilities have their uses, but they come with a heavy cost which must be justified somehow. Boring code is good code! :-D -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Mon Jul 13 16:53:26 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Mon, 13 Jul 2015 18:53:26 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: References: <55A3A4C8.3040309@fmap.me> Message-ID: <55A3ED06.6020404@gmail.com> > http://www.extremeprogramming.org/rules/simple.html ;-) So IMHO a > simple, old-skool '\x -> case x of Left _ -> True; _ -> False' (probably > item 2.5 in the list above) is by far the "best" way: It doesn't use any > kind of extension, it doesn't pull in a dozen of packages for a trivial > task, and is readable by anyone. My personal experience is that things > which look very clever and advanced (like using meta/reflection > facilities) only increase the WTF factor in the long run. Those > facilities have their uses, but they come with a heavy cost which must > be justified somehow. Boring code is good code! :-D +1 for readability That's the problem with Haskell. You can do things in so many beautiful and wondrous ways that you tend to get lost very easily. From svenpanne at gmail.com Mon Jul 13 17:01:08 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 13 Jul 2015 19:01:08 +0200 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: 2015-07-13 18:41 GMT+02:00 Michael Steele : > On Windows the 'system' path variable always has precedence over the > 'user' path variable (see [1]). You will need to rename, delete, or > overwrite the version of cabal.exe installed globally for the one under > %appdata% to be used. > > > [1]: https://support.microsoft.com/en-us/kb/100843 > To me that looks like a bug in the Haskell Platform installer: It puts the path to the tools shipped with the platform into the the system PATH and the path to the user-installed tools (i.e. the stuff below %APPDATA%) into the user part of the PATH. This way, you will always get the shipped alex/cabal/happy/HsColour, not the new stuff. This is a bit like putting e.g. /usr/bin before your $HOME/bin on *nices, which is exactly the wrong way round. Furthermore, I've just seen that there is a 'C:\Program Files\Haskell\bin' at the start of my system PATH, pointing to nowhere. Is this a remnant of former GHC/platform installations? No clue where this comes from... -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at nand.wakku.to Mon Jul 13 17:03:02 2015 From: haskell at nand.wakku.to (Niklas Haas) Date: Mon, 13 Jul 2015 19:03:02 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3BFD1.5010007@fmap.me> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> Message-ID: <20150713190302.GB20650@nanodesu.localdomain> For this specific use case, you can also consider list comprehensions: [ x | x@(DataDefinition _) <- tlds ] I personally greatly prefer this over something like ?filter? + an ugly lambda, especially if you can use the list comprehension for the rest of your processing as well. On Mon, 13 Jul 2015 16:40:33 +0300, Nikolay Amiantov wrote: > A nice idea! It can be helpful in some cases, although usually I have > more complex patterns, for example "get all DataDefinitions from a list > of TopLevelDefinitions parsed from a .hs file" or "filter all KeyPresses > directed to a particular window from an Event stream". From haskell at nand.wakku.to Mon Jul 13 17:04:11 2015 From: haskell at nand.wakku.to (Niklas Haas) Date: Mon, 13 Jul 2015 19:04:11 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <20150713190302.GB20650@nanodesu.localdomain> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> <20150713190302.GB20650@nanodesu.localdomain> Message-ID: <20150713190411.GC20765@nanodesu.localdomain> I forgot to mention: The same can be extended to any monad with a good ?fail? definition, including many types of streams/parsers/whatever. On Mon, 13 Jul 2015 19:03:02 +0200, Niklas Haas wrote: > For this specific use case, you can also consider list comprehensions: > > [ x | x@(DataDefinition _) <- tlds ] > > I personally greatly prefer this over something like ?filter? + an ugly > lambda, especially if you can use the list comprehension for the rest of > your processing as well. > > On Mon, 13 Jul 2015 16:40:33 +0300, Nikolay Amiantov wrote: > > A nice idea! It can be helpful in some cases, although usually I have > > more complex patterns, for example "get all DataDefinitions from a list > > of TopLevelDefinitions parsed from a .hs file" or "filter all KeyPresses > > directed to a particular window from an Event stream". From mikesteele81 at gmail.com Mon Jul 13 17:57:40 2015 From: mikesteele81 at gmail.com (Michael Steele) Date: Mon, 13 Jul 2015 10:57:40 -0700 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: I disagree that this is a bug or misfeature in the Haskell Platform. The problem is caused by a quirk in how Windows works. There are a few other options I didn't mention. One is to delete the global entry from the 'system' path variable and insert it into the 'user' path variable somewhere after the "%appdata%\cabal\bin" entry. The downside here is that other user accounts will be affected. Another option is to use a custom shortcut or execute a batch script which manually sets PATH variables as needed. This is the method I use personally. On Mon, Jul 13, 2015 at 10:01 AM, Sven Panne wrote: > 2015-07-13 18:41 GMT+02:00 Michael Steele : > >> On Windows the 'system' path variable always has precedence over the >> 'user' path variable (see [1]). You will need to rename, delete, or >> overwrite the version of cabal.exe installed globally for the one under >> %appdata% to be used. >> >> >> [1]: https://support.microsoft.com/en-us/kb/100843 >> > > To me that looks like a bug in the Haskell Platform installer: It puts the > path to the tools shipped with the platform into the the system PATH and > the path to the user-installed tools (i.e. the stuff below %APPDATA%) into > the user part of the PATH. This way, you will always get the shipped > alex/cabal/happy/HsColour, not the new stuff. This is a bit like putting > e.g. /usr/bin before your $HOME/bin on *nices, which is exactly the wrong > way round. > > Furthermore, I've just seen that there is a 'C:\Program Files\Haskell\bin' > at the start of my system PATH, pointing to nowhere. Is this a remnant of > former GHC/platform installations? No clue where this comes from... > -- -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From ab at fmap.me Mon Jul 13 18:01:54 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 21:01:54 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <20150713190302.GB20650@nanodesu.localdomain> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> <20150713190302.GB20650@nanodesu.localdomain> Message-ID: <55A3FD12.60800@fmap.me> Ouch, I feel deeply ashamed for not thinking of that from the beginning! While not being a general solution "Pattern a -> a -> Bool" this covers almost all my use cases (with rest of processing, too) while requiring no extensions, no dependencies and overall being readable and "boring" in Sven's sense (at least I feel so -- comprehensions are being taught in every Haskell tutorial under the sun and are pretty self-describing). It remains a question of whether it's equally readable in monadic case ("huh? list comprehension? but... this is a Maybe/an Event!"), but in most my GUI/event-processing code I use lens anyway to cope with deep hierarchies of records describing events, so it's not much of a problem there. Thanks! On 07/13/2015 08:03 PM, Niklas Haas wrote: > For this specific use case, you can also consider list comprehensions: > > [ x | x@(DataDefinition _) <- tlds ] > > I personally greatly prefer this over something like ?filter? + an ugly > lambda, especially if you can use the list comprehension for the rest of > your processing as well. -- Nikolay. From haskell at nand.wakku.to Mon Jul 13 18:10:22 2015 From: haskell at nand.wakku.to (Niklas Haas) Date: Mon, 13 Jul 2015 20:10:22 +0200 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <55A3FD12.60800@fmap.me> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> <20150713190302.GB20650@nanodesu.localdomain> <55A3FD12.60800@fmap.me> Message-ID: <20150713201022.GB24693@nanodesu.localdomain> Concerning monad patterns, I was thinking of expressions like these: do SomeEvent a <- streamOfEvents ... Depending on the stream monad involved (including []), this can have the desired semantics. On Mon, 13 Jul 2015 21:01:54 +0300, Nikolay Amiantov wrote: > Ouch, I feel deeply ashamed for not thinking of that from the beginning! > While not being a general solution "Pattern a -> a -> Bool" this covers > almost all my use cases (with rest of processing, too) while requiring > no extensions, no dependencies and overall being readable and "boring" > in Sven's sense (at least I feel so -- comprehensions are being taught > in every Haskell tutorial under the sun and are pretty self-describing). > It remains a question of whether it's equally readable in monadic case > ("huh? list comprehension? but... this is a Maybe/an Event!"), but in > most my GUI/event-processing code I use lens anyway to cope with deep > hierarchies of records describing events, so it's not much of a problem > there. Thanks! > > On 07/13/2015 08:03 PM, Niklas Haas wrote: > > For this specific use case, you can also consider list comprehensions: > > > > [ x | x@(DataDefinition _) <- tlds ] > > > > I personally greatly prefer this over something like ?filter? + an ugly > > lambda, especially if you can use the list comprehension for the rest of > > your processing as well. > -- > Nikolay. From kc1956 at gmail.com Mon Jul 13 18:21:48 2015 From: kc1956 at gmail.com (KC) Date: Mon, 13 Jul 2015 11:21:48 -0700 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: I created a Cabal variable with the path to cabal\bin in the system variables area and than put that early in the Path variable Cabal update now finds the new cabal-install What are the pros and cons of doing this? I have a feeling running batch scripts to set path variables might be better to avoid long path variables and to inadvertently finding the wrong files on long path variables. I have also found that you want to install most/all programming platforms outside of the Program Files folder which Windows has special protections on. -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey On Jul 13, 2015 10:57 AM, "Michael Steele" wrote: > I disagree that this is a bug or misfeature in the Haskell Platform. The > problem is caused by a quirk in how Windows works. > > There are a few other options I didn't mention. One is to delete the > global entry from the 'system' path variable and insert it into the 'user' > path variable somewhere after the "%appdata%\cabal\bin" entry. The downside > here is that other user accounts will be affected. Another option is to use > a custom shortcut or execute a batch script which manually sets PATH > variables as needed. This is the method I use personally. > > > On Mon, Jul 13, 2015 at 10:01 AM, Sven Panne wrote: > >> 2015-07-13 18:41 GMT+02:00 Michael Steele : >> >>> On Windows the 'system' path variable always has precedence over the >>> 'user' path variable (see [1]). You will need to rename, delete, or >>> overwrite the version of cabal.exe installed globally for the one under >>> %appdata% to be used. >>> >>> >>> [1]: https://support.microsoft.com/en-us/kb/100843 >>> >> >> To me that looks like a bug in the Haskell Platform installer: It puts >> the path to the tools shipped with the platform into the the system PATH >> and the path to the user-installed tools (i.e. the stuff below %APPDATA%) >> into the user part of the PATH. This way, you will always get the shipped >> alex/cabal/happy/HsColour, not the new stuff. This is a bit like putting >> e.g. /usr/bin before your $HOME/bin on *nices, which is exactly the wrong >> way round. >> >> Furthermore, I've just seen that there is a 'C:\Program >> Files\Haskell\bin' at the start of my system PATH, pointing to nowhere. Is >> this a remnant of former GHC/platform installations? No clue where this >> comes from... >> > > > > -- > -- Michael Steele > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ab at fmap.me Mon Jul 13 18:25:45 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Mon, 13 Jul 2015 21:25:45 +0300 Subject: [Haskell-cafe] Best way to return Bool based on a successful pattern match? In-Reply-To: <20150713201022.GB24693@nanodesu.localdomain> References: <55A3A4C8.3040309@fmap.me> <87a8v0p8ow.fsf@karetnikov.org> <55A3B772.1010204@fmap.me> <55A3BFD1.5010007@fmap.me> <20150713190302.GB20650@nanodesu.localdomain> <55A3FD12.60800@fmap.me> <20150713201022.GB24693@nanodesu.localdomain> Message-ID: <55A402A9.9030109@fmap.me> Hm, right, that's better. On 07/13/2015 09:10 PM, Niklas Haas wrote: > Concerning monad patterns, I was thinking of expressions like these: > > do SomeEvent a <- streamOfEvents > ... > > Depending on the stream monad involved (including []), this can have the > desired semantics. -- Nikolay. From svenpanne at gmail.com Mon Jul 13 18:38:25 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 13 Jul 2015 20:38:25 +0200 Subject: [Haskell-cafe] On Windows after I install the new cabal-install then when I do a cabal update it says there is a new ... In-Reply-To: References: Message-ID: 2015-07-13 19:57 GMT+02:00 Michael Steele : > I disagree that this is a bug or misfeature in the Haskell Platform. The > problem is caused by a quirk in how Windows works. > Hmmm, I think it can be argued that it*is* a bug/misfeature of the HP, because people are obviously confused by the status quo, see the OP. The whole idea behind the HP is giving people an easy and painless approach to installing a useful Haskell ecosystem. Granted, the fact that the user part of the PATH is appended to the system part (not *pre*pended) is exactly the wrong way round in Windows, but an out-of-the-box system like the HP should work around exactly such things, e.g. by setting user vars on the first run etc. > There are a few other options I didn't mention. One is to delete the > global entry from the 'system' path variable and insert it into the 'user' > path variable somewhere after the "%appdata%\cabal\bin" entry. The downside > here is that other user accounts will be affected. Another option is to use > a custom shortcut or execute a batch script which manually sets PATH > variables as needed. This is the method I use personally. > Manually fiddling around with system settings/paths and reverting to manually written batch scripts should not be necessary. If we expect that from users, there's no point in having a HP. Don't get me wrong: Depending on your workflow, doing exactly what you described might be the right approach for power users, but that't not the target group. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Tue Jul 14 00:23:01 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 13 Jul 2015 17:23:01 -0700 Subject: [Haskell-cafe] In " returnIO x = IO $ \ s -> (# s, x #)" what are the # symbols? Message-ID: That appears here: http://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-Base.html#line-1057 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Tue Jul 14 00:24:56 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 13 Jul 2015 17:24:56 -0700 Subject: [Haskell-cafe] In " returnIO x = IO $ \ s -> (# s, x #)" what are the # symbols? In-Reply-To: References: Message-ID: That's special syntax to make an unboxed tuple. See the manual section on unboxed types[1]. [1]: https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/primitives.html On Mon, Jul 13, 2015 at 5:23 PM, Jeffrey Brown wrote: > That appears here: > http://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-Base.html#line-1057 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Tue Jul 14 00:46:16 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 14 Jul 2015 00:46:16 +0000 Subject: [Haskell-cafe] In " returnIO x = IO $ \ s -> (# s, x #)" what are the # symbols? In-Reply-To: References: Message-ID: You may also like this Wiki page about state tokens[1] (note: I'm the author). [1] https://wiki.haskell.org/Evaluation_order_and_state_tokens On Mon, Jul 13, 2015 at 5:25 PM Tikhon Jelvis wrote: > That's special syntax to make an unboxed tuple. See the manual section on > unboxed types[1]. > > [1]: > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/primitives.html > > On Mon, Jul 13, 2015 at 5:23 PM, Jeffrey Brown > wrote: > >> That appears here: >> http://hackage.haskell.org/package/base-4.8.0.0/docs/src/GHC-Base.html#line-1057 >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Tue Jul 14 04:03:23 2015 From: simon at joyful.com (Simon Michael) Date: Mon, 13 Jul 2015 21:03:23 -0700 Subject: [Haskell-cafe] ANN: hledger 0.26 Message-ID: I'm pleased to announce hledger and hledger-web 0.26! This release restores non-regular-expression account aliases as the default, and brings miscellaneous bugfixes and cleanups and some performance work. Also the website and documentation have been improved, and now include many more examples. Full release notes: http://hledger.org/release-notes#hledger-0.26 . Release contributors: Simon Michael, Imuli, Carlos Lopez-Camey, Kyle Marek-Spartz, Rick Lupton, Simon Hengel. About: hledger (http://hledger.org) is a command-line tool and haskell library for tracking financial transactions, which are stored in a human-readable plain text format. It can also read CSV or timelog files, and output CSV. It provides useful reports, and can also help you record new transactions interactively. Add-on commands include hledger-web (a web interface), hledger-irr (for calculating internal rate of return) and hledger-interest (for generating interest transactions). hledger is inspired by and largely compatible with Ledger, and can be used with some Ledger files. Installation: $ cabal update [$ cabal sandbox init] $ cabal install hledger[-web]-0.26 or: install stack (https://github.com/commercialhaskell/stack/wiki/Downloads ) $ stack --resolver nightly-2015-07-13 install hledger [hledger-web] or: $ git clone https://github.com/simonmichael/hledger.git $ cd hledger $ git checkout hledger-0.26 $ stack install or see http://hledger.org/download for more options. Best! -Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Jul 15 02:14:18 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 14 Jul 2015 19:14:18 -0700 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? Message-ID: Hello, I have been looking at Hackage for a package/library that supports Haskell interoperability with Java/Scala. Didn't see any such support. If true, is there any project in the works? Thanks, Vasili From ruben.astud at gmail.com Wed Jul 15 02:35:06 2015 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Tue, 14 Jul 2015 23:35:06 -0300 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: <55A5C6DA.30006@gmail.com> On 14/07/15 23:14, Vasili I. Galchin wrote: > Hello, > > I have been looking at Hackage for a package/library that > supports Haskell interoperability with Java/Scala. Didn't see any such > support. If true, is there any project in the works? Frege [1] seems to be the go to option for something like haskell on the JVM. Interoperation between GHC's haskell code and the JVM seems to be not that easy. [1]: https://github.com/Frege/frege -- Ruben Astudillo OpenPGP: 0x3C332311 Crear un haiku, en diecisiete silabas, es complica... From vigalchin at gmail.com Wed Jul 15 03:02:02 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 14 Jul 2015 20:02:02 -0700 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: <55A5C6DA.30006@gmail.com> References: <55A5C6DA.30006@gmail.com> Message-ID: Ruben, When you write "not that easy", is it because Frege is first compiled into Java vs directly calling the JVM?? Vasili On Tuesday, July 14, 2015, Ruben Astudillo wrote: > On 14/07/15 23:14, Vasili I. Galchin wrote: > >> Hello, >> >> I have been looking at Hackage for a package/library that >> supports Haskell interoperability with Java/Scala. Didn't see any such >> support. If true, is there any project in the works? >> > > Frege [1] seems to be the go to option for something like haskell on the > JVM. Interoperation between GHC's haskell code and the JVM seems to be > not that easy. > > [1]: https://github.com/Frege/frege > > -- > Ruben Astudillo OpenPGP: 0x3C332311 > Crear un haiku, en diecisiete silabas, es complica... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dagitj at gmail.com Wed Jul 15 03:06:36 2015 From: dagitj at gmail.com (Jason Dagit) Date: Tue, 14 Jul 2015 20:06:36 -0700 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: <55A5C6DA.30006@gmail.com> Message-ID: He's likely referring to the issues raised here: https://wiki.haskell.org/GHC:FAQ#Why_isn.27t_GHC_available_for_.NET_or_on_the_JVM.3F On Tue, Jul 14, 2015 at 8:02 PM, Vasili I. Galchin wrote: > Ruben, > > When you write "not that easy", is it because Frege is first > compiled into Java vs directly calling the JVM?? > > Vasili > > On Tuesday, July 14, 2015, Ruben Astudillo wrote: > >> On 14/07/15 23:14, Vasili I. Galchin wrote: >> >>> Hello, >>> >>> I have been looking at Hackage for a package/library that >>> supports Haskell interoperability with Java/Scala. Didn't see any such >>> support. If true, is there any project in the works? >>> >> >> Frege [1] seems to be the go to option for something like haskell on the >> JVM. Interoperation between GHC's haskell code and the JVM seems to be >> not that easy. >> >> [1]: https://github.com/Frege/frege >> >> -- >> Ruben Astudillo OpenPGP: 0x3C332311 >> Crear un haiku, en diecisiete silabas, es complica... >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vigalchin at gmail.com Wed Jul 15 03:13:00 2015 From: vigalchin at gmail.com (Vasili I. Galchin) Date: Tue, 14 Jul 2015 20:13:00 -0700 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: I am looking to suppprt Haskell (OCaml ??) for apache.spark.org. Currently there is support for programming language "R" which has functional features (not as rich as Haskell, OCaml, et. al.) and does lazy evaluation. I am going to drop back and look at the R->Scala/Java implementation BUT I will also read your link. Any more.suggestions are gratefully welcome. Kind thx, Vasili On Tuesday, July 14, 2015, Jason Dagit wrote: > Did you look at java bridge? > * https://hackage.haskell.org/package/java-bridge > > Perhaps counter-intuitively, you're probably better off defining a > protocol and using that for interop. Something like zeromq could simplify > the communication. > > The main hassle with a full interop is the difference between the notions > of types in the two languages. For instance, subtyping on the Java side > doesn't really map well to the Haskell side. > > I would say that it forces attempts at a general interop to go with a > least common denominator approach. In the extreme, this degenerates back to > having the code on each side pretend like it's talking to C. > > Whereas designing a message protocol for your task allows you to > incorporate domain specific knowledge and thus avoid a general solution and > also leave out things you will never use. > > On Tue, Jul 14, 2015 at 7:14 PM, Vasili I. Galchin > wrote: > >> Hello, >> >> I have been looking at Hackage for a package/library that >> supports Haskell interoperability with Java/Scala. Didn't see any such >> support. If true, is there any project in the works? >> >> Thanks, >> >> Vasili >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kjeldaas at gmail.com Wed Jul 15 05:49:03 2015 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Wed, 15 Jul 2015 07:49:03 +0200 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: I don't know of any project that does interopability, but I don't think there is any technical issues blocking this. The GHC RTS and the JVM RTS should be able to run in the same process using their respective parts of the heap. Initially you would want the set of threads managed by the JVM to be separate from the GHC RTS threads, but it might even be possible to have call directly from one to the other (through C). Alexander On Wed, Jul 15, 2015 at 5:13 AM, Vasili I. Galchin wrote: > I am looking to suppprt Haskell (OCaml ??) for apache.spark.org. > Currently there is support for programming language "R" which has > functional features (not as rich as Haskell, OCaml, et. al.) and does lazy > evaluation. I am going to drop back and look at the R->Scala/Java > implementation BUT I will also read your link. Any more.suggestions are > gratefully welcome. > > Kind thx, > > Vasili > > On Tuesday, July 14, 2015, Jason Dagit wrote: > >> Did you look at java bridge? >> * https://hackage.haskell.org/package/java-bridge >> >> Perhaps counter-intuitively, you're probably better off defining a >> protocol and using that for interop. Something like zeromq could simplify >> the communication. >> >> The main hassle with a full interop is the difference between the notions >> of types in the two languages. For instance, subtyping on the Java side >> doesn't really map well to the Haskell side. >> >> I would say that it forces attempts at a general interop to go with a >> least common denominator approach. In the extreme, this degenerates back to >> having the code on each side pretend like it's talking to C. >> >> Whereas designing a message protocol for your task allows you to >> incorporate domain specific knowledge and thus avoid a general solution and >> also leave out things you will never use. >> >> On Tue, Jul 14, 2015 at 7:14 PM, Vasili I. Galchin >> wrote: >> >>> Hello, >>> >>> I have been looking at Hackage for a package/library that >>> supports Haskell interoperability with Java/Scala. Didn't see any such >>> support. If true, is there any project in the works? >>> >>> Thanks, >>> >>> Vasili >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Wed Jul 15 12:43:46 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Wed, 15 Jul 2015 13:43:46 +0100 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: I'm working on a Java binding generator as a side project that embeds the Java type system into Haskell quite well. Stay tuned! On Wed, Jul 15, 2015 at 3:14 AM, Vasili I. Galchin wrote: > Hello, > > I have been looking at Hackage for a package/library that > supports Haskell interoperability with Java/Scala. Didn't see any such > support. If true, is there any project in the works? > > Thanks, > > Vasili > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikita at karetnikov.org Wed Jul 15 12:50:57 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Wed, 15 Jul 2015 15:50:57 +0300 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: (Patrick Chilton's message of "Wed, 15 Jul 2015 13:43:46 +0100") References: Message-ID: <87r3o91t5a.fsf@karetnikov.org> There's also a parser for Scala: https://github.com/puffnfresh/language-scala When I tried it (months ago), it couldn't parse scalac source, though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From nikita at karetnikov.org Wed Jul 15 12:57:26 2015 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Wed, 15 Jul 2015 15:57:26 +0300 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: <87r3o91t5a.fsf@karetnikov.org> (Nikita Karetnikov's message of "Wed, 15 Jul 2015 15:50:57 +0300") References: <87r3o91t5a.fsf@karetnikov.org> Message-ID: <87mvyx1suh.fsf@karetnikov.org> Oh, someone has mentioned Frege, but there's also Ermine: https://github.com/ermine-language -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: From atzeus at gmail.com Wed Jul 15 13:25:26 2015 From: atzeus at gmail.com (Atze van der Ploeg) Date: Wed, 15 Jul 2015 15:25:26 +0200 Subject: [Haskell-cafe] [ANN] frpnow-0.12 Message-ID: Dear Cafe, We have released the (nearly) first version of FRPNow, the functional reactive programming library based on the ICFP 2015 paper "Principled Practical FRP: Forget the Past, Change the Future, FRPNow!" ( https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ ) The main package: http://hackage.haskell.org/package/frpnow Examples: https://github.com/atzeus/FRPNow/tree/master/Examples Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk (hackage doesn't like the newer GTK docs, so you can read the docs at http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) Cheers, Atze -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at degoes.net Wed Jul 15 14:55:01 2015 From: john at degoes.net (John A. De Goes) Date: Wed, 15 Jul 2015 08:55:01 -0600 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: This is a herculean effort due, among other things, to Spark?s heavy reliance on function serialization. Not to say you can?t do it, but it?s going to be a huge amount of effort to build and maintain it in any way that provides feature parity with any JVM language on Spark, and of course you?re going to be going Haskell -> C -> JVM, and JVM -> C -> Haskell for everything, which entails its own set of delightful pains. If you?re not too picky about the ML, I?d suggest a better path is contributing to PureScript on the JVM (either that project or another one). PureScript?s semantics map cleanly to the JVM?s and very good native interop is possible; in addition, the PureScript compiler is designed for compiling to different backends (i.e. it has no runtime and will necessarily utilize the target?s native runtime environment). One could ease Spark integration by targeting TASTY or generating functional code compatible with Scala / Java 8 runtimes. --? John A. De Goes Follow me @jdegoes On July 14, 2015 at 9:13:05 PM, Vasili I. Galchin (vigalchin at gmail.com) wrote: I am looking to suppprt Haskell (OCaml ??) for apache.spark.org. Currently there is support for programming language "R" which has functional features (not as rich as Haskell, OCaml, et. al.) and does lazy evaluation. I am going to drop back and look at the R->Scala/Java implementation BUT I will also read your link.? Any more.suggestions are gratefully welcome. Kind thx, Vasili On Tuesday, July 14, 2015, Jason Dagit wrote: Did you look at java bridge? ? *?https://hackage.haskell.org/package/java-bridge Perhaps counter-intuitively, you're probably better off defining a protocol and using that for interop. Something like zeromq could simplify the communication. The main hassle with a full interop is the difference between the notions of types in the two languages. For instance, subtyping on the Java side doesn't really map well to the Haskell side. I would say that it forces attempts at a general interop to go with a least common denominator approach. In the extreme, this degenerates back to having the code on each side pretend like it's talking to C. Whereas designing a message protocol for your task allows you to incorporate domain specific knowledge and thus avoid a general solution and also leave out things you will never use. On Tue, Jul 14, 2015 at 7:14 PM, Vasili I. Galchin wrote: Hello, ? ? ? I have been looking at Hackage for a package/library that supports Haskell interoperability with Java/Scala. Didn't see any such support. If true, is there any project in the works? Thanks, Vasili _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Wed Jul 15 16:06:36 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 15 Jul 2015 16:06:36 +0000 Subject: [Haskell-cafe] [ANN] frpnow-0.12 In-Reply-To: References: Message-ID: Congrats on the release! Can't wait to have a play with this - am curious how it compares to reactive-banana. - ocharles On Wed, Jul 15, 2015 at 2:25 PM Atze van der Ploeg wrote: > Dear Cafe, > > We have released the (nearly) first version of FRPNow, the functional > reactive programming library based on the ICFP 2015 paper "Principled > Practical FRP: Forget the Past, Change the Future, FRPNow!" ( > https://www.reddit.com/r/haskell/comments/3ai7hl/principled_practical_frp_forget_the_past_change/ > ) > > The main package: http://hackage.haskell.org/package/frpnow > > Examples: https://github.com/atzeus/FRPNow/tree/master/Examples > > Gloss interoperability: http://hackage.haskell.org/package/frpnow-gloss > > GTK interoperability: http://hackage.haskell.org/package/frpnow-gtk > > (hackage doesn't like the newer GTK docs, so you can read the docs at > http://www.cse.chalmers.se/~atze/frpnow-gtk/ ) > > > Cheers, > > > Atze > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Jul 15 18:52:53 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 15 Jul 2015 19:52:53 +0100 Subject: [Haskell-cafe] Haskell & Java/Scala interoperbility? In-Reply-To: References: Message-ID: <20150715185253.GZ22437@weber> On Wed, Jul 15, 2015 at 08:55:01AM -0600, John A. De Goes wrote: > If you?re not too picky about the ML, I?d suggest a better path is > contributing to PureScript on the JVM (either that project or another > one). PureScript?s semantics map cleanly to the JVM?s and very good > native interop is possible; in addition, the PureScript compiler is > designed for compiling to different backends (i.e. it has no runtime and > will necessarily utilize the target?s native runtime environment). Could you explain why PureScript is easier to port to the JVM? In particular I don't understand why its "semantics map cleanly to the JVM?s" but Haskell's don't. Tom From marcin.jan.mrotek at gmail.com Thu Jul 16 15:02:26 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 16 Jul 2015 17:02:26 +0200 Subject: [Haskell-cafe] ANN: repa-linear-algebra = HMatrix + REPA Message-ID: Hello, Given that apparently HMatrix uses the same underlying representation as F arrays in REPA, I've wrote some utilities to convert to and from these types, and ported HMatrix functions to work with REPA arrays. http://hackage.haskell.org/package/repa-linear-algebra-0.0.0.0 All functions return F arrays. In general, unqualified functions take F array(s), and the postfixed functions take D array(s), allocating them before feeding to HMatrix: * -S functions allocate sequentially (using computeS) * -SIO functions allocate sequentially inside the IO monad (using computeIntoS) * -P functions allocate in parallel (using computeP) * -PIO functions allocate in parallel inside the IO monad (using computeIntoP) Writing all that boilerplate was quite mind-numbing, so sorry if there are any mistakes or inconsistencies (I wish this was a way to automate it, but it's not always straightforwards, for example I've decided that arguments that will be often supplied unchanged to multiple calls (like the kernel of convolution) shouldn't be changed to take D arrays in the preallocating functions). Please have in mind that the module is HIGHLY experimental, as it does just plain rude casts under the hood. Before you use it for anything serious first check if it works as you expect it to. Best regards, Marcin Mrotek From eric at oco.nnor.org Thu Jul 16 19:49:20 2015 From: eric at oco.nnor.org (Eric O'Connor) Date: Thu, 16 Jul 2015 13:49:20 -0600 Subject: [Haskell-cafe] wiki username request: Eric Message-ID: <55A80AC0.1070805@oco.nnor.org> Eric true Thu Jul 16 13:45:49 MDT 2015 From hjgtuyl at chello.nl Thu Jul 16 22:09:24 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 17 Jul 2015 00:09:24 +0200 Subject: [Haskell-cafe] wiki username request: Eric In-Reply-To: <55A80AC0.1070805@oco.nnor.org> References: <55A80AC0.1070805@oco.nnor.org> Message-ID: On Thu, 16 Jul 2015 21:49:20 +0200, Eric O'Connor wrote: > > Eric > true > > Thu Jul 16 13:45:49 MDT 2015 > Done Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From josef.svenningsson at chalmers.se Fri Jul 17 00:26:25 2015 From: josef.svenningsson at chalmers.se (Josef Svenningsson) Date: Fri, 17 Jul 2015 00:26:25 +0000 Subject: [Haskell-cafe] Call for Contributions: Haskell Implementors' Workshop 2015 Message-ID: Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2015 Vancouver, Canada, 30 August, 2015 Co-located with ICFP 2015 http://www.icfpconference.org/icfp2015/ Important dates --------------- Proposal Deadline: Monday, 3 August, 2015 (midnight, anywhere on earth) Notification: Monday, 10 August, 2015 Workshop: Sunday, 30 August, 2015 The 7th Haskell Implementors' Workshop is to be held alongside ICFP 2015 this year in Vancouver. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Attendance figures clearly reflect the growth of the Haskell user community and a constant interest in implementation aspects. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2015. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw15.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers ---------- * Richard Eisenberg (University of Pennsylvania) * Edward Kmett (S&P Capital IQ) * Hans-Wolfgang Loidl (Heriot-Watt University) * Trevor L. McDonell (Indiana University) * Deian Stefan (Stanford University) * Josef Svenningsson - chair (Chalmers University of Technology) Contact ------- * Josef Svenningsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Fri Jul 17 06:19:45 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 16 Jul 2015 23:19:45 -0700 Subject: [Haskell-cafe] very general directed hypergraphs over text Message-ID: I'm writing a graph class that generalizes the traditional mathematical graph: Nodes can be statements or relationships, and relationships ("edges") can involve any number of nodes, including other relationships. [1] describes the motivation in a little more detail. [2] explains the idea behind the major types -- Graph, Node, Stmt, and Rel. Of the .hs files in the project, at this time I believe only the primary one, Dwt.hs [3], deserves your attention. It is only about 100 lines of code. I am interested in any kind of feedback at all, no matter how minute in detail or expansive in scope. [4] lists what I already think might be likely problems and solutions. In particular I wonder whether I should interpret these two patterns: "case ni of Rel -> .. Stmt -> .." and "if (Maybe.isJust nMb) ... else error ..." as signs that I'm not completely solving the problem. I suspect it might be helpful to make the graph operations Maybe or Either, and use <|> on them -- but while I can monkey those words, I don't really know what I'm saying. [1] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/motivation.txt [2] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/how_it_works.txt [3] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/src/Dwt.hs [4] https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/todo%2Cmaybe.txt Thank you, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergueyz at gmail.com Fri Jul 17 09:14:09 2015 From: sergueyz at gmail.com (Serguey Zefirov) Date: Fri, 17 Jul 2015 12:14:09 +0300 Subject: [Haskell-cafe] very general directed hypergraphs over text In-Reply-To: References: Message-ID: First, make statement structure richer. Instead of just String, make its' parameter a list of something like this: data SExpr = Underscore | Word String and Stmt thus: data Stmt = Stmt [SExpr] This way it is easier to construct and/or combine. Second, make graph operations to operate on bulk of data. Singleton data is a special case of bulk data and bulk operations are much more efficient in general. So instead of addRelIdxToNode :: RelIdx -> Node -> Node create something like addRelIdxToNodes :: RelIdx -> [Node] -> [Node] (use your collection of choice instead of lists). This will pay rather quickly (in terms of performance and brevity). Those are my two humble suggestions. 2015-07-17 9:19 GMT+03:00 Jeffrey Brown : > I'm writing a graph class that generalizes the traditional mathematical > graph: Nodes can be statements or relationships, and relationships > ("edges") can involve any number of nodes, including other relationships. > [1] describes the motivation in a little more detail. > > [2] explains the idea behind the major types -- Graph, Node, Stmt, and Rel. > > Of the .hs files in the project, at this time I believe only the primary > one, Dwt.hs [3], deserves your attention. It is only about 100 lines of > code. > > I am interested in any kind of feedback at all, no matter how minute in > detail or expansive in scope. > > [4] lists what I already think might be likely problems and solutions. In > particular I wonder whether I should interpret these two patterns: > "case ni of Rel -> .. Stmt -> .." > and > "if (Maybe.isJust nMb) ... else error ..." > as signs that I'm not completely solving the problem. > > I suspect it might be helpful to make the graph operations Maybe or > Either, and use <|> on them -- but while I can monkey those words, I don't > really know what I'm saying. > > [1] > https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/motivation.txt > [2] > https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/how_it_works.txt > [3] > https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/src/Dwt.hs > [4] > https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/english/todo%2Cmaybe.txt > > Thank you, > Jeff > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brucker at spamfence.net Fri Jul 17 17:23:16 2015 From: brucker at spamfence.net (Achim D. Brucker) Date: Fri, 17 Jul 2015 19:23:16 +0200 Subject: [Haskell-cafe] OCL 2015: ** Deadline Extension ** Submit Your Paper Until July 26, 2015 Message-ID: <20150717172316.GA4034@fujikawa.home.brucker.ch> (Apologies for duplicates) If you are working on the foundations, methods, or tools for OCL or textual modelling, you should now finalise your submission for the OCL workshop! *** The submission deadline has been extended to July 26th, 2015! *** CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. Topics of interest include (but are not limited to) =================================================== - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for -- validation, verification, and testing, -- model transformation and code generation, -- meta-modeling and DSLs, and -- query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports -- usage of textual modeling languages and tools in complex domains, -- usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing tools that support - in a very broad sense - textual modeling languages (if you have implemented OCL.js to run OCL in a web browser, this is the right workshop to present your work) as well as textual model transformations. Venue ===== The workshop will be organized as a part of MODELS 2015 Conference in Ottawa, Canada. It continues the series of OCL workshops held at UML/MODELS conferences: York (2000), Toronto (2001), San Francisco (2003), Lisbon (2004), Montego Bay (2005), Genova (2006), Nashville (2007), Toulouse (2008), Denver (2009), Oslo (2010), Zurich (2011, at the TOOLs conference), 2012 in Innsbruck, 2013 in Miami, and 2014 in Valencia, Spain. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. Workshop Format =============== The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. Submissions =========== Three types of papers will be considered: * short papers (between 6 and 8 pages) describing ideas, * tool papers (between 6 and 8 pages), and * full papers (between 12 and 16 pages) in LNCS format. Submissions should be uploaded to EasyChair (https://easychair.org/conferences/?conf=ocl20150). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a pre-conference edition of CEUR (http://www.ceur-ws.org). Important Dates =============== Submission of papers: July 26, 2015 (extended) Notification: August 21, 2015 Workshop date: September 28, 2015 Organizers ========== Achim D. Brucker, SAP SE, Germany Marina Egea, Indra Sistemas S.A., Spain Martin Gogolla, University of Bremen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Programme Committee =================== Mira Balaban, Ben-Gurion University of the Negev, Israel Tricia Balfe, Nomos Software, Ireland Achim D. Brucker, SAP SE, Germany Fabian Buettner, Inria - Ecole des Mines de Nantes, France Jordi Cabot, Inria - Ecole des Mines de Nantes, France Dan Chiorean, Babes-Bolyai University, Romania Robert Clariso, Universitat Oberta de Catalunya, Spain Tony Clark, Middlesex University, UK Manuel Clavel, IMDEA Software Institute, Spain Carolina Dania, IMDEA Software Institute, Spain Birgit Demuth, Technische Universitat Dresden, Germany Marina Egea, Indra Sistemas S.A., Spain Geri Georg, Colorado State University, USA Martin Gogolla, University of Bremen, Germany Shahar Maoz, Tel Aviv University, Israel Istvan Rath, Budapest University of Technology and Economics, Hungary Bernhard Rumpe, RWTH Aachen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Claas Wilke, Technische Universitat Dresden, Germany Edward Willink, Willink Transformations Ltd., UK Burkhart Wolff, Univ. Paris-Sud - LRI, France Steffen Zschaler, King's College, UK -- Dr. Achim D. Brucker, SAP SE, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/ From ab at fmap.me Fri Jul 17 18:37:04 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Fri, 17 Jul 2015 21:37:04 +0300 Subject: [Haskell-cafe] Strange error message with PolyKinds Message-ID: <55A94B50.8060609@fmap.me> Hi Cafe, I've bumped into a strange error message -- it looks like an obvious bug, but maybe there's something that I'm just not aware of: GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghci> type Test a = a ghci> type Huh = Test :3:1: Type synonym ?Test? should have 1 argument, but has been given none In the type declaration for ?Huh? So far, so good: ghci> :set -XPolyKinds ghci> type Test a = a ghci> type Huh = Test :6:1: Type synonym ?Test? should have 2 arguments, but has been given 1 In the type declaration for ?Huh? (Notice the number of arguments reported in the second case) -- Nikolay. From anselm.scholl at tu-harburg.de Fri Jul 17 19:53:46 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Fri, 17 Jul 2015 21:53:46 +0200 Subject: [Haskell-cafe] Strange error message with PolyKinds In-Reply-To: <55A94B50.8060609@fmap.me> References: <55A94B50.8060609@fmap.me> Message-ID: <55A95D4A.4010203@tu-harburg.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would guess the two arguments are a kind and a type of that kind. The kind is given implicitly, so this corresponds to your one given argument. If we specify a kind, we get the following: Prelude> :set -XPolyKinds -XDataKinds -XKindSignatures Prelude> type Test a = a Prelude> type Huh a = Test (a :: Bool) Prelude> type Bar = Huh :5:1: Type synonym ?Huh? should have 1 argument, but has been given none In the type declaration for ?Bar? So it really takes two arguments and we can specify one, leaving one to be specified. Maybe a better error message would be useful, but I would not say this is a bug. On 07/17/2015 08:37 PM, Nikolay Amiantov wrote: > Hi Cafe, > > I've bumped into a strange error message -- it looks like an obvious > bug, but maybe there's something that I'm just not aware of: > > GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help > ghci> type Test a = a > ghci> type Huh = Test > > :3:1: > Type synonym ?Test? should have 1 argument, but has been given none > In the type declaration for ?Huh? > > So far, so good: > > ghci> :set -XPolyKinds > ghci> type Test a = a > ghci> type Huh = Test > > :6:1: > Type synonym ?Test? should have 2 arguments, but has been given 1 > In the type declaration for ?Huh? > > (Notice the number of arguments reported in the second case) > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVqV0gAAoJEM0PYZBmfhoBEYYH/2dbUfsM9X9EKRaGdrsGmRlx Yj51KkvO8uGDfoFfu++JuCY/o0poD3/NQLUtHOrUx9tKrGD+Kksoqs5+3jKdKWhb x4SITIShOOd31qwwKdfs7QaTdrP1cyr/km9U5wP5o8Zgf9XCUI337RC6HRuhphcb Ytk+We3ZODy1+SewMjYvJvOiTfzTAa3u4zW1arEcXMXaaIcyMwtfH+UMgSljbBUt K9nfWE73klyftae3duSonML0fwTgUepnhRrZ+weIS0fEHqfJDsy4KJKqJGm2ee8T w72D69FNVvwkL46TH7rZKhHyh3k7Ct5SHb14IqyDDduobFtswfhCpGjdLXyfn3o= =5hgl -----END PGP SIGNATURE----- From ab at fmap.me Fri Jul 17 20:13:33 2015 From: ab at fmap.me (Nikolay Amiantov) Date: Fri, 17 Jul 2015 23:13:33 +0300 Subject: [Haskell-cafe] Strange error message with PolyKinds In-Reply-To: <55A95D4A.4010203@tu-harburg.de> References: <55A94B50.8060609@fmap.me> <55A95D4A.4010203@tu-harburg.de> Message-ID: <55A961ED.5050905@fmap.me> Thanks, it indeed looks so! I guess better error message would be desirable; reported as #10654. On 07/17/2015 10:53 PM, Jonas Scholl wrote: > > I would guess the two arguments are a kind and a type of that kind. The > kind is given implicitly, so this corresponds to your one given > argument. If we specify a kind, we get the following: > > Prelude> :set -XPolyKinds -XDataKinds -XKindSignatures > Prelude> type Test a = a > Prelude> type Huh a = Test (a :: Bool) > Prelude> type Bar = Huh > > :5:1: > Type synonym ?Huh? should have 1 argument, but has been given none > In the type declaration for ?Bar? > > So it really takes two arguments and we can specify one, leaving one to > be specified. Maybe a better error message would be useful, but I would > not say this is a bug. -- Nikolay. From icfp.publicity at googlemail.com Sat Jul 18 16:49:21 2015 From: icfp.publicity at googlemail.com (David Van Horn) Date: Sat, 18 Jul 2015 12:49:21 -0400 Subject: [Haskell-cafe] ICFP 2015 Call for Participation Message-ID: [ Early registration ends 3 August. ] ===================================================================== Call for Participation ICFP 2015 20th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 30 - September 5, 2015 Vancouver, British Columbia, Canada http://icfpconference.org/icfp2015/ ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. A full week dedicated to functional programming: 1 conference, 1 symposium, 11 workshops, tutorials, programming contest results, student research competition, and mentoring workshop * Program: http://icfpconference.org/icfp2015/program.html * Accepted Papers: http://icfpconference.org/icfp2015/accepted.html * Affiliated Events: http://icfpconference.org/icfp2015/affiliated.html * Local arrangements (including travel and accommodation): http://icfpconference.org/icfp2015/local.html * Registration is available via: https://regmaster4.com/2015conf/ICFP15/register.php Early registration is due 3 August, 2015. * Programming contest, 7-10 August, 2015: http://icfpcontest.org/ * Follow @icfp_conference on twitter for the latest news: http://twitter.com/icfp_conference There are several events affiliated with ICFP: Sunday, August 30 Haskell Implementors Workshop Workshop on Higher-order Programming with Effects Workshop on Generic Programming Programming Languages Mentoring Workshop Ally Skills Tutorial Monday, August 31 ? Wednesday, September 2 ICFP Thursday, September 3 Workshop on Functional High-Performance Computing Haskell Symposium ? Day 1 ML Family Workshop Commercial Users of Functional Programming ? Day 1 Friday, September 4 Erlang Workshop Haskell Symposium ? Day 2 OCaml Workshop Commercial Users of Functional Programming ? Day 2 Scheme and Functional Programming Workshop Saturday, September 5 Functional Art, Music, Modeling and Design Commercial Users of Functional Programming ? Day 3 Conference Organizers General Chair: Kathleen Fisher, Tufts University Program Chair: John Reppy, University of Chicago Local Arrangements Chair: Ronald Garcia, University of British Columbia Industrial Relations Chair: Anil Madhavapeddy, University of Cambridge Workshop Co-Chairs: Tom Schrijvers, KU Leuven Nicolas Wu, University of Bristol Programming Contest Chair: Joe Kiniry, Galois Student Research Competition Chair: Andrew Kennedy, Microsoft Research Mentoring Workshop Co-Chairs: Ronald Garcia, University of British Columbia Stephanie Weirich, University of Pennsylvania Publicity Chair: David Van Horn, University of Maryland Video Chair: Iavor Diatchki, Galois Student Volunteer Co-Chairs: Felipe Ba?ados Schwerter, University of British Columbia Gabriel Scherer, INRIA Mobile App Chair: Reid Holmes, University of Waterloo Industrial partners: Platinum partners Jane Street Capital Gold partners Anonymous donor Ahrefs Google Mozilla Research Oracle Labs Silver partners Bloomberg Tsuru Capital Galois The University of Chicago Bronze partners Erlang Solutions FireEye IntelliFactory PivotCloud Systor Vest ===================================================================== From clintonmead at gmail.com Sun Jul 19 00:13:54 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 19 Jul 2015 10:13:54 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? Message-ID: Lets say I've got the following data type: data D c a b = D (c a b) (c b a) And I define a function to manipulate it: apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 b2 apply f1 f2 (D x y) = D (f1 x) (f2 y) This is all fine. But I want a shorter function if (f1 = f2). So I write: applyBoth f = apply f f I originally thought that if "apply f f" is valid, then logically "applyBoth f" should also be valid. But it seems that type inference results in applyBoth only working for functions "c a a -> c a2 a2". Is there a way to type "applyBoth" so it works for all functions that would work simply by repeating them twice in "apply"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sun Jul 19 00:23:27 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 19 Jul 2015 10:23:27 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: On 19 July 2015 at 10:13, Clinton Mead wrote: > Lets say I've got the following data type: > > data D c a b = D (c a b) (c b a) > > And I define a function to manipulate it: > > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 b2 > apply f1 f2 (D x y) = D (f1 x) (f2 y) > > This is all fine. But I want a shorter function if (f1 = f2). So I write: > > applyBoth f = apply f f > > I originally thought that if "apply f f" is valid, then logically "applyBoth > f" should also be valid. But it seems that type inference results in > applyBoth only working for functions "c a a -> c a2 a2". applyBoth f = apply f f In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 (as the above two type signatures must match since f1 = f2). So we must have that (f :: c a a -> c a2 a2). > > Is there a way to type "applyBoth" so it works for all functions that would > work simply by repeating them twice in "apply"? I'm not sure what you mean; what else would make sense? Can you provide an example? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ivan.miljenovic at gmail.com Sun Jul 19 07:54:00 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 19 Jul 2015 17:54:00 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: (Re-CC'ing Cafe) I think what's happening here is that when you do "apply f1 f1", the two c's and d's don't actually match with each other. But when you do it with applyBoth, they *have* to match each other. As a comparison, compare: :t (read, read) (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) and :t Control.Monad.join read Control.Monad.join (,) read :: Read a => (String -> a, String -> a) I'm not sure how you could define such a function to do what you're requesting; my attempt is this: applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> D arr a2 b2 applyBoth f = apply f f but whilst ghci accepts it, I couldn't actually seem to use it (lots of errors about being unable to match types). On 19 July 2015 at 17:15, Clinton Mead wrote: > Thanks for your reply Ivan > > Here's a full code example ( http://ideone.com/1K3Yhw ): > > --- > > data D c a b = D (c a b) (c b a) > > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 b2 > apply f1 f2 (D x y) = D (f1 x) (f2 y) > > applyBoth f = apply f f > > f :: Int -> String > f = show > > g :: String -> Int > g = read > > h :: Int -> Int > h = (*2) > > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) > join f g (x, y) = (f x, g y) > > x1 = D f g > > f1 = join h > > y1 = apply f1 f1 x1 -- This compiles > y2 = apply g g x1 where g = f1 -- Also works > > z1 = applyBoth f1 x1 -- This fails > > main = return () > > --- > > You see, with "y1" and "y2", a different "f1" instantiation (is that the > right word) of "f1" is chosen. Even when I let "g = f1", each "g" passed to > apply is different, the first operates on "Int -> String", the second, > "String -> Int". > > On the face of it, if: > > f x = g x x > > Then well, you should be able to replace "g x x" with "f x" wherever you see > it. > > But it seems in this case this doesn't work. Surely Haskell doesn't require > me to "repeat myself", and there's a way to write "applyBoth", instead of > having to write "apply f f" (note the repetition of f) all the time? > > I assume there's some type signature I can give "applyBoth f" so it can be > used just like "apply f f" but I can't work out what it is. > > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic > wrote: >> >> On 19 July 2015 at 10:13, Clinton Mead wrote: >> > Lets say I've got the following data type: >> > >> > data D c a b = D (c a b) (c b a) >> > >> > And I define a function to manipulate it: >> > >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 >> > b2 >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> > >> > This is all fine. But I want a shorter function if (f1 = f2). So I >> > write: >> > >> > applyBoth f = apply f f >> > >> > I originally thought that if "apply f f" is valid, then logically >> > "applyBoth >> > f" should also be valid. But it seems that type inference results in >> > applyBoth only working for functions "c a a -> c a2 a2". >> >> applyBoth f = apply f f >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). >> >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 >> (as the above two type signatures must match since f1 = f2). >> >> So we must have that (f :: c a a -> c a2 a2). >> >> > >> > Is there a way to type "applyBoth" so it works for all functions that >> > would >> > work simply by repeating them twice in "apply"? >> >> I'm not sure what you mean; what else would make sense? Can you >> provide an example? >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From clintonmead at gmail.com Sun Jul 19 08:08:14 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 19 Jul 2015 18:08:14 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: Thanks for the CC Ivan, forgot to "reply all". I guess I want the passed argument to stay polymorphic long enough to be instanced inside the call. Surely if "f x = g x x" then you should somehow be able to replace "g x x" with "f x"?! That's basically what I'm getting at. On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > (Re-CC'ing Cafe) > > I think what's happening here is that when you do "apply f1 f1", the > two c's and d's don't actually match with each other. > > But when you do it with applyBoth, they *have* to match each other. > > As a comparison, compare: > > :t (read, read) > (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) > > and > > :t Control.Monad.join read > Control.Monad.join (,) read :: Read a => (String -> a, String -> a) > > I'm not sure how you could define such a function to do what you're > requesting; my attempt is this: > > applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> > D arr a2 b2 > applyBoth f = apply f f > > but whilst ghci accepts it, I couldn't actually seem to use it (lots > of errors about being unable to match types). > > On 19 July 2015 at 17:15, Clinton Mead wrote: > > Thanks for your reply Ivan > > > > Here's a full code example ( http://ideone.com/1K3Yhw ): > > > > --- > > > > data D c a b = D (c a b) (c b a) > > > > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 b2 > > apply f1 f2 (D x y) = D (f1 x) (f2 y) > > > > applyBoth f = apply f f > > > > f :: Int -> String > > f = show > > > > g :: String -> Int > > g = read > > > > h :: Int -> Int > > h = (*2) > > > > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) > > join f g (x, y) = (f x, g y) > > > > x1 = D f g > > > > f1 = join h > > > > y1 = apply f1 f1 x1 -- This compiles > > y2 = apply g g x1 where g = f1 -- Also works > > > > z1 = applyBoth f1 x1 -- This fails > > > > main = return () > > > > --- > > > > You see, with "y1" and "y2", a different "f1" instantiation (is that the > > right word) of "f1" is chosen. Even when I let "g = f1", each "g" passed > to > > apply is different, the first operates on "Int -> String", the second, > > "String -> Int". > > > > On the face of it, if: > > > > f x = g x x > > > > Then well, you should be able to replace "g x x" with "f x" wherever you > see > > it. > > > > But it seems in this case this doesn't work. Surely Haskell doesn't > require > > me to "repeat myself", and there's a way to write "applyBoth", instead of > > having to write "apply f f" (note the repetition of f) all the time? > > > > I assume there's some type signature I can give "applyBoth f" so it can > be > > used just like "apply f f" but I can't work out what it is. > > > > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic > > wrote: > >> > >> On 19 July 2015 at 10:13, Clinton Mead wrote: > >> > Lets say I've got the following data type: > >> > > >> > data D c a b = D (c a b) (c b a) > >> > > >> > And I define a function to manipulate it: > >> > > >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 > >> > b2 > >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> > > >> > This is all fine. But I want a shorter function if (f1 = f2). So I > >> > write: > >> > > >> > applyBoth f = apply f f > >> > > >> > I originally thought that if "apply f f" is valid, then logically > >> > "applyBoth > >> > f" should also be valid. But it seems that type inference results in > >> > applyBoth only working for functions "c a a -> c a2 a2". > >> > >> applyBoth f = apply f f > >> > >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). > >> > >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 > >> (as the above two type signatures must match since f1 = f2). > >> > >> So we must have that (f :: c a a -> c a2 a2). > >> > >> > > >> > Is there a way to type "applyBoth" so it works for all functions that > >> > would > >> > work simply by repeating them twice in "apply"? > >> > >> I'm not sure what you mean; what else would make sense? Can you > >> provide an example? > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sun Jul 19 08:42:19 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 19 Jul 2015 18:42:19 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: My understanding is that when you have "LHS = RHS", you can replace any instance of LHS with RHS but you can't always do it the other way around, as the LHS might be more specialised (as in this case it is). On 19 July 2015 at 18:08, Clinton Mead wrote: > Thanks for the CC Ivan, forgot to "reply all". > > I guess I want the passed argument to stay polymorphic long enough to be > instanced inside the call. > > Surely if "f x = g x x" then you should somehow be able to replace "g x x" > with "f x"?! That's basically what I'm getting at. > > > > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic > wrote: >> >> (Re-CC'ing Cafe) >> >> I think what's happening here is that when you do "apply f1 f1", the >> two c's and d's don't actually match with each other. >> >> But when you do it with applyBoth, they *have* to match each other. >> >> As a comparison, compare: >> >> :t (read, read) >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) >> >> and >> >> :t Control.Monad.join read >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) >> >> I'm not sure how you could define such a function to do what you're >> requesting; my attempt is this: >> >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> >> D arr a2 b2 >> applyBoth f = apply f f >> >> but whilst ghci accepts it, I couldn't actually seem to use it (lots >> of errors about being unable to match types). >> >> On 19 July 2015 at 17:15, Clinton Mead wrote: >> > Thanks for your reply Ivan >> > >> > Here's a full code example ( http://ideone.com/1K3Yhw ): >> >> > >> > --- >> > >> > data D c a b = D (c a b) (c b a) >> > >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 >> > b2 >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> > >> > applyBoth f = apply f f >> > >> > f :: Int -> String >> > f = show >> > >> > g :: String -> Int >> > g = read >> > >> > h :: Int -> Int >> > h = (*2) >> > >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) >> > join f g (x, y) = (f x, g y) >> > >> > x1 = D f g >> > >> > f1 = join h >> > >> > y1 = apply f1 f1 x1 -- This compiles >> > y2 = apply g g x1 where g = f1 -- Also works >> > >> > z1 = applyBoth f1 x1 -- This fails >> > >> > main = return () >> > >> > --- >> > >> > You see, with "y1" and "y2", a different "f1" instantiation (is that the >> > right word) of "f1" is chosen. Even when I let "g = f1", each "g" passed >> > to >> > apply is different, the first operates on "Int -> String", the second, >> > "String -> Int". >> > >> > On the face of it, if: >> > >> > f x = g x x >> > >> > Then well, you should be able to replace "g x x" with "f x" wherever you >> > see >> > it. >> > >> > But it seems in this case this doesn't work. Surely Haskell doesn't >> > require >> > me to "repeat myself", and there's a way to write "applyBoth", instead >> > of >> > having to write "apply f f" (note the repetition of f) all the time? >> > >> > I assume there's some type signature I can give "applyBoth f" so it can >> > be >> > used just like "apply f f" but I can't work out what it is. >> > >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic >> > wrote: >> >> >> >> >> On 19 July 2015 at 10:13, Clinton Mead wrote: >> >> > Lets say I've got the following data type: >> >> > >> >> > data D c a b = D (c a b) (c b a) >> >> > >> >> > And I define a function to manipulate it: >> >> > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c >> >> > a2 >> >> > b2 >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> >> > >> >> > This is all fine. But I want a shorter function if (f1 = f2). So I >> >> > write: >> >> > >> >> > applyBoth f = apply f f >> >> > >> >> > I originally thought that if "apply f f" is valid, then logically >> >> > "applyBoth >> >> > f" should also be valid. But it seems that type inference results in >> >> > applyBoth only working for functions "c a a -> c a2 a2". >> >> >> >> applyBoth f = apply f f >> >> >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). >> >> >> >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 >> >> (as the above two type signatures must match since f1 = f2). >> >> >> >> So we must have that (f :: c a a -> c a2 a2). >> >> >> >> > >> >> > Is there a way to type "applyBoth" so it works for all functions that >> >> > would >> >> > work simply by repeating them twice in "apply"? >> >> >> >> I'm not sure what you mean; what else would make sense? Can you >> >> provide an example? >> >> >> >> -- >> >> Ivan Lazar Miljenovic >> >> Ivan.Miljenovic at gmail.com >> >> http://IvanMiljenovic.wordpress.com >> > >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From clintonmead at gmail.com Sun Jul 19 08:51:59 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 19 Jul 2015 18:51:59 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: I guess my question is, how to I type LHS so it is no more specialised as RHS in this case? On Sun, Jul 19, 2015 at 6:42 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > My understanding is that when you have "LHS = RHS", you can replace > any instance of LHS with RHS but you can't always do it the other way > around, as the LHS might be more specialised (as in this case it is). > > On 19 July 2015 at 18:08, Clinton Mead wrote: > > Thanks for the CC Ivan, forgot to "reply all". > > > > I guess I want the passed argument to stay polymorphic long enough to be > > instanced inside the call. > > > > Surely if "f x = g x x" then you should somehow be able to replace "g x > x" > > with "f x"?! That's basically what I'm getting at. > > > > > > > > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic > > wrote: > >> > >> (Re-CC'ing Cafe) > >> > >> I think what's happening here is that when you do "apply f1 f1", the > >> two c's and d's don't actually match with each other. > >> > >> But when you do it with applyBoth, they *have* to match each other. > >> > >> As a comparison, compare: > >> > >> :t (read, read) > >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) > >> > >> and > >> > >> :t Control.Monad.join read > >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) > >> > >> I'm not sure how you could define such a function to do what you're > >> requesting; my attempt is this: > >> > >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> > >> D arr a2 b2 > >> applyBoth f = apply f f > >> > >> but whilst ghci accepts it, I couldn't actually seem to use it (lots > >> of errors about being unable to match types). > >> > >> On 19 July 2015 at 17:15, Clinton Mead wrote: > >> > Thanks for your reply Ivan > >> > > >> > Here's a full code example ( http://ideone.com/1K3Yhw ): > >> > >> > > >> > --- > >> > > >> > data D c a b = D (c a b) (c b a) > >> > > >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c a2 > >> > b2 > >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> > > >> > applyBoth f = apply f f > >> > > >> > f :: Int -> String > >> > f = show > >> > > >> > g :: String -> Int > >> > g = read > >> > > >> > h :: Int -> Int > >> > h = (*2) > >> > > >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) > >> > join f g (x, y) = (f x, g y) > >> > > >> > x1 = D f g > >> > > >> > f1 = join h > >> > > >> > y1 = apply f1 f1 x1 -- This compiles > >> > y2 = apply g g x1 where g = f1 -- Also works > >> > > >> > z1 = applyBoth f1 x1 -- This fails > >> > > >> > main = return () > >> > > >> > --- > >> > > >> > You see, with "y1" and "y2", a different "f1" instantiation (is that > the > >> > right word) of "f1" is chosen. Even when I let "g = f1", each "g" > passed > >> > to > >> > apply is different, the first operates on "Int -> String", the second, > >> > "String -> Int". > >> > > >> > On the face of it, if: > >> > > >> > f x = g x x > >> > > >> > Then well, you should be able to replace "g x x" with "f x" wherever > you > >> > see > >> > it. > >> > > >> > But it seems in this case this doesn't work. Surely Haskell doesn't > >> > require > >> > me to "repeat myself", and there's a way to write "applyBoth", instead > >> > of > >> > having to write "apply f f" (note the repetition of f) all the time? > >> > > >> > I assume there's some type signature I can give "applyBoth f" so it > can > >> > be > >> > used just like "apply f f" but I can't work out what it is. > >> > > >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic > >> > wrote: > >> > >> >> > >> >> On 19 July 2015 at 10:13, Clinton Mead > wrote: > >> >> > Lets say I've got the following data type: > >> >> > > >> >> > data D c a b = D (c a b) (c b a) > >> >> > > >> >> > And I define a function to manipulate it: > >> >> > > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c > >> >> > a2 > >> >> > b2 > >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> >> > > >> >> > This is all fine. But I want a shorter function if (f1 = f2). So I > >> >> > write: > >> >> > > >> >> > applyBoth f = apply f f > >> >> > > >> >> > I originally thought that if "apply f f" is valid, then logically > >> >> > "applyBoth > >> >> > f" should also be valid. But it seems that type inference results > in > >> >> > applyBoth only working for functions "c a a -> c a2 a2". > >> >> > >> >> applyBoth f = apply f f > >> >> > >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). > >> >> > >> >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 > >> >> (as the above two type signatures must match since f1 = f2). > >> >> > >> >> So we must have that (f :: c a a -> c a2 a2). > >> >> > >> >> > > >> >> > Is there a way to type "applyBoth" so it works for all functions > that > >> >> > would > >> >> > work simply by repeating them twice in "apply"? > >> >> > >> >> I'm not sure what you mean; what else would make sense? Can you > >> >> provide an example? > >> >> > >> >> -- > >> >> Ivan Lazar Miljenovic > >> >> Ivan.Miljenovic at gmail.com > >> >> http://IvanMiljenovic.wordpress.com > >> > > >> > > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Sun Jul 19 08:52:58 2015 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 19 Jul 2015 18:52:58 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: <55AB656A.2060806@gmail.com> FYI f x = g x x can be written: f = join g On 19/07/15 18:51, Clinton Mead wrote: > I guess my question is, how to I type LHS so it is no more specialised > as RHS in this case? > > On Sun, Jul 19, 2015 at 6:42 PM, Ivan Lazar Miljenovic > > wrote: > > My understanding is that when you have "LHS = RHS", you can replace > any instance of LHS with RHS but you can't always do it the other way > around, as the LHS might be more specialised (as in this case it is). > > On 19 July 2015 at 18:08, Clinton Mead > wrote: > > Thanks for the CC Ivan, forgot to "reply all". > > > > I guess I want the passed argument to stay polymorphic long enough to be > > instanced inside the call. > > > > Surely if "f x = g x x" then you should somehow be able to replace "g x x" > > with "f x"?! That's basically what I'm getting at. > > > > > > > > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic > > > wrote: > >> > >> (Re-CC'ing Cafe) > >> > >> I think what's happening here is that when you do "apply f1 f1", the > >> two c's and d's don't actually match with each other. > >> > >> But when you do it with applyBoth, they *have* to match each other. > >> > >> As a comparison, compare: > >> > >> :t (read, read) > >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) > >> > >> and > >> > >> :t Control.Monad.join read > >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) > >> > >> I'm not sure how you could define such a function to do what you're > >> requesting; my attempt is this: > >> > >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> > >> D arr a2 b2 > >> applyBoth f = apply f f > >> > >> but whilst ghci accepts it, I couldn't actually seem to use it (lots > >> of errors about being unable to match types). > >> > >> On 19 July 2015 at 17:15, Clinton Mead > wrote: > >> > Thanks for your reply Ivan > >> > > >> > Here's a full code example ( http://ideone.com/1K3Yhw ): > >> > >> > > >> > --- > >> > > >> > data D c a b = D (c a b) (c b a) > >> > > >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> > D c a2 > >> > b2 > >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> > > >> > applyBoth f = apply f f > >> > > >> > f :: Int -> String > >> > f = show > >> > > >> > g :: String -> Int > >> > g = read > >> > > >> > h :: Int -> Int > >> > h = (*2) > >> > > >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) > >> > join f g (x, y) = (f x, g y) > >> > > >> > x1 = D f g > >> > > >> > f1 = join h > >> > > >> > y1 = apply f1 f1 x1 -- This compiles > >> > y2 = apply g g x1 where g = f1 -- Also works > >> > > >> > z1 = applyBoth f1 x1 -- This fails > >> > > >> > main = return () > >> > > >> > --- > >> > > >> > You see, with "y1" and "y2", a different "f1" instantiation (is > that the > >> > right word) of "f1" is chosen. Even when I let "g = f1", each > "g" passed > >> > to > >> > apply is different, the first operates on "Int -> String", the > second, > >> > "String -> Int". > >> > > >> > On the face of it, if: > >> > > >> > f x = g x x > >> > > >> > Then well, you should be able to replace "g x x" with "f x" > wherever you > >> > see > >> > it. > >> > > >> > But it seems in this case this doesn't work. Surely Haskell doesn't > >> > require > >> > me to "repeat myself", and there's a way to write "applyBoth", > instead > >> > of > >> > having to write "apply f f" (note the repetition of f) all the > time? > >> > > >> > I assume there's some type signature I can give "applyBoth f" > so it can > >> > be > >> > used just like "apply f f" but I can't work out what it is. > >> > > >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic > >> > > > wrote: > >> > >> >> > >> >> On 19 July 2015 at 10:13, Clinton Mead > wrote: > >> >> > Lets say I've got the following data type: > >> >> > > >> >> > data D c a b = D (c a b) (c b a) > >> >> > > >> >> > And I define a function to manipulate it: > >> >> > > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b > -> D c > >> >> > a2 > >> >> > b2 > >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> >> > > >> >> > This is all fine. But I want a shorter function if (f1 = > f2). So I > >> >> > write: > >> >> > > >> >> > applyBoth f = apply f f > >> >> > > >> >> > I originally thought that if "apply f f" is valid, then > logically > >> >> > "applyBoth > >> >> > f" should also be valid. But it seems that type inference > results in > >> >> > applyBoth only working for functions "c a a -> c a2 a2". > >> >> > >> >> applyBoth f = apply f f > >> >> > >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). > >> >> > >> >> So for "apply f f" to typecheck, we must have that a ~ b and > a2 ~ b2 > >> >> (as the above two type signatures must match since f1 = f2). > >> >> > >> >> So we must have that (f :: c a a -> c a2 a2). > >> >> > >> >> > > >> >> > Is there a way to type "applyBoth" so it works for all > functions that > >> >> > would > >> >> > work simply by repeating them twice in "apply"? > >> >> > >> >> I'm not sure what you mean; what else would make sense? Can you > >> >> provide an example? > >> >> > >> >> -- > >> >> Ivan Lazar Miljenovic > >> >> Ivan.Miljenovic at gmail.com > >> >> http://IvanMiljenovic.wordpress.com > >> > > >> > > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From ivan.miljenovic at gmail.com Sun Jul 19 09:02:34 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 19 Jul 2015 19:02:34 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: <55AB656A.2060806@gmail.com> References: <55AB656A.2060806@gmail.com> Message-ID: On 19 July 2015 at 18:52, Tony Morris wrote: > FYI > > f x = g x x > > can be written: > > f = join g In this case it can't be, as Clinton has defined a new join function. > > > On 19/07/15 18:51, Clinton Mead wrote: >> I guess my question is, how to I type LHS so it is no more specialised >> as RHS in this case? >> >> On Sun, Jul 19, 2015 at 6:42 PM, Ivan Lazar Miljenovic >> > wrote: >> >> My understanding is that when you have "LHS = RHS", you can replace >> any instance of LHS with RHS but you can't always do it the other way >> around, as the LHS might be more specialised (as in this case it is). >> >> On 19 July 2015 at 18:08, Clinton Mead > > wrote: >> > Thanks for the CC Ivan, forgot to "reply all". >> > >> > I guess I want the passed argument to stay polymorphic long enough to be >> > instanced inside the call. >> > >> > Surely if "f x = g x x" then you should somehow be able to replace "g x x" >> > with "f x"?! That's basically what I'm getting at. >> > >> > >> > >> > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic >> > > wrote: >> >> >> >> (Re-CC'ing Cafe) >> >> >> >> I think what's happening here is that when you do "apply f1 f1", the >> >> two c's and d's don't actually match with each other. >> >> >> >> But when you do it with applyBoth, they *have* to match each other. >> >> >> >> As a comparison, compare: >> >> >> >> :t (read, read) >> >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) >> >> >> >> and >> >> >> >> :t Control.Monad.join read >> >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) >> >> >> >> I'm not sure how you could define such a function to do what you're >> >> requesting; my attempt is this: >> >> >> >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> >> >> D arr a2 b2 >> >> applyBoth f = apply f f >> >> >> >> but whilst ghci accepts it, I couldn't actually seem to use it (lots >> >> of errors about being unable to match types). >> >> >> >> On 19 July 2015 at 17:15, Clinton Mead > wrote: >> >> > Thanks for your reply Ivan >> >> > >> >> > Here's a full code example ( http://ideone.com/1K3Yhw ): >> >> >> >> > >> >> > --- >> >> > >> >> > data D c a b = D (c a b) (c b a) >> >> > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> >> D c a2 >> >> > b2 >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> >> > >> >> > applyBoth f = apply f f >> >> > >> >> > f :: Int -> String >> >> > f = show >> >> > >> >> > g :: String -> Int >> >> > g = read >> >> > >> >> > h :: Int -> Int >> >> > h = (*2) >> >> > >> >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) >> >> > join f g (x, y) = (f x, g y) >> >> > >> >> > x1 = D f g >> >> > >> >> > f1 = join h >> >> > >> >> > y1 = apply f1 f1 x1 -- This compiles >> >> > y2 = apply g g x1 where g = f1 -- Also works >> >> > >> >> > z1 = applyBoth f1 x1 -- This fails >> >> > >> >> > main = return () >> >> > >> >> > --- >> >> > >> >> > You see, with "y1" and "y2", a different "f1" instantiation (is >> that the >> >> > right word) of "f1" is chosen. Even when I let "g = f1", each >> "g" passed >> >> > to >> >> > apply is different, the first operates on "Int -> String", the >> second, >> >> > "String -> Int". >> >> > >> >> > On the face of it, if: >> >> > >> >> > f x = g x x >> >> > >> >> > Then well, you should be able to replace "g x x" with "f x" >> wherever you >> >> > see >> >> > it. >> >> > >> >> > But it seems in this case this doesn't work. Surely Haskell doesn't >> >> > require >> >> > me to "repeat myself", and there's a way to write "applyBoth", >> instead >> >> > of >> >> > having to write "apply f f" (note the repetition of f) all the >> time? >> >> > >> >> > I assume there's some type signature I can give "applyBoth f" >> so it can >> >> > be >> >> > used just like "apply f f" but I can't work out what it is. >> >> > >> >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic >> >> > > >> wrote: >> >> >> >> >> >> >> >> On 19 July 2015 at 10:13, Clinton Mead > > wrote: >> >> >> > Lets say I've got the following data type: >> >> >> > >> >> >> > data D c a b = D (c a b) (c b a) >> >> >> > >> >> >> > And I define a function to manipulate it: >> >> >> > >> >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b >> -> D c >> >> >> > a2 >> >> >> > b2 >> >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> >> >> > >> >> >> > This is all fine. But I want a shorter function if (f1 = >> f2). So I >> >> >> > write: >> >> >> > >> >> >> > applyBoth f = apply f f >> >> >> > >> >> >> > I originally thought that if "apply f f" is valid, then >> logically >> >> >> > "applyBoth >> >> >> > f" should also be valid. But it seems that type inference >> results in >> >> >> > applyBoth only working for functions "c a a -> c a2 a2". >> >> >> >> >> >> applyBoth f = apply f f >> >> >> >> >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). >> >> >> >> >> >> So for "apply f f" to typecheck, we must have that a ~ b and >> a2 ~ b2 >> >> >> (as the above two type signatures must match since f1 = f2). >> >> >> >> >> >> So we must have that (f :: c a a -> c a2 a2). >> >> >> >> >> >> > >> >> >> > Is there a way to type "applyBoth" so it works for all >> functions that >> >> >> > would >> >> >> > work simply by repeating them twice in "apply"? >> >> >> >> >> >> I'm not sure what you mean; what else would make sense? Can you >> >> >> provide an example? >> >> >> >> >> >> -- >> >> >> Ivan Lazar Miljenovic >> >> >> Ivan.Miljenovic at gmail.com >> >> >> http://IvanMiljenovic.wordpress.com >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Ivan Lazar Miljenovic >> >> Ivan.Miljenovic at gmail.com >> >> http://IvanMiljenovic.wordpress.com >> > >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ivan.miljenovic at gmail.com Sun Jul 19 09:03:07 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 19 Jul 2015 19:03:07 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: On 19 July 2015 at 18:51, Clinton Mead wrote: > I guess my question is, how to I type LHS so it is no more specialised as > RHS in this case? I don't believe you can. > > On Sun, Jul 19, 2015 at 6:42 PM, Ivan Lazar Miljenovic > wrote: >> >> My understanding is that when you have "LHS = RHS", you can replace >> any instance of LHS with RHS but you can't always do it the other way >> around, as the LHS might be more specialised (as in this case it is). >> >> On 19 July 2015 at 18:08, Clinton Mead wrote: >> > Thanks for the CC Ivan, forgot to "reply all". >> > >> > I guess I want the passed argument to stay polymorphic long enough to be >> > instanced inside the call. >> > >> > Surely if "f x = g x x" then you should somehow be able to replace "g x >> > x" >> > with "f x"?! That's basically what I'm getting at. >> > >> > >> > >> > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic >> > wrote: >> >> >> >> (Re-CC'ing Cafe) >> >> >> >> I think what's happening here is that when you do "apply f1 f1", the >> >> two c's and d's don't actually match with each other. >> >> >> >> But when you do it with applyBoth, they *have* to match each other. >> >> >> >> As a comparison, compare: >> >> >> >> :t (read, read) >> >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) >> >> >> >> and >> >> >> >> :t Control.Monad.join read >> >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) >> >> >> >> I'm not sure how you could define such a function to do what you're >> >> requesting; my attempt is this: >> >> >> >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> >> >> D arr a2 b2 >> >> applyBoth f = apply f f >> >> >> >> but whilst ghci accepts it, I couldn't actually seem to use it (lots >> >> of errors about being unable to match types). >> >> >> >> On 19 July 2015 at 17:15, Clinton Mead wrote: >> >> > Thanks for your reply Ivan >> >> > >> >> > Here's a full code example ( http://ideone.com/1K3Yhw ): >> >> >> >> >> > >> >> > --- >> >> > >> >> > data D c a b = D (c a b) (c b a) >> >> > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c >> >> > a2 >> >> > b2 >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> >> > >> >> > applyBoth f = apply f f >> >> > >> >> > f :: Int -> String >> >> > f = show >> >> > >> >> > g :: String -> Int >> >> > g = read >> >> > >> >> > h :: Int -> Int >> >> > h = (*2) >> >> > >> >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) >> >> > join f g (x, y) = (f x, g y) >> >> > >> >> > x1 = D f g >> >> > >> >> > f1 = join h >> >> > >> >> > y1 = apply f1 f1 x1 -- This compiles >> >> > y2 = apply g g x1 where g = f1 -- Also works >> >> > >> >> > z1 = applyBoth f1 x1 -- This fails >> >> > >> >> > main = return () >> >> > >> >> > --- >> >> > >> >> > You see, with "y1" and "y2", a different "f1" instantiation (is that >> >> > the >> >> > right word) of "f1" is chosen. Even when I let "g = f1", each "g" >> >> > passed >> >> > to >> >> > apply is different, the first operates on "Int -> String", the >> >> > second, >> >> > "String -> Int". >> >> > >> >> > On the face of it, if: >> >> > >> >> > f x = g x x >> >> > >> >> > Then well, you should be able to replace "g x x" with "f x" wherever >> >> > you >> >> > see >> >> > it. >> >> > >> >> > But it seems in this case this doesn't work. Surely Haskell doesn't >> >> > require >> >> > me to "repeat myself", and there's a way to write "applyBoth", >> >> > instead >> >> > of >> >> > having to write "apply f f" (note the repetition of f) all the time? >> >> > >> >> > I assume there's some type signature I can give "applyBoth f" so it >> >> > can >> >> > be >> >> > used just like "apply f f" but I can't work out what it is. >> >> > >> >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic >> >> > wrote: >> >> >> >> >> >> >> >> >> On 19 July 2015 at 10:13, Clinton Mead >> >> >> wrote: >> >> >> > Lets say I've got the following data type: >> >> >> > >> >> >> > data D c a b = D (c a b) (c b a) >> >> >> > >> >> >> > And I define a function to manipulate it: >> >> >> > >> >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D >> >> >> > c >> >> >> > a2 >> >> >> > b2 >> >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) >> >> >> > >> >> >> > This is all fine. But I want a shorter function if (f1 = f2). So I >> >> >> > write: >> >> >> > >> >> >> > applyBoth f = apply f f >> >> >> > >> >> >> > I originally thought that if "apply f f" is valid, then logically >> >> >> > "applyBoth >> >> >> > f" should also be valid. But it seems that type inference results >> >> >> > in >> >> >> > applyBoth only working for functions "c a a -> c a2 a2". >> >> >> >> >> >> applyBoth f = apply f f >> >> >> >> >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). >> >> >> >> >> >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ b2 >> >> >> (as the above two type signatures must match since f1 = f2). >> >> >> >> >> >> So we must have that (f :: c a a -> c a2 a2). >> >> >> >> >> >> > >> >> >> > Is there a way to type "applyBoth" so it works for all functions >> >> >> > that >> >> >> > would >> >> >> > work simply by repeating them twice in "apply"? >> >> >> >> >> >> I'm not sure what you mean; what else would make sense? Can you >> >> >> provide an example? >> >> >> >> >> >> -- >> >> >> Ivan Lazar Miljenovic >> >> >> Ivan.Miljenovic at gmail.com >> >> >> http://IvanMiljenovic.wordpress.com >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Ivan Lazar Miljenovic >> >> Ivan.Miljenovic at gmail.com >> >> http://IvanMiljenovic.wordpress.com >> > >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From clintonmead at gmail.com Sun Jul 19 09:07:01 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 19 Jul 2015 19:07:01 +1000 Subject: [Haskell-cafe] Type signature for function where function parameter is used twice? In-Reply-To: References: Message-ID: Avoiding the name class for the moment by qualifying, it seems: applyBoth = Control.Monad.join apply has the same issue On Sun, Jul 19, 2015 at 7:03 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 19 July 2015 at 18:51, Clinton Mead wrote: > > I guess my question is, how to I type LHS so it is no more specialised as > > RHS in this case? > > I don't believe you can. > > > > > On Sun, Jul 19, 2015 at 6:42 PM, Ivan Lazar Miljenovic > > wrote: > >> > >> My understanding is that when you have "LHS = RHS", you can replace > >> any instance of LHS with RHS but you can't always do it the other way > >> around, as the LHS might be more specialised (as in this case it is). > >> > >> On 19 July 2015 at 18:08, Clinton Mead wrote: > >> > Thanks for the CC Ivan, forgot to "reply all". > >> > > >> > I guess I want the passed argument to stay polymorphic long enough to > be > >> > instanced inside the call. > >> > > >> > Surely if "f x = g x x" then you should somehow be able to replace "g > x > >> > x" > >> > with "f x"?! That's basically what I'm getting at. > >> > > >> > > >> > > >> > On Sun, Jul 19, 2015 at 5:54 PM, Ivan Lazar Miljenovic > >> > wrote: > >> >> > >> >> (Re-CC'ing Cafe) > >> >> > >> >> I think what's happening here is that when you do "apply f1 f1", the > >> >> two c's and d's don't actually match with each other. > >> >> > >> >> But when you do it with applyBoth, they *have* to match each other. > >> >> > >> >> As a comparison, compare: > >> >> > >> >> :t (read, read) > >> >> (read, read) :: (Read a, Read a1) => (String -> a, String -> a1) > >> >> > >> >> and > >> >> > >> >> :t Control.Monad.join read > >> >> Control.Monad.join (,) read :: Read a => (String -> a, String -> a) > >> >> > >> >> I'm not sure how you could define such a function to do what you're > >> >> requesting; my attempt is this: > >> >> > >> >> applyBoth :: (forall a b a2 b2. arr a b -> arr a2 b2) -> D arr a b -> > >> >> D arr a2 b2 > >> >> applyBoth f = apply f f > >> >> > >> >> but whilst ghci accepts it, I couldn't actually seem to use it (lots > >> >> of errors about being unable to match types). > >> >> > >> >> On 19 July 2015 at 17:15, Clinton Mead > wrote: > >> >> > Thanks for your reply Ivan > >> >> > > >> >> > Here's a full code example ( http://ideone.com/1K3Yhw ): > >> > >> >> > >> >> > > >> >> > --- > >> >> > > >> >> > data D c a b = D (c a b) (c b a) > >> >> > > >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> D c > >> >> > a2 > >> >> > b2 > >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> >> > > >> >> > applyBoth f = apply f f > >> >> > > >> >> > f :: Int -> String > >> >> > f = show > >> >> > > >> >> > g :: String -> Int > >> >> > g = read > >> >> > > >> >> > h :: Int -> Int > >> >> > h = (*2) > >> >> > > >> >> > join :: (a -> b) -> (c -> d) -> ((a, c) -> (b, d)) > >> >> > join f g (x, y) = (f x, g y) > >> >> > > >> >> > x1 = D f g > >> >> > > >> >> > f1 = join h > >> >> > > >> >> > y1 = apply f1 f1 x1 -- This compiles > >> >> > y2 = apply g g x1 where g = f1 -- Also works > >> >> > > >> >> > z1 = applyBoth f1 x1 -- This fails > >> >> > > >> >> > main = return () > >> >> > > >> >> > --- > >> >> > > >> >> > You see, with "y1" and "y2", a different "f1" instantiation (is > that > >> >> > the > >> >> > right word) of "f1" is chosen. Even when I let "g = f1", each "g" > >> >> > passed > >> >> > to > >> >> > apply is different, the first operates on "Int -> String", the > >> >> > second, > >> >> > "String -> Int". > >> >> > > >> >> > On the face of it, if: > >> >> > > >> >> > f x = g x x > >> >> > > >> >> > Then well, you should be able to replace "g x x" with "f x" > wherever > >> >> > you > >> >> > see > >> >> > it. > >> >> > > >> >> > But it seems in this case this doesn't work. Surely Haskell doesn't > >> >> > require > >> >> > me to "repeat myself", and there's a way to write "applyBoth", > >> >> > instead > >> >> > of > >> >> > having to write "apply f f" (note the repetition of f) all the > time? > >> >> > > >> >> > I assume there's some type signature I can give "applyBoth f" so it > >> >> > can > >> >> > be > >> >> > used just like "apply f f" but I can't work out what it is. > >> >> > > >> >> > On Sun, Jul 19, 2015 at 10:23 AM, Ivan Lazar Miljenovic > >> >> > wrote: > >> > >> >> > >> >> >> > >> >> >> On 19 July 2015 at 10:13, Clinton Mead > >> >> >> wrote: > >> >> >> > Lets say I've got the following data type: > >> >> >> > > >> >> >> > data D c a b = D (c a b) (c b a) > >> >> >> > > >> >> >> > And I define a function to manipulate it: > >> >> >> > > >> >> >> > apply :: (c a b -> c a2 b2) -> (c b a -> c b2 a2) -> D c a b -> > D > >> >> >> > c > >> >> >> > a2 > >> >> >> > b2 > >> >> >> > apply f1 f2 (D x y) = D (f1 x) (f2 y) > >> >> >> > > >> >> >> > This is all fine. But I want a shorter function if (f1 = f2). > So I > >> >> >> > write: > >> >> >> > > >> >> >> > applyBoth f = apply f f > >> >> >> > > >> >> >> > I originally thought that if "apply f f" is valid, then > logically > >> >> >> > "applyBoth > >> >> >> > f" should also be valid. But it seems that type inference > results > >> >> >> > in > >> >> >> > applyBoth only working for functions "c a a -> c a2 a2". > >> >> >> > >> >> >> applyBoth f = apply f f > >> >> >> > >> >> >> In apply, (f1 :: c a b -> c a2 b2) and (f2 :: c b a -> c b2 a2). > >> >> >> > >> >> >> So for "apply f f" to typecheck, we must have that a ~ b and a2 ~ > b2 > >> >> >> (as the above two type signatures must match since f1 = f2). > >> >> >> > >> >> >> So we must have that (f :: c a a -> c a2 a2). > >> >> >> > >> >> >> > > >> >> >> > Is there a way to type "applyBoth" so it works for all functions > >> >> >> > that > >> >> >> > would > >> >> >> > work simply by repeating them twice in "apply"? > >> >> >> > >> >> >> I'm not sure what you mean; what else would make sense? Can you > >> >> >> provide an example? > >> >> >> > >> >> >> -- > >> >> >> Ivan Lazar Miljenovic > >> >> >> Ivan.Miljenovic at gmail.com > >> >> >> http://IvanMiljenovic.wordpress.com > >> >> > > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Ivan Lazar Miljenovic > >> >> Ivan.Miljenovic at gmail.com > >> >> http://IvanMiljenovic.wordpress.com > >> > > >> > > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Jul 19 21:29:51 2015 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 19 Jul 2015 23:29:51 +0200 Subject: [Haskell-cafe] The evil GADTs extension in ghci 7.8.4 (maybe in other versions too?) References: <1433475098-sup-1820@sabre> <1433475711-sup-8101@sabre> <55788BC6.2080004@ro-che.info> Message-ID: wren romano wrote: > On Wed, Jun 10, 2015 at 3:21 PM, Nathan Bouscal > wrote: >>> The current behavior may be surprising if you are not aware of it, but >>> it's the only sensible one. Otherwise, what should the meaning of >>> >>> {-# LANGUAGE MonoLocalBinds, NoMonoLocalBinds #-} >>> >>> be? >> >> Arguably it should be a compiler warning. > > +1. > > I'd say, when a set of flags are mutually incompatible (e.g., {Foo, > NoFoo}) then that should be a warning/error. Whereas with GADTs, we > *recommend* (and by default assume) MonoLocalBinds, but GADTs are not > *incompatible* with NoMonoLocalBinds. We already support defeasible > recommendations (in practice, if not intentionally); why not remove > the counterintuitive corner cases they create in the current > implementation? > > As for the complaint about project-wide vs file-specific language > extensions: yes, it can be helpful to have overriding behavior; but > having that behavior at the commandline or within a single file is > counterintuitive at best. What I think would make more sense is a > set-valued variant of the Last monad where each local collection of > constraints (the collection given on the commandline, the collection > given in the cabal file, the collection given in the Haskell file > itself, etc) must be internally consistent, generating an > error/warning if it is not. And then we simply have the more > fine-grained constraint sets override the coarser-grained constraint > sets. This is exactly the conclusion I arrived at when re-designing the option handling in Darcs. There we have even more (four) sources for options; in decreasing order of precedence: hard-coded defaults, global (per user) defaults, local (per repo) defaults, command line. Each level is required to be consistent in itself, later levels override earlier ones. Experience with this scheme has been good so far. Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams From ben.franksen at online.de Sun Jul 19 22:17:35 2015 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 20 Jul 2015 00:17:35 +0200 Subject: [Haskell-cafe] Add IsNumeric (similar to IsString and IsList) References: Message-ID: Ivan Lazar Miljenovic wrote: > On 15 June 2015 at 18:05, Chris Wong wrote: >> On Fri, Jun 12, 2015 at 7:04 PM, Michael Baikov >> wrote: >>> Now that we have OverloadedList and OverloadedStrings extensions it >>> might make sense to add something similar for numerals - right now if >>> you want to be able to specify some items as numbers >>> you have to implement Num instance, unfortunately not everything that >>> can be represented as number can have sensible operations required by >>> Num: negation makes no sense for set of natural numbers for example, >>> multiplication for some applications of currency values which results >>> in Num instance full of (*) = error "No multipication for Foos", (+) = >>> error "No addition for Foos". >>> >>> I don't have any statistics from hackage or github, but in codebase >>> I'm working with there are 3 such instances. >>> >>> Proposal: add OverloadedNumerals language pragma, IsNumeric typeclass >>> and some methods to make that class useful with behavior similar to >>> Lists and Strings. >> >> As for naming: it should be named IsInteger/fromInteger by analogy >> with IsString/fromString and IsList/fromList. > > The problem with calling it "fromInteger" is that it would clobber the > existing fromInteger method in the Num class (thus hiding > tricks/qualification would be needed when defining/using instances) > unless it is split out of Num, but that will probably be more of an > uphill battle. Can anyone explain to me why IsString was named so and not FromString? I wonder about that every time I encounter this class. Would it not make more sense to break with this rather unfortunate naming convention? Cheers Ben -- "Make it so they have to reboot after every typo." ? Scott Adams From kc1956 at gmail.com Mon Jul 20 02:03:27 2015 From: kc1956 at gmail.com (KC) Date: Sun, 19 Jul 2015 19:03:27 -0700 Subject: [Haskell-cafe] Where else is EclipseFP available since SourceForge seems to be partially down? Message-ID: Where else is EclipseFP available since SourceForge seems to be partially down? -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jul 20 02:20:11 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 19 Jul 2015 22:20:11 -0400 Subject: [Haskell-cafe] Where else is EclipseFP available since SourceForge seems to be partially down? In-Reply-To: References: Message-ID: On Sun, Jul 19, 2015 at 10:03 PM, KC wrote: > Where else is EclipseFP available since SourceForge seems to be partially > down? I was under the impression that EclipseFP was no longer supported, so possibly nowhere. -- 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 voldermort at hotmail.com Mon Jul 20 07:28:03 2015 From: voldermort at hotmail.com (Jeremy) Date: Mon, 20 Jul 2015 00:28:03 -0700 (MST) Subject: [Haskell-cafe] Where is Haskell Weekly News syndicated? In-Reply-To: References: <1426087518070-5766854.post@n5.nabble.com> <1426408319367-5767017.post@n5.nabble.com> <20150315145524.GA73677@inanna.trygub.com> <1434614959662-5811671.post@n5.nabble.com> <1434629971980-5811691.post@n5.nabble.com> Message-ID: <1437377283118-5813708.post@n5.nabble.com> Last edition was over a month ago. Has there been a hiatus? -- View this message in context: http://haskell.1045720.n5.nabble.com/Where-is-Haskell-Weekly-News-syndicated-tp5766854p5813708.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From mail at nh2.me Mon Jul 20 13:07:13 2015 From: mail at nh2.me (=?UTF-8?B?TmlrbGFzIEhhbWLDvGNoZW4=?=) Date: Mon, 20 Jul 2015 15:07:13 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem Message-ID: <55ACF281.6020707@nh2.me> Hello Cafe, I would like to point out a problem common to all programming languages, and that Haskell hasn't addressed yet while other languages have. It is about what happens to file descriptors when the `exec()` syscall is used (whenever you `readProcess`, `createProcess`, `system`, use any form of `popen()`, Shake's `cmd` etc.). (A Markdown-rendered version containing most of this email can be found at https://github.com/ndmitchell/shake/issues/253.) Take the following function f :: IO () f = do inSomeTemporaryDirectory $ do BS.writeFile "mybinary" binaryContents setPermissions "mybinary" (setOwnerExecutable True emptyPermissions) _ <- readProcess "./mybinary" [] "" return () If this is happening in parallel, e.g. using, forkIO f >> forkIO f >> forkIO f >> threadDelay 5000000` then on Linux the `readProcess` might often fail wit the error message mybinary: Text file busy This error means "Cannot execute the program 'mybinary' because it is open for writing by some process". How can this happen, given that we're writing all `mybinary` files in completely separate temporary directories, and given that `BS.writeFile` guarantees to close the file handle / file descriptor (`Fd`) before it returns? The answer is that by default, child processes on Unix (`fork()+exec()`) inherit all open file descriptors of the parent process. An ordering that leads to the problematic case could be: * Thread 1 writes its file completely (opens and closes an Fd 1) * Thread 2 starts writing its file (Fd 2 open for writing) * Thread 1 executes "myBinary" (which calls `fork()` and `exec()`). Fd 2 is inherited by the child process * Thread 2 finishes writing (closes its Fd 2) * Thread 2 executes "myBinary", which fails with `Text file busy` because an Fd is still open to it in the child of Process 1 The scope of this program is quite general unfortunately: It will happen for any program that uses parallel threads, and that runs two or more external processes at some time. It cannot be fixed by the part that starts the external process (e.g. you can't write a reliable `readProcess` function that doesn't have this problem, since the problem is rooted in the Fds, and there is no version of `exec()` that doesn't inherit parent Fds). This problem is a general problem in C on Unix, and was discovered quite late. Naive solutions to this use `fcntl`, e.g. `fcntl(fd, F_SETFD, FD_CLOEXEC)`: http://stackoverflow.com/questions/6125068/what-does-the-fd-cloexec-fcntl-flag-do which is the equivalent of Haskell's `setFdOption` to set the `CLOEXEC` flag to all Fds before `exec()`ing. Fds with this flag are not inherited by `exec()`ed child processes. However, these solutions are racy in multi-threaded programs (such as typical Haskell programs), where an `exec()` made by some thread can fall just in between the `int fd = open(...); exec(...)` of some other thread. For this reason, the `O_CLOEXEC` flag was added in Linux 2.6.23, see e.g. `man 2 open` http://man7.org/linux/man-pages/man2/open.2.html to the `open()` syscall to atomically open a file and set the Fd to CLOEXEC in a single step. This flag is not the default in Haskell - but maybe it should be. Other languages set it by default, for example Python. See PEP-433: https://www.python.org/dev/peps/pep-0433/ and the newer PEP-446: https://www.python.org/dev/peps/pep-0446/ for a very good description of the situation. Python >= 3.2 closes open Fds *after* the `exec()` when performed with its `subprocess` module. Python 3.4 uses O_CLOEXEC by default on all Fds opened by Python. It is also noted that "The programming languages Go, Perl and Ruby make newly created file descriptors non-inheritable by default: since Go 1.0 (2009), Perl 1.0 (1987) and Ruby 2.0 (2013)": https://www.python.org/dev/peps/pep-0446/#related-work A work-around for Haskell is to use `O_CLOEXEC` explicitly, as in this example module `System/Posix/IO/ExecSafe.hsc`: https://gist.github.com/nh2/4932ecf5ca919659ae51 Then we can implement a safe version of `BS.writeFile`: https://gist.github.com/nh2/4932ecf5ca919659ae51 Using this form of `writeFileExecSafe` helps in cases when your program is very small, when you can change all the code and you don't use any libraries that open files. However, this is a very rare case, and not a real solution. All multi-threaded Haskell programs that write and execute files will inherently trigger the `Text file busy` problem. We need to discuss what to do about this. Let us run this discussion on haskell-cafe and move to the libraries@ mailing list once we've got some ideas and opinions. My personal stance is that we should follow Python's example, and all functions in our standard libraries should open files with the O_CLOEXEC flag set. Niklas From hesselink at gmail.com Mon Jul 20 13:31:40 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 20 Jul 2015 15:31:40 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55ACF281.6020707@nh2.me> References: <55ACF281.6020707@nh2.me> Message-ID: I've run into this, but with sockets instead of files. For example, if you run a kind of launcher that spawns processes with a double fork, and it listens on its own socket, restarting it will fail to rebind the socket, since the spawned processes inherited it. We set FD_CLOEXEC on the socket now, but, at least on Linux, you could pass SOCK_CLOEXEC to 'socket' in a similar way as with 'open'. Mac support is trickier: it does seem to support the flag on 'open', but not on 'socket', as far as I can tell. I have no idea if this discussion applies to Windows at all. Personally I agree with you that we should probably set this by default, and expose a flag to change it. Erik On Mon, Jul 20, 2015 at 3:07 PM, Niklas Hamb?chen wrote: > Hello Cafe, > > I would like to point out a problem common to all programming languages, > and that Haskell hasn't addressed yet while other languages have. > > It is about what happens to file descriptors when the `exec()` syscall > is used (whenever you `readProcess`, `createProcess`, `system`, use any > form of `popen()`, Shake's `cmd` etc.). > > (A Markdown-rendered version containing most of this email can be found > at https://github.com/ndmitchell/shake/issues/253.) > > Take the following function > > f :: IO () > f = do > inSomeTemporaryDirectory $ do > BS.writeFile "mybinary" binaryContents > setPermissions "mybinary" (setOwnerExecutable True emptyPermissions) > _ <- readProcess "./mybinary" [] "" > return () > > If this is happening in parallel, e.g. using, > > forkIO f >> forkIO f >> forkIO f >> threadDelay 5000000` > > then on Linux the `readProcess` might often fail wit the error message > > mybinary: Text file busy > > This error means "Cannot execute the program 'mybinary' because it is > open for writing by some process". > > How can this happen, given that we're writing all `mybinary` files in > completely separate temporary directories, and given that `BS.writeFile` > guarantees to close the file handle / file descriptor (`Fd`) before it > returns? > > The answer is that by default, child processes on Unix (`fork()+exec()`) > inherit all open file descriptors of the parent process. An ordering > that leads to the problematic case could be: > > * Thread 1 writes its file completely (opens and closes an Fd 1) > * Thread 2 starts writing its file (Fd 2 open for writing) > * Thread 1 executes "myBinary" (which calls `fork()` and `exec()`). Fd 2 > is inherited by the child process > * Thread 2 finishes writing (closes its Fd 2) > * Thread 2 executes "myBinary", which fails with `Text file busy` > because an Fd is still open to it in the child of Process 1 > > The scope of this program is quite general unfortunately: It will happen > for any program that uses parallel threads, and that runs two or more > external processes at some time. It cannot be fixed by the part that > starts the external process (e.g. you can't write a reliable > `readProcess` function that doesn't have this problem, since the problem > is rooted in the Fds, and there is no version of `exec()` that doesn't > inherit parent Fds). > > This problem is a general problem in C on Unix, and was discovered quite > late. > > Naive solutions to this use `fcntl`, e.g. `fcntl(fd, F_SETFD, FD_CLOEXEC)`: > > > http://stackoverflow.com/questions/6125068/what-does-the-fd-cloexec-fcntl-flag-do > > which is the equivalent of Haskell's `setFdOption` to set the `CLOEXEC` > flag to all Fds before `exec()`ing. Fds with this flag are not inherited > by `exec()`ed child processes. However, these solutions are racy in > multi-threaded programs (such as typical Haskell programs), where an > `exec()` made by some thread can fall just in between the `int fd = > open(...); exec(...)` of some other thread. > > For this reason, the `O_CLOEXEC` flag was added in Linux 2.6.23, see > e.g. `man 2 open` > > http://man7.org/linux/man-pages/man2/open.2.html > > to the `open()` syscall to atomically open a file and set the Fd to > CLOEXEC in a single step. > > This flag is not the default in Haskell - but maybe it should be. Other > languages set it by default, for example Python. See > > PEP-433: https://www.python.org/dev/peps/pep-0433/ > and the newer > PEP-446: https://www.python.org/dev/peps/pep-0446/ > > for a very good description of the situation. > > Python >= 3.2 closes open Fds *after* the `exec()` when performed with > its `subprocess` module. > Python 3.4 uses O_CLOEXEC by default on all Fds opened by Python. > > It is also noted that "The programming languages Go, Perl and Ruby make > newly created file descriptors non-inheritable by default: since Go 1.0 > (2009), Perl 1.0 (1987) and Ruby 2.0 (2013)": > > https://www.python.org/dev/peps/pep-0446/#related-work > > A work-around for Haskell is to use `O_CLOEXEC` explicitly, as in this > example module `System/Posix/IO/ExecSafe.hsc`: > > https://gist.github.com/nh2/4932ecf5ca919659ae51 > > Then we can implement a safe version of `BS.writeFile`: > > https://gist.github.com/nh2/4932ecf5ca919659ae51 > > Using this form of `writeFileExecSafe` helps in cases when your program > is very small, when you can change all the code and you don't use any > libraries that open files. However, this is a very rare case, and not a > real solution. > > All multi-threaded Haskell programs that write and execute files will > inherently trigger the `Text file busy` problem. > > We need to discuss what to do about this. > > Let us run this discussion on haskell-cafe and move to the libraries@ > mailing list once we've got some ideas and opinions. > > My personal stance is that we should follow Python's example, and all > functions in our standard libraries should open files with the O_CLOEXEC > flag set. > > Niklas > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mwm at mired.org Mon Jul 20 13:57:15 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 20 Jul 2015 13:57:15 +0000 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55ACF281.6020707@nh2.me> References: <55ACF281.6020707@nh2.me> Message-ID: This is just one example of the general problem of fork()'ing with threads holding a lock. Given that locks come in different flavors and have different uses, they need individual handling. The best general solution I know of is "don't do that". One of the things I like about Haskell is that the type system gives me hints when I'm trying to do that. That said, there are a number of issues raised by leaving FD's open across an exec, and that's rarely the right thing to do. So making it the default behavior is probably a good idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Mon Jul 20 15:26:13 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Mon, 20 Jul 2015 12:26:13 -0300 Subject: [Haskell-cafe] Where else is EclipseFP available since SourceForge seems to be partially down? In-Reply-To: References: Message-ID: <55AD1315.5030800@gmail.com> [CC-ing JP Moresmau] Em 19-07-2015 23:03, KC escreveu: > Where else is EclipseFP available since SourceForge seems to be > partially down? Em 19-07-2015 23:20, Brandon Allbery escreveu: > I was under the impression that EclipseFP was no longer supported, so > possibly nowhere. It would be nice if one could still fetch the repo and binaries, though. Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From jpmoresmau at gmail.com Mon Jul 20 15:28:03 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Mon, 20 Jul 2015 17:28:03 +0200 Subject: [Haskell-cafe] Where else is EclipseFP available since SourceForge seems to be partially down? In-Reply-To: <55AD1315.5030800@gmail.com> References: <55AD1315.5030800@gmail.com> Message-ID: https://github.com/JPMoresmau/eclipsefp is still accessible, so you can get the source from there. On Mon, Jul 20, 2015 at 5:26 PM, Felipe Lessa wrote: > [CC-ing JP Moresmau] > > Em 19-07-2015 23:03, KC escreveu: > > Where else is EclipseFP available since SourceForge seems to be > > partially down? > > Em 19-07-2015 23:20, Brandon Allbery escreveu: > > I was under the impression that EclipseFP was no longer supported, so > > possibly nowhere. > > It would be nice if one could still fetch the repo and binaries, though. > > Cheers, > > -- > Felipe. > > -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Jul 20 16:22:01 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 20 Jul 2015 18:22:01 +0200 Subject: [Haskell-cafe] Message passing library Message-ID: Hello, what would you recommend as a message passing library? Essentially, I would to replace this library http://hackage.haskell.org/package/eprocess by something more mainstream. It is used in Hint-server: http://hackage.haskell.org/package/hint-server Thanks! Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Mon Jul 20 16:26:32 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Mon, 20 Jul 2015 09:26:32 -0700 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: Have you considered ZMQ? It's quite standard, well supported across languages and platforms, and has great bindings in many languages, including Haskell, and also has a great online "book". I have used it successfully with IHaskell. It does have C library requirements, though. Andrew On Mon, Jul 20, 2015 at 9:22 AM, Corentin Dupont wrote: > Hello, > what would you recommend as a message passing library? > Essentially, I would to replace this library > http://hackage.haskell.org/package/eprocess > by something more mainstream. > It is used in Hint-server: http://hackage.haskell.org/package/hint-server > > Thanks! > Corentin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Jul 20 16:27:24 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Jul 2015 11:27:24 -0500 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: I believe the primary contenders would be Cloud Haskell [1] and Courier [2]. [1]: http://hackage.haskell.org/package/distributed-process and http://haskell-distributed.github.io/ [2]: http://hackage.haskell.org/package/courier Cloud Haskell is probably more widely used. I don't know if they're leveraging Static Pointers yet, but the feature was motivated in part by their needs. We mostly use Pipes, TCP sockets, and Binary but I think you're looking for something more reliable. Probably someone will recommend ZeroMQ. I'd steer clear of ZeroMQ unless you have an intimate understanding of it and how to work around its quirks. On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont wrote: > Hello, > what would you recommend as a message passing library? > Essentially, I would to replace this library > http://hackage.haskell.org/package/eprocess > by something more mainstream. > It is used in Hint-server: http://hackage.haskell.org/package/hint-server > > Thanks! > Corentin > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Mon Jul 20 16:31:20 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 20 Jul 2015 09:31:20 -0700 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: As far as ZeroMQ goes, it made it difficult for me to build IHaskell both times I've tried. It's not insurmountable, but it is a bit of a pain. If you do end up using it, some clear (maybe even copy-pastable) instructions on how to install and check the C library itself on different systems would go a long way. I don't think it's bad enough to rule it out a priori, but it's something to keep in mind. On Jul 20, 2015 9:27 AM, "Christopher Allen" wrote: > I believe the primary contenders would be Cloud Haskell [1] and Courier > [2]. > > [1]: http://hackage.haskell.org/package/distributed-process and > http://haskell-distributed.github.io/ > > [2]: http://hackage.haskell.org/package/courier > > Cloud Haskell is probably more widely used. I don't know if they're > leveraging Static Pointers yet, but the feature was motivated in part by > their needs. > > We mostly use Pipes, TCP sockets, and Binary but I think you're looking > for something more reliable. Probably someone will recommend ZeroMQ. I'd > steer clear of ZeroMQ unless you have an intimate understanding of it and > how to work around its quirks. > > > On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> Hello, >> what would you recommend as a message passing library? >> Essentially, I would to replace this library >> http://hackage.haskell.org/package/eprocess >> by something more mainstream. >> It is used in Hint-server: http://hackage.haskell.org/package/hint-server >> >> Thanks! >> Corentin >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Jul 20 16:39:21 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Jul 2015 11:39:21 -0500 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: The problems get worse after you've successfully built it. Someone will probably pipe up to say, "it worked for me!", which is great, but I think Corentin isn't looking for first-pass functionality here. Something that has a better story for error handling is probably part of what's wanted. I don't know if Cloud Haskell or Courier will fit the bill, but I'm pretty sure ZMQ won't unless Corentin is already an expert in bashing ZMQ into place. If that were the case, why would they need to ask the mailing list for suggestions? They'd have a tool they already know well and could use for message-passing'ish over the network. On Mon, Jul 20, 2015 at 11:31 AM, Tikhon Jelvis wrote: > As far as ZeroMQ goes, it made it difficult for me to build IHaskell both > times I've tried. It's not insurmountable, but it is a bit of a pain. > > If you do end up using it, some clear (maybe even copy-pastable) > instructions on how to install and check the C library itself on different > systems would go a long way. > > I don't think it's bad enough to rule it out a priori, but it's something > to keep in mind. > On Jul 20, 2015 9:27 AM, "Christopher Allen" wrote: > >> I believe the primary contenders would be Cloud Haskell [1] and Courier >> [2]. >> >> [1]: http://hackage.haskell.org/package/distributed-process and >> http://haskell-distributed.github.io/ >> >> [2]: http://hackage.haskell.org/package/courier >> >> Cloud Haskell is probably more widely used. I don't know if they're >> leveraging Static Pointers yet, but the feature was motivated in part by >> their needs. >> >> We mostly use Pipes, TCP sockets, and Binary but I think you're looking >> for something more reliable. Probably someone will recommend ZeroMQ. I'd >> steer clear of ZeroMQ unless you have an intimate understanding of it and >> how to work around its quirks. >> >> >> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> Hello, >>> what would you recommend as a message passing library? >>> Essentially, I would to replace this library >>> http://hackage.haskell.org/package/eprocess >>> by something more mainstream. >>> It is used in Hint-server: >>> http://hackage.haskell.org/package/hint-server >>> >>> Thanks! >>> Corentin >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Mon Jul 20 16:50:05 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Mon, 20 Jul 2015 18:50:05 +0200 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: Actually I only need to pass messages between processes with a queue... No need for network... Sorry it was not clear :) On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen wrote: > I believe the primary contenders would be Cloud Haskell [1] and Courier > [2]. > > [1]: http://hackage.haskell.org/package/distributed-process and > http://haskell-distributed.github.io/ > > [2]: http://hackage.haskell.org/package/courier > > Cloud Haskell is probably more widely used. I don't know if they're > leveraging Static Pointers yet, but the feature was motivated in part by > their needs. > > We mostly use Pipes, TCP sockets, and Binary but I think you're looking > for something more reliable. Probably someone will recommend ZeroMQ. I'd > steer clear of ZeroMQ unless you have an intimate understanding of it and > how to work around its quirks. > > > On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> Hello, >> what would you recommend as a message passing library? >> Essentially, I would to replace this library >> http://hackage.haskell.org/package/eprocess >> by something more mainstream. >> It is used in Hint-server: http://hackage.haskell.org/package/hint-server >> >> Thanks! >> Corentin >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at functorgroup.com Mon Jul 20 16:51:15 2015 From: j at functorgroup.com (Johan Glimming) Date: Mon, 20 Jul 2015 16:51:15 +0000 Subject: [Haskell-cafe] =?utf-8?q?Several_Experienced_Developers_for_Advan?= =?utf-8?q?ced_Functional_Programming_-_Ocaml=2C_Haskell=2C_Scala_-_compil?= =?utf-8?q?er_technology=2C_LLVM=2C_C=2C_etcetera=2C__and_Martin-L=C3=B6f_?= =?utf-8?q?type_theory=2C_static_analysis=2C_our_main_target_is_embedded_s?= =?utf-8?q?oftware?= Message-ID: Hi folks, There are openings at Functor, Sweden, including also remote work, except for Scala consultants who must immediately relocate: Do you want to be part of the journey as the Functor startup research spin-off innovates the future of software engineering? Do you want to make a difference? Do you want to devote your talents where it can have incredible impact on the entire software industry? Functor, Sweden, is again looking for brilliant minds, essentially co-founders as a generous equity program will after a certain threshold time make sure developers, building the company indeed, also own what they are building. Please apply on LinkedIn, closing soon take action if interested: https://www.linkedin.com/jobs2/consumer/overview/60296037 We use Haskell, OCaml, LLVM and our tools are closely tied to the C programming language and indeed to functional programming. Embedded software market is one target market, and skills in compiler design, type systems and operational semantics is key to our teams though we look for optimised teams as a whole, and your particular skill set may or may not include a PhD, but surely industrial experience. We have openings for Research Engineers and have some renown Research Engineers already. Research collaboration is key to our success and projects planned including a large EU project CONSTRUCTOR next year. We have strong industrial partners and some very high-profile customers internationally. The customer-driven journey is still at an early stage, while founded in 2011, and your contributions would be key to our success. Scala consultants will be sent straight from the top down into projects at Ericsson for very challenging work. For these three consultants we require an exceptionally strong background with Scala projects as we team up with Typesafe and secure projects that can only be matched by exceptional Scala developers. Our Functor Scalor? is oriented somewhat differently than Scala, see www.domainspecific.org for some initial information on that products that appeals to very large companies at this stage, while Functor Prevent? is suitable for just about any software development projects, currently doing static analysis with dependent types and automatic testing for C code, such as the Erlang code base, Twitter?s MySQL branch or embedded software at large, see www.functorprevent.com or www.static-analysis.org, and also the standalone tool www.functor.se/prevent which secures systems including a project at a customer with a range of 100 MEUR/each equipment investments, all relying on the VxWorks C code where our Functor Prevent? delivers its value to prevent up to 50% of the bugs in certain projects, already with its current R1 feature set! [cid:BA7C0361-C40F-4993-820E-420FB0B1543B at in.functor.se] Instructions and information, please read carefully the last paragraph on what we need to evaluate candidates adequately: https://www.linkedin.com/pulse/openings-functional-programmers-swedish-startup-johan-glimming Read up with links above to our webpages (last link), and postings on LinkedIn and Facebook: https://www.linkedin.com/pulse/future-software-engineering-johan-glimming?trk=mp-reader-card Facebook eg: http://www.facebook.com/functor Webpage has more information, linked to one the main posting above for some key webpages to check: www.functor.se [3230fbd.png] Welcome to apply and be part of an exciting journey ahead with a very important mission to turn software engineering into a discipline at last, backed by industrial productification for years and R&D that have never reached the software industry due to its inherent complexity, now mature, and now with proven market fit with Functor Prevent? and Functor Scalor? being used in heavy duty projects but much more to come! It?s Martin-L?f / dependent type theory inside our tools. Best, Johan ? Dr Johan Glimming Chief Executive Officer at Functor AB, Chairman at Functor Group AB Request a meeting or schedule a call: www.doodle.com/glimming Mobile: +46-76-7646000 Direct: +46-8-55005505 Main: +46-8-55005500 Assistant: +46-8-55005501 Skype: glimming Twitter: @glimming LinkedIn: se.linkedin.com/in/glimming Functor AB, Box 7070, 164 07 Kista, SWEDEN Web: www.functorgroup.com Twitter: @functors UK tel: +44-1223-911400 US tel: +1-(415)-513-0090 ? ANY INFORMATION DISCLOSED DIRECTLY OR INDIRECTLY IN, OR IMPLIED BY, THIS EMAIL, INCLUDING ATTACHMENTS, EXTERNAL REFERENCES OR APPENDICES, IS STRICTLY CONFIDENTIAL AND/OR PROPRIETARY AND IS INTENDED ONLY FOR USE BY FUNCTOR GROUP AB, SWEDEN, REG. NR. 556972-3736, AND ITS SUBSIDIARIES ? OR BY A THIRD PARTY STRICTLY IN FUNCTOR GROUP AB?S OR ITS SUBSIDIARIES' DIRECT INTEREST, BUT ONLY FOR THOSE PARTIES LISTED AS DESIGNATED RECIPIENTS AND PARTIES WITH PRIOR WRITTEN PERMISSION. ANY UNAUTHORISED RELEASE OR USE OF THIS INFORMATION IS PROHIBITED AND PUNISHABLE BY LAW. YOU SHOULD IMMEDIATELY UPON RECEIVING THIS E-MAIL, YOU SHOULD IMMEDIATELY CONTACT THE SENDER OR FUNCTOR. OUR LAWYERS AT LEGAL at FUNCFTORGROUP.COM OR +46-8-55005517 ARE AVAILABLE AS NEEDED. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: AAEAAQAAAAAAAAJyAAAAJDY0ZmQ2NDc1LTY5ZjAtNDBlNC1hN2JmLTNmYzllZTllMjg5OA.jpeg Type: image/jpeg Size: 46048 bytes Desc: AAEAAQAAAAAAAAJyAAAAJDY0ZmQ2NDc1LTY5ZjAtNDBlNC1hN2JmLTNmYzllZTllMjg5OA.jpeg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 3230fbd.png Type: image/png Size: 320803 bytes Desc: 3230fbd.png URL: From aeroboy94 at gmail.com Mon Jul 20 17:00:44 2015 From: aeroboy94 at gmail.com (Arian van Putten) Date: Mon, 20 Jul 2015 19:00:44 +0200 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: You could just use Unix sockets. You ca n create those with the standard network library if I recall correctly. On 20 Jul 2015 18:50, "Corentin Dupont" wrote: > Actually I only need to pass messages between processes with a queue... > No need for network... Sorry it was not clear :) > > > > On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen > wrote: > >> I believe the primary contenders would be Cloud Haskell [1] and Courier >> [2]. >> >> [1]: http://hackage.haskell.org/package/distributed-process and >> http://haskell-distributed.github.io/ >> >> [2]: http://hackage.haskell.org/package/courier >> >> Cloud Haskell is probably more widely used. I don't know if they're >> leveraging Static Pointers yet, but the feature was motivated in part by >> their needs. >> >> We mostly use Pipes, TCP sockets, and Binary but I think you're looking >> for something more reliable. Probably someone will recommend ZeroMQ. I'd >> steer clear of ZeroMQ unless you have an intimate understanding of it and >> how to work around its quirks. >> >> >> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> Hello, >>> what would you recommend as a message passing library? >>> Essentially, I would to replace this library >>> http://hackage.haskell.org/package/eprocess >>> by something more mainstream. >>> It is used in Hint-server: >>> http://hackage.haskell.org/package/hint-server >>> >>> Thanks! >>> Corentin >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Jul 20 17:09:48 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Jul 2015 12:09:48 -0500 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: What isn't satisfactory with what you currently have? Are you just looking for more support so you don't have to DIY? Cloud Haskell and Courier both have an in-memory backends, so I'm not sure how to whittle things down yet without other candidate libraries/tech to consider. The only other options that come to mind right now as being related to message passing go in the opposite direction of what you want, like Kafka. On Mon, Jul 20, 2015 at 11:50 AM, Corentin Dupont wrote: > Actually I only need to pass messages between processes with a queue... > No need for network... Sorry it was not clear :) > > > > On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen > wrote: > >> I believe the primary contenders would be Cloud Haskell [1] and Courier >> [2]. >> >> [1]: http://hackage.haskell.org/package/distributed-process and >> http://haskell-distributed.github.io/ >> >> [2]: http://hackage.haskell.org/package/courier >> >> Cloud Haskell is probably more widely used. I don't know if they're >> leveraging Static Pointers yet, but the feature was motivated in part by >> their needs. >> >> We mostly use Pipes, TCP sockets, and Binary but I think you're looking >> for something more reliable. Probably someone will recommend ZeroMQ. I'd >> steer clear of ZeroMQ unless you have an intimate understanding of it and >> how to work around its quirks. >> >> >> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> Hello, >>> what would you recommend as a message passing library? >>> Essentially, I would to replace this library >>> http://hackage.haskell.org/package/eprocess >>> by something more mainstream. >>> It is used in Hint-server: >>> http://hackage.haskell.org/package/hint-server >>> >>> Thanks! >>> Corentin >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Jul 20 17:23:45 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 20 Jul 2015 12:23:45 -0500 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: Another library to keep in mind could be slave-thread: http://hackage.haskell.org/package/slave-thread ? potentially useful if you have forkIO'd processors of messages. On Mon, Jul 20, 2015 at 12:09 PM, Christopher Allen wrote: > What isn't satisfactory with what you currently have? Are you just looking > for more support so you don't have to DIY? Cloud Haskell and Courier both > have an in-memory backends, so I'm not sure how to whittle things down yet > without other candidate libraries/tech to consider. The only other options > that come to mind right now as being related to message passing go in the > opposite direction of what you want, like Kafka. > > On Mon, Jul 20, 2015 at 11:50 AM, Corentin Dupont < > corentin.dupont at gmail.com> wrote: > >> Actually I only need to pass messages between processes with a queue... >> No need for network... Sorry it was not clear :) >> >> >> >> On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen >> wrote: >> >>> I believe the primary contenders would be Cloud Haskell [1] and Courier >>> [2]. >>> >>> [1]: http://hackage.haskell.org/package/distributed-process and >>> http://haskell-distributed.github.io/ >>> >>> [2]: http://hackage.haskell.org/package/courier >>> >>> Cloud Haskell is probably more widely used. I don't know if they're >>> leveraging Static Pointers yet, but the feature was motivated in part by >>> their needs. >>> >>> We mostly use Pipes, TCP sockets, and Binary but I think you're looking >>> for something more reliable. Probably someone will recommend ZeroMQ. I'd >>> steer clear of ZeroMQ unless you have an intimate understanding of it and >>> how to work around its quirks. >>> >>> >>> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < >>> corentin.dupont at gmail.com> wrote: >>> >>>> Hello, >>>> what would you recommend as a message passing library? >>>> Essentially, I would to replace this library >>>> http://hackage.haskell.org/package/eprocess >>>> by something more mainstream. >>>> It is used in Hint-server: >>>> http://hackage.haskell.org/package/hint-server >>>> >>>> Thanks! >>>> Corentin >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> > > > -- > Chris Allen > Currently working on http://haskellbook.com > -- Chris Allen Currently working on http://haskellbook.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Mon Jul 20 22:28:21 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 20 Jul 2015 18:28:21 -0400 Subject: [Haskell-cafe] Message passing library In-Reply-To: References: Message-ID: <99D1C229-C920-4572-8820-D42B29A03682@gmail.com> Are you sure you don't just want Control.Concurrent.Chan or similar? Tom El Jul 20, 2015, a las 13:23, Christopher Allen escribi?: > Another library to keep in mind could be slave-thread: http://hackage.haskell.org/package/slave-thread ? potentially useful if you have forkIO'd processors of messages. > > On Mon, Jul 20, 2015 at 12:09 PM, Christopher Allen wrote: >> What isn't satisfactory with what you currently have? Are you just looking for more support so you don't have to DIY? Cloud Haskell and Courier both have an in-memory backends, so I'm not sure how to whittle things down yet without other candidate libraries/tech to consider. The only other options that come to mind right now as being related to message passing go in the opposite direction of what you want, like Kafka. >> >> On Mon, Jul 20, 2015 at 11:50 AM, Corentin Dupont wrote: >>> Actually I only need to pass messages between processes with a queue... >>> No need for network... Sorry it was not clear :) >>> >>> >>> >>> On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen wrote: >>>> I believe the primary contenders would be Cloud Haskell [1] and Courier [2]. >>>> >>>> [1]: http://hackage.haskell.org/package/distributed-process and http://haskell-distributed.github.io/ >>>> >>>> [2]: http://hackage.haskell.org/package/courier >>>> >>>> Cloud Haskell is probably more widely used. I don't know if they're leveraging Static Pointers yet, but the feature was motivated in part by their needs. >>>> >>>> We mostly use Pipes, TCP sockets, and Binary but I think you're looking for something more reliable. Probably someone will recommend ZeroMQ. I'd steer clear of ZeroMQ unless you have an intimate understanding of it and how to work around its quirks. >>>> >>>> >>>> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont wrote: >>>>> Hello, >>>>> what would you recommend as a message passing library? >>>>> Essentially, I would to replace this library http://hackage.haskell.org/package/eprocess >>>>> by something more mainstream. >>>>> It is used in Hint-server: http://hackage.haskell.org/package/hint-server >>>>> >>>>> Thanks! >>>>> Corentin >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>>> >>>> -- >>>> Chris Allen >>>> Currently working on http://haskellbook.com >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue Jul 21 05:52:48 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 21 Jul 2015 12:52:48 +0700 Subject: [Haskell-cafe] Where is Haskell Weekly News syndicated? In-Reply-To: <1437377283118-5813708.post@n5.nabble.com> References: <1426087518070-5766854.post@n5.nabble.com> <1426408319367-5767017.post@n5.nabble.com> <20150315145524.GA73677@inanna.trygub.com> <1434614959662-5811671.post@n5.nabble.com> <1434629971980-5811691.post@n5.nabble.com> <1437377283118-5813708.post@n5.nabble.com> Message-ID: On Mon, Jul 20, 2015 at 2:28 PM, Jeremy wrote: > Last edition was over a month ago. Has there been a hiatus? Yes. You'll find out why in the latest issue out soon. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Tue Jul 21 09:43:49 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 21 Jul 2015 11:43:49 +0200 Subject: [Haskell-cafe] Message passing library In-Reply-To: <99D1C229-C920-4572-8820-D42B29A03682@gmail.com> References: <99D1C229-C920-4572-8820-D42B29A03682@gmail.com> Message-ID: Actually I'm already using Chan in https://hackage.haskell.org/package/eprocess But I wondered if something more mainstream existed :) On Tue, Jul 21, 2015 at 12:28 AM, wrote: > Are you sure you don't just want Control.Concurrent.Chan or similar? > > Tom > > > El Jul 20, 2015, a las 13:23, Christopher Allen > escribi?: > > Another library to keep in mind could be slave-thread: > http://hackage.haskell.org/package/slave-thread ? potentially useful if > you have forkIO'd processors of messages. > > On Mon, Jul 20, 2015 at 12:09 PM, Christopher Allen > wrote: > >> What isn't satisfactory with what you currently have? Are you just >> looking for more support so you don't have to DIY? Cloud Haskell and >> Courier both have an in-memory backends, so I'm not sure how to whittle >> things down yet without other candidate libraries/tech to consider. The >> only other options that come to mind right now as being related to message >> passing go in the opposite direction of what you want, like Kafka. >> >> On Mon, Jul 20, 2015 at 11:50 AM, Corentin Dupont < >> corentin.dupont at gmail.com> wrote: >> >>> Actually I only need to pass messages between processes with a queue... >>> No need for network... Sorry it was not clear :) >>> >>> >>> >>> On Mon, Jul 20, 2015 at 6:27 PM, Christopher Allen >>> wrote: >>> >>>> I believe the primary contenders would be Cloud Haskell [1] and Courier >>>> [2]. >>>> >>>> [1]: http://hackage.haskell.org/package/distributed-process and >>>> http://haskell-distributed.github.io/ >>>> >>>> [2]: http://hackage.haskell.org/package/courier >>>> >>>> Cloud Haskell is probably more widely used. I don't know if they're >>>> leveraging Static Pointers yet, but the feature was motivated in part by >>>> their needs. >>>> >>>> We mostly use Pipes, TCP sockets, and Binary but I think you're looking >>>> for something more reliable. Probably someone will recommend ZeroMQ. I'd >>>> steer clear of ZeroMQ unless you have an intimate understanding of it and >>>> how to work around its quirks. >>>> >>>> >>>> On Mon, Jul 20, 2015 at 11:22 AM, Corentin Dupont < >>>> corentin.dupont at gmail.com> wrote: >>>> >>>>> Hello, >>>>> what would you recommend as a message passing library? >>>>> Essentially, I would to replace this library >>>>> http://hackage.haskell.org/package/eprocess >>>>> by something more mainstream. >>>>> It is used in Hint-server: >>>>> http://hackage.haskell.org/package/hint-server >>>>> >>>>> Thanks! >>>>> Corentin >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>>> >>>> -- >>>> Chris Allen >>>> Currently working on http://haskellbook.com >>>> >>> >>> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > > -- > Chris Allen > Currently working on http://haskellbook.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vagarenko at gmail.com Tue Jul 21 13:35:49 2015 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Tue, 21 Jul 2015 06:35:49 -0700 (PDT) Subject: [Haskell-cafe] Why there is no instance Generic Word? Message-ID: <10a946a9-e6fe-4d53-a3e5-44ab5b76f613@googlegroups.com> There is instance Generic Int, but not Generic Word. Also no Generic instances for Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64. -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Tue Jul 21 23:11:17 2015 From: winterkoninkje at gmail.com (wren romano) Date: Tue, 21 Jul 2015 19:11:17 -0400 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: On Wed, Jul 8, 2015 at 9:14 PM, Richard Eisenberg wrote: > I think GADTs are a red herring here -- this is the classic show/read ambiguity dressed up. In the code below, how should GHC determine the type of e1' or e2'? There's no way to know. Except that when I erase the indices, everything works just fine: {-# LANGUAGE KindSignatures, GADTs #-} data Type = Fun Type Type data AST :: * -> * where App :: ast -> ast -> AST ast class ABT (abt :: *) where view :: abt -> AST abt unview :: AST abt -> abt class WellTypedABT (abt :: *) where unviewWT :: Type -> AST abt -> abt typeOf :: abt -> Type data TypeCheckMonad a = TCM { unTCM :: a } instance Functor TypeCheckMonad where fmap f = TCM . f . unTCM instance Applicative TypeCheckMonad where pure = TCM TCM f <*> TCM x = TCM (f x) instance Monad TypeCheckMonad where return = pure TCM x >>= k = k x inferType :: (ABT abt, WellTypedABT abt') => abt -> TypeCheckMonad abt' inferType e0 = case view e0 of App e1 e2 -> do e1' <- inferType e1 case typeOf e1' of Fun typ2 typ3 -> do e2' <- inferType e2 return . unviewWT typ3 $ App e1' e2' -- Live well, ~wren From donn at avvanta.com Wed Jul 22 02:47:20 2015 From: donn at avvanta.com (Donn Cave) Date: Tue, 21 Jul 2015 19:47:20 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55ACF281.6020707@nh2.me> References: <55ACF281.6020707@nh2.me> Message-ID: <20150722024720.CAE18F3938@mail.avvanta.com> quoth Niklas Hamb?chen, ... > The scope of this program is quite general unfortunately: It will happen > for any program that uses parallel threads, and that runs two or more > external processes at some time. It cannot be fixed by the part that > starts the external process (e.g. you can't write a reliable > `readProcess` function that doesn't have this problem, since the problem > is rooted in the Fds, and there is no version of `exec()` that doesn't > inherit parent Fds). > > This problem is a general problem in C on Unix, and was discovered quite > late. I believe it has actually been a familiar issue for decades. I don't have any code handy to check, but I'm pretty sure the UNIX system(3) and popen(3) functions closed extraneous file descriptors back in the early '90s, and probably had been doing it for some time by then. I believe this approach to the problem is supported in System.Process, via close_fds. Implementation is a walk through open FDs, in the child fork, closing anything not called for by the procedure's parameters prior to the exec. That approach has the advantage that it applies to all file descriptors, whether created by open(2) or by other means - socket, dup(2), etc. I like this already implemented solution much better than adding a new flag to "all" opens (really only those opens that occur within the Haskell runtime, while of course not for external library FDs.) The O_CLOEXEC proposal wouldn't be the worst or most gratuitous way Haskell tampers with normal UNIX parameters, but any time you do that, you set up the conditions for breaking something that works in C, which I hate to see happen with Haskell. Donn From mail at andres-loeh.de Wed Jul 22 06:59:37 2015 From: mail at andres-loeh.de (Andres Loeh) Date: Wed, 22 Jul 2015 08:59:37 +0200 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Hi. I've drastically reduced the example. This program triggers the same error: > {-# LANGUAGE GADTs, KindSignatures #-} > > data Sing :: * -> * where > SFun :: Sing (Maybe j) > > class WellTypedABT (abt :: * -> *) where > typeOf :: abt a -> Sing a > > inferType :: (WellTypedABT abt') => abt a -> abt' a > inferType e1 = > let e1' = inferType e1 > in case typeOf e1' of > SFun -> e1' Btw, this compiles fine with ghc-6.12 (as does a version of the original program if we replace the data kinds involved by equivalent kind-*-datatypes). Cheers, Andres On Wed, Jul 22, 2015 at 1:11 AM, wren romano wrote: > On Wed, Jul 8, 2015 at 9:14 PM, Richard Eisenberg wrote: >> I think GADTs are a red herring here -- this is the classic show/read ambiguity dressed up. In the code below, how should GHC determine the type of e1' or e2'? There's no way to know. > > Except that when I erase the indices, everything works just fine: > > > {-# LANGUAGE KindSignatures, GADTs #-} > > data Type = Fun Type Type > > data AST :: * -> * where > App :: ast -> ast -> AST ast > > class ABT (abt :: *) where > view :: abt -> AST abt > unview :: AST abt -> abt > > class WellTypedABT (abt :: *) where > unviewWT :: Type -> AST abt -> abt > typeOf :: abt -> Type > > data TypeCheckMonad a = TCM { unTCM :: a } > > instance Functor TypeCheckMonad where > fmap f = TCM . f . unTCM > > instance Applicative TypeCheckMonad where > pure = TCM > TCM f <*> TCM x = TCM (f x) > > instance Monad TypeCheckMonad where > return = pure > TCM x >>= k = k x > > inferType > :: (ABT abt, WellTypedABT abt') > => abt > -> TypeCheckMonad abt' > inferType e0 = > case view e0 of > App e1 e2 -> do > e1' <- inferType e1 > case typeOf e1' of > Fun typ2 typ3 -> do > e2' <- inferType e2 > return . unviewWT typ3 $ App e1' e2' > > > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From oleg.grenrus at iki.fi Wed Jul 22 07:53:09 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Wed, 22 Jul 2015 10:53:09 +0300 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Nailing down `abt` and `abt?`, but keeping `a` free makes the trick: {-# LANGUAGE DataKinds, PolyKinds, GADTs, RankNTypes, ScopedTypeVariables #-} data Type = Fun Type Type | Unit data Sing :: Type -> * where SUnit :: Sing Unit SFun :: Sing i -> Sing j -> Sing (Fun i j) data AST :: (Type -> *) -> Type -> * where TT :: AST ast Unit App :: ast (Fun a b) -> ast a -> AST ast b class ABT (abt :: Type -> *) where view :: abt a -> AST abt a unview :: AST abt a -> abt a class WellTypedABT (abt :: Type -> *) where unviewWT :: Sing a -> AST abt a -> abt a typeOf :: abt a -> Sing a type TypeCheckMonad = Maybe inferType :: forall abt abt' a. (ABT abt, WellTypedABT abt') => abt a -> TypeCheckMonad (abt' a) inferType e0 = go e0 -- b is free, abt and abt' are bounded, class dictionaries come from above. where go :: forall b. abt b -> TypeCheckMonad (abt' b) go e0' = case view e0' of TT -> return . unviewWT SUnit $ TT App e1 e2 -> do e1' <- go e1 case typeOf e1' of -- -Wall doesn't warn about missing SUnit case here, victory! SFun _typ2 typ3 -> do e2' <- inferType e2 return . unviewWT typ3 $ App e1' e2' > On 07 Jul 2015, at 19:05, wren romano wrote: > > On Tue, Jul 7, 2015 at 3:35 AM, Simon Peyton Jones > wrote: >> If you post a repro case someone (even me) might help. The devil is always in the details. > > The smallest repro I can come up with (which is still related to the > actual problem) is as follows. In case it matters for the solution, > there are a number of important bits I've erased. Most importantly, > the inferType function is actually mutually recursive with a checkType > function, though that doesn't seem to be the cause of the problem. > > > {-# LANGUAGE DataKinds, PolyKinds, GADTs #-} > > data Type = Fun Type Type > > data Sing :: Type -> * where > SFun :: Sing i -> Sing j -> Sing (Fun i j) > > data AST :: (Type -> *) -> Type -> * where > App :: ast (Fun a b) -> ast a -> AST ast b > > class ABT (abt :: Type -> *) where > view :: abt a -> AST abt a > unview :: AST abt a -> abt a > > class WellTypedABT (abt :: Type -> *) where > unviewWT :: Sing a -> AST abt a -> abt a > typeOf :: abt a -> Sing a > > data TypeCheckMonad a = TCM { unTCM :: a } > > instance Functor TypeCheckMonad where > fmap f = TCM . f . unTCM > > instance Applicative TypeCheckMonad where > pure = TCM > TCM f <*> TCM x = TCM (f x) > > instance Monad TypeCheckMonad where > return = pure > TCM x >>= k = k x > > inferType > :: (ABT abt, WellTypedABT abt') > => abt a > -> TypeCheckMonad (abt' a) > inferType e0 = > case view e0 of > App e1 e2 -> do > e1' <- inferType e1 > case typeOf e1' of > SFun typ2 typ3 -> do > e2' <- inferType e2 > return . unviewWT typ3 $ App e1' e2' > -- > Live well, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mail at nh2.me Wed Jul 22 12:33:19 2015 From: mail at nh2.me (=?windows-1252?Q?Niklas_Hamb=FCchen?=) Date: Wed, 22 Jul 2015 14:33:19 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150722024720.CAE18F3938@mail.avvanta.com> References: <55ACF281.6020707@nh2.me> <20150722024720.CAE18F3938@mail.avvanta.com> Message-ID: <55AF8D8F.5000606@nh2.me> Hello Donn, Python has a detailed discussion of this suggestion: * https://www.python.org/dev/peps/pep-0433/#close-file-descriptors-after-fork * https://www.python.org/dev/peps/pep-0446/#closing-all-open-file-descriptors It highlights some problems with this approach, most notably Windows problems, not solving the problem when you exec() without fork(), and looping up to MAXFD being slow (this is what the current Haskell `runInteractiveProcess` code (http://hackage.haskell.org/package/process-1.2.3.0/src/cbits/runProcess.c) seems to be doing; Python improved upon this by not looping up to MAXFD, but instead looking up the open FDs in /proc//fd/, after people complained about this loop of close() syscalls being very slow when many FDs were open. > do that, you set up the conditions for breaking something that > works in C, which I hate to see happen with Haskell. While I understand your opinion here, I'm not sure that "breaking something that works in C" is the right description. O_CLOEXEC changes a default setting, but does not irrevocably disable any feature that is available in C. The difference is that you'd have to say which FDs you want to keep in the child - which to my knowledge is OK, since it is a much more common thing to work with *some* designated FDs in the child process than with all of them. To elaborate a bit, if you wanted to write a program where a child process would access the parent's Fds, you would in most cases already have those Fds in some Haskell variables you're working with. In that case, it is easy to `setFdOption fd CloseOnExec False` on those if CLOEXEC is the default, and everybody is happy. If CLOEXEC is not the default, then you'd get a problem with all those Fds on which do *not* have a grip in your program, and it's much harder to fix problems with these resources that are around invisible in the background than with those that you have in variables that you use. In other words, CLOEXEC is something that is easy to *undo* locally when you don't want it, but hard to *do* globally when you need it. Let me know what you think about this. Niklas On 22/07/15 04:47, Donn Cave wrote: > quoth Niklas Hamb?chen, > ... >> The scope of this program is quite general unfortunately: It will happen >> for any program that uses parallel threads, and that runs two or more >> external processes at some time. It cannot be fixed by the part that >> starts the external process (e.g. you can't write a reliable >> `readProcess` function that doesn't have this problem, since the problem >> is rooted in the Fds, and there is no version of `exec()` that doesn't >> inherit parent Fds). >> >> This problem is a general problem in C on Unix, and was discovered quite >> late. > > I believe it has actually been a familiar issue for decades. I don't > have any code handy to check, but I'm pretty sure the UNIX system(3) > and popen(3) functions closed extraneous file descriptors back in the > early '90s, and probably had been doing it for some time by then. > > I believe this approach to the problem is supported in System.Process, > via close_fds. Implementation is a walk through open FDs, in the child > fork, closing anything not called for by the procedure's parameters > prior to the exec. > > That approach has the advantage that it applies to all file descriptors, > whether created by open(2) or by other means - socket, dup(2), etc. > > I like this already implemented solution much better than adding a > new flag to "all" opens (really only those opens that occur within > the Haskell runtime, while of course not for external library FDs.) > The O_CLOEXEC proposal wouldn't be the worst or most gratuitous > way Haskell tampers with normal UNIX parameters, but any time you > do that, you set up the conditions for breaking something that > works in C, which I hate to see happen with Haskell. > > Donn > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From aeyerstaylor11 at gmail.com Wed Jul 22 12:50:36 2015 From: aeyerstaylor11 at gmail.com (Alexander Eyers-Taylor) Date: Wed, 22 Jul 2015 13:50:36 +0100 Subject: [Haskell-cafe] Fwd: Re: Strange "ambiguity" problems thanks to GADTs In-Reply-To: <55AF8B98.9040605@gmail.com> References: <55AF8B98.9040605@gmail.com> Message-ID: <55AF919C.8000609@gmail.com> Sorry I forgot to reply to the list Alex -------- Forwarded Message -------- Subject: Re: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs Date: Wed, 22 Jul 2015 13:24:56 +0100 From: Alexander Eyers-Taylor To: Andres Loeh Hi In this case what happens in the type checker is that after checking the start of the let we give the variable e1 a type (say abt0a) Then we enter the case. When entering the case, as SFun introduces a constaint (SFun is actually of type (a ~ Maybe j) => Sing a). As we have a constraint we cannot then unify the variables. The reason we can't unify is that we cant tell that (a ~ Maybe j) does not imply (abt0 ~ abt'). In GHC 6.12 the old type inference algotrithm was used. This had some problems as it didn't always infer a priciple type for GADTs. The new inference algorithm OutsideIn does this in a more principled way. In the non-indexed versions when we do the pattern match no constaints are introduced so we can typecheck as usual Alex On 22/07/15 07:59, Andres Loeh wrote: > Hi. > > I've drastically reduced the example. This program triggers the same error: > >> {-# LANGUAGE GADTs, KindSignatures #-} >> >> data Sing :: * -> * where >> SFun :: Sing (Maybe j) >> >> class WellTypedABT (abt :: * -> *) where >> typeOf :: abt a -> Sing a >> >> inferType :: (WellTypedABT abt') => abt a -> abt' a >> inferType e1 = >> let e1' = inferType e1 >> in case typeOf e1' of >> SFun -> e1' > Btw, this compiles fine with ghc-6.12 (as does a version of the > original program if we replace the data kinds involved by equivalent > kind-*-datatypes). > > Cheers, > Andres > > On Wed, Jul 22, 2015 at 1:11 AM, wren romano wrote: >> On Wed, Jul 8, 2015 at 9:14 PM, Richard Eisenberg wrote: >>> I think GADTs are a red herring here -- this is the classic show/read ambiguity dressed up. In the code below, how should GHC determine the type of e1' or e2'? There's no way to know. >> Except that when I erase the indices, everything works just fine: >> >> >> {-# LANGUAGE KindSignatures, GADTs #-} >> >> data Type = Fun Type Type >> >> data AST :: * -> * where >> App :: ast -> ast -> AST ast >> >> class ABT (abt :: *) where >> view :: abt -> AST abt >> unview :: AST abt -> abt >> >> class WellTypedABT (abt :: *) where >> unviewWT :: Type -> AST abt -> abt >> typeOf :: abt -> Type >> >> data TypeCheckMonad a = TCM { unTCM :: a } >> >> instance Functor TypeCheckMonad where >> fmap f = TCM . f . unTCM >> >> instance Applicative TypeCheckMonad where >> pure = TCM >> TCM f <*> TCM x = TCM (f x) >> >> instance Monad TypeCheckMonad where >> return = pure >> TCM x >>= k = k x >> >> inferType >> :: (ABT abt, WellTypedABT abt') >> => abt >> -> TypeCheckMonad abt' >> inferType e0 = >> case view e0 of >> App e1 e2 -> do >> e1' <- inferType e1 >> case typeOf e1' of >> Fun typ2 typ3 -> do >> e2' <- inferType e2 >> return . unviewWT typ3 $ App e1' e2' >> >> >> -- >> Live well, >> ~wren >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Wed Jul 22 13:07:52 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 22 Jul 2015 23:07:52 +1000 Subject: [Haskell-cafe] ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0 Message-ID: I'm pleased to announce that I've (finally!) just released version 5.5.2.0 of [fgl]. Major changes in this release include a test suite, refactorings, code clean-ups and the following potentially breaking changes (in that they were previously unspecified or incorrect): - `nodeRange` and `nodeRangeM` for the various graph data structures erroneously returned `(0,0)` for empty graphs (making them indistinguishable from graphs containing the single node `0`). They now match the default implementation of throwing an error. - The behaviour of `delLEdge` when dealing with multiple edges was unspecified; it now deletes only a single edge and the new function `delAllLEdge` deletes all edges matching the one provided. All changes can be found in the changelog. [fgl]: https://hackage.haskell.org/package/fgl Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e. the "I finally build against the version on Hackage" release). [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From haskell at dshevchenko.biz Wed Jul 22 19:04:05 2015 From: haskell at dshevchenko.biz (Denis Shevchenko) Date: Wed, 22 Jul 2015 22:04:05 +0300 Subject: [Haskell-cafe] ghc-mod: cannot satisfy yesod-static Message-ID: <55AFE925.4030503@dshevchenko.biz> Hi all! I'm trying to use ghc-mod with my Yesod-project, but I get this error: $ ghc-mod ghc-mod: : cannot satisfy -package-id yesod-static-1.4.0.4-c893310d859222b1b20461f9fdb4d916 (use -v for more information) My project builds correctly. In my .cabal-file I see this dependency: build-depends: base >= 4 && < 5 , yesod >= 1.4.0 && < 1.5 , yesod-core >= 1.4.0 && < 1.5 , yesod-auth >= 1.4.0 && < 1.5 , yesod-static >= 1.4.0 && < 1.5 ... I use LTS-2.18, and I see this package in ~/.stack/snapshots/x86_64-osx/lts-2.18/7.8.4/lib/x86_64-osx-ghc-7.8.4/: ... yesod-static-1.4.0.4 ... So, what can I do? Please help me. Sincerely, Denis. From lists at andy-morris.xyz Wed Jul 22 19:36:19 2015 From: lists at andy-morris.xyz (Andrew Morris) Date: Wed, 22 Jul 2015 20:36:19 +0100 Subject: [Haskell-cafe] ghc-mod: cannot satisfy yesod-static In-Reply-To: <55AFE925.4030503@dshevchenko.biz> References: <55AFE925.4030503@dshevchenko.biz> Message-ID: Ghc-mod doesn't support Stack yet, only plain Cabal sandboxes. It is in progress though; see, e.g.: > On 22 Jul 2015, at 20:04, Denis Shevchenko wrote: > > Hi all! > > I'm trying to use ghc-mod with my Yesod-project, but I get this error: > > $ ghc-mod > ghc-mod: : cannot satisfy -package-id yesod-static-1.4.0.4-c893310d859222b1b20461f9fdb4d916 > (use -v for more information) > > My project builds correctly. In my .cabal-file I see this dependency: > > build-depends: base >= 4 && < 5 > , yesod >= 1.4.0 && < 1.5 > , yesod-core >= 1.4.0 && < 1.5 > , yesod-auth >= 1.4.0 && < 1.5 > , yesod-static >= 1.4.0 && < 1.5 > ... > > I use LTS-2.18, and I see this package in ~/.stack/snapshots/x86_64-osx/lts-2.18/7.8.4/lib/x86_64-osx-ghc-7.8.4/: > > ... > yesod-static-1.4.0.4 > ... > > So, what can I do? Please help me. > > Sincerely, Denis. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From fuuzetsu at fuuzetsu.co.uk Wed Jul 22 21:17:33 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 22 Jul 2015 22:17:33 +0100 Subject: [Haskell-cafe] ANN: haddock-2.16.1 Message-ID: <55B0086D.8000801@fuuzetsu.co.uk> Hi, We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I inline the changelog at the bottom. It should work fine with 7.10.x GHC family. The packages are already on Hackage: haddock for the executable, haddock-api for the guts and use from Haskell and haddock-library which is the comment parser. It should also be shipping with GHC 7.10.2. I think two things are worth mentioning before: * The pending mathjax PR[1] is going to be included in future release of Haddock. As it is likely to break the interface file version, I am putting it off a bit to bundle with other possibly interface-breaking changes. * Our GSOC student has successfully completed first part of his project[2]. It involves native source code highlighting and perhaps more excitingly, source hyperlinking: you should now be able to click on identifiers to be taken to their definitions. This change is not in 2.16.1 as it is rather recent so we erred on the side of safety when picking what to release with GHC 7.10.2. You can try it by building current Haddock master, should work with 7.10.x family. As usual, if you want to contribute, please do so on GitHub. We're also on IRC under #haddock. Thanks! Changes in version 2.16.1 * Don't default to type constructors for out-of-scope names (#253 and #375) * Fix Hoogle display of constructors (#361) * Fully qualify names in Hoogle instances output (#263) * Output method documentation in Hoogle backend (#259) * Don't print instance safety information in Hoogle (#168) * Expand response files in arguments (#285) * Build the main executable with -threaded (#399) * Use SrcSpan of declarations for inferred type sigs (#207) * Fix cross-module instance locations (#383) * Fix alignment of Source link for instances in Firefox (#384) [1]: https://github.com/haskell/haddock/pull/397 [2]: https://github.com/haskell/haddock/pull/410 -- Mateusz K. From matthewtpickering at gmail.com Wed Jul 22 21:43:13 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 22 Jul 2015 23:43:13 +0200 Subject: [Haskell-cafe] ANN: haddock-2.16.1 In-Reply-To: <55B0086D.8000801@fuuzetsu.co.uk> References: <55B0086D.8000801@fuuzetsu.co.uk> Message-ID: The curious can see an example of this new hyperlinked source here[1]. Great work ?ukasz and Mateusz! [1]: https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk wrote: > Hi, > > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I > inline the changelog at the bottom. It should work fine with 7.10.x GHC > family. The packages are already on Hackage: haddock for the executable, > haddock-api for the guts and use from Haskell and haddock-library which > is the comment parser. > > It should also be shipping with GHC 7.10.2. > > I think two things are worth mentioning before: > > * The pending mathjax PR[1] is going to be included in future release of > Haddock. As it is likely to break the interface file version, I am > putting it off a bit to bundle with other possibly interface-breaking > changes. > > * Our GSOC student has successfully completed first part of his > project[2]. It involves native source code highlighting and perhaps more > excitingly, source hyperlinking: you should now be able to click on > identifiers to be taken to their definitions. This change is not in > 2.16.1 as it is rather recent so we erred on the side of safety when > picking what to release with GHC 7.10.2. You can try it by building > current Haddock master, should work with 7.10.x family. > > As usual, if you want to contribute, please do so on GitHub. We're also > on IRC under #haddock. > > Thanks! > > Changes in version 2.16.1 > > * Don't default to type constructors for out-of-scope names (#253 and > #375) > > * Fix Hoogle display of constructors (#361) > > * Fully qualify names in Hoogle instances output (#263) > > * Output method documentation in Hoogle backend (#259) > > * Don't print instance safety information in Hoogle (#168) > > * Expand response files in arguments (#285) > > * Build the main executable with -threaded (#399) > > * Use SrcSpan of declarations for inferred type sigs (#207) > > * Fix cross-module instance locations (#383) > > * Fix alignment of Source link for instances in Firefox (#384) > > [1]: https://github.com/haskell/haddock/pull/397 > [2]: https://github.com/haskell/haddock/pull/410 > > -- > Mateusz K. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From donn at avvanta.com Thu Jul 23 01:23:52 2015 From: donn at avvanta.com (Donn Cave) Date: Wed, 22 Jul 2015 18:23:52 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55AF8D8F.5000606@nh2.me> References: <55AF8D8F.5000606@nh2.me> Message-ID: <20150723012352.3CBE2276D62@mail.avvanta.com> quoth Niklas_Hamb?chen, >> do that, you set up the conditions for breaking something that >> works in C, which I hate to see happen with Haskell. > > While I understand your opinion here, I'm not sure that "breaking > something that works in C" is the right description. O_CLOEXEC changes a > default setting, but does not irrevocably disable any feature that is > available in C. Sure, it isn't irrevocable - so what's broken may be fixed, if you have access to it, but of course it's better not to break things in the first place. > In other words, CLOEXEC is something that is easy to *undo* locally when > you don't want it, but hard to *do* globally when you need it. Yes, of course, I understand the appeal. But it's a deep change to the way FDs have historically worked that affects widely used UNIX features, and it doesn't solve the problem - sockets, file descriptors created by external libraries or inherited from the parent process, child processes that don't exec - so if you want to relieve a child process of all extraneous open files, you still have to walk the FD table, the sam way it's been done for the last 20 or 30 years. Fork-exec is the relatively unusual event where it makes sense to deal with these issues - including other resources besides FDs as required. Fork-exec outside of GHC should of course continue to work as written. Donn From alexander.kjeldaas at gmail.com Thu Jul 23 06:31:28 2015 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Thu, 23 Jul 2015 08:31:28 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150723012352.3CBE2276D62@mail.avvanta.com> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> Message-ID: On Thu, Jul 23, 2015 at 3:23 AM, Donn Cave wrote: > quoth Niklas_Hamb?chen, > >> do that, you set up the conditions for breaking something that > >> works in C, which I hate to see happen with Haskell. > > > > While I understand your opinion here, I'm not sure that "breaking > > something that works in C" is the right description. O_CLOEXEC changes a > > default setting, but does not irrevocably disable any feature that is > > available in C. > > Sure, it isn't irrevocable - so what's broken may be fixed, if you > have access to it, but of course it's better not to break things > in the first place. > > > In other words, CLOEXEC is something that is easy to *undo* locally when > > you don't want it, but hard to *do* globally when you need it. > > Yes, of course, I understand the appeal. But it's a deep change > to the way FDs have historically worked that affects widely used > UNIX features, and it doesn't solve the problem - sockets, file > descriptors created by external libraries or inherited from the > parent process, child processes that don't exec - so if you want > to relieve a child process of all extraneous open files, you still > have to walk the FD table, the sam way it's been done for the last > 20 or 30 years. Fork-exec is the relatively unusual event where > it makes sense to deal with these issues - including other resources > besides FDs as required. Fork-exec outside of GHC should of course > continue to work as written. > > This history is from before the c10k problem and related file descriptor scaling became relevant. Yes we need to walk the open file descriptors by walking /prod/self/fd and using obscure APIs on OS X. No matter how you see it, it's not what it was 30 years ago. Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Thu Jul 23 15:36:11 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Thu, 23 Jul 2015 17:36:11 +0200 Subject: [Haskell-cafe] Bibliographic references on advantages of functional languages for refactoring In-Reply-To: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> References: <262FDF8F-2A5A-45BD-8DCE-8E95BB3FBAD0@gmail.com> Message-ID: <55B109EB.9070300@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 23/06/15 18:11, Nicola Gigante wrote: > So the question: can you help me find referentiable published work > relative to how strongly-typed functional programming eases > refactoring? My master thesis[0] sort of concluded that refactoring is simpler in haskell than c++. [0] - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVsQnqAAoJENQqWdRUGk8ByXQP/iVxzRpY6RpbeehiG4hTbONw z1XpGjVz2i5xpPc+QrsB9RWw2XO2Ay6mOU2jPK2k+nU9a81d/2VnrdROAOG4ZTfy 2Emt1v7PgugCtyaUoDAoZ4Gff4kTCwoGOBuXJDSaKA1xhIDA15pDlCMTpp76mINC ff7zYVG//SFztetZOo8wawNWOby64X5KlTGj2+daxVIdAFckod6clOZwUt4PjD/Z JRG0sAjCKN/EndDoErLUrW7gH/t7SLYPDlKn9xOPkKQAuoqm3U+gpXOlVbAKQE/v KNlnRf6DKfAqUHmW5Lfk4z1GqaX9I12Ke4jBMI6xXeDaUK0bFNJB50t3PcbLKWtw CrRVgvvIF8Rshq3rO4MgznvI8++kOQOfGNqvcdaijoda+SZOekAH236GXrl4zZ/0 LccChwZeK0jIBbl7SqSlfT4F603s5hyX66WCyYHR2c9aR2C4jlFYJEAs5kwQIV6P r84Oy+35cpqhfW4wS1g0hgNF+UR1zmCrI5xH6mLlXhILDBad+8cho1mkOLgO6gmY IeeOjlEOrCtjQqLze8XjnMxV2YvVmZ0CWRpTTelAxnR4aeClZ9pW9G4R4WniJKSw 3Cmq8RkFSEpDa5DlJWLzRaE84Ba40XpaG5NdYpBBxq0HPUaJa1yAi7ipAta13Ecd MOeCGB4GSV3NjiUgsWZS =9Mwn -----END PGP SIGNATURE----- From donn at avvanta.com Thu Jul 23 16:33:27 2015 From: donn at avvanta.com (Donn Cave) Date: Thu, 23 Jul 2015 09:33:27 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> Message-ID: <20150723163327.4DB07276D63@mail.avvanta.com> Quoth David Turner , ... > Non-inheritable-by-default makes sense to me - if you forget to clear > FD_CLOEXEC when you meant to then your program breaks loudly and obviously; This is where we differ. First, it isn't fair to say we "forget" to clear FD_CLOEXEC, if in pre-existing software we didn't have a CLOEXEC bit to clear. Rather, in the existing set of applications that have an exec - whether in Haskell code or not - we can expect that some subset of them will start to behave differently. Maybe behave better, but in any case likely a surprise to everyone because we've reversed the default on some large subset of file descriptors. And I think it's very optimistic to predict that the breakage will be obvious - the obvious effects will naturally be obvious, but I personally am not up to accounting for all non-obvious cases. And there's the other FDs - inherited, non-Haskell, sockets - so we still need another solution if we're serious about fixing the problem. Donn From agocorona at gmail.com Fri Jul 24 09:03:18 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Fri, 24 Jul 2015 11:03:18 +0200 Subject: [Haskell-cafe] ANN: haddock-2.16.1 In-Reply-To: References: <55B0086D.8000801@fuuzetsu.co.uk> Message-ID: I know for sure that haddock in the future will have live examples in the style of the School of Haskell 2015-07-22 23:43 GMT+02:00 Matthew Pickering : > The curious can see an example of this new hyperlinked source here[1]. > > Great work ?ukasz and Mateusz! > > [1]: > https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html > > On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk > wrote: > > Hi, > > > > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I > > inline the changelog at the bottom. It should work fine with 7.10.x GHC > > family. The packages are already on Hackage: haddock for the executable, > > haddock-api for the guts and use from Haskell and haddock-library which > > is the comment parser. > > > > It should also be shipping with GHC 7.10.2. > > > > I think two things are worth mentioning before: > > > > * The pending mathjax PR[1] is going to be included in future release of > > Haddock. As it is likely to break the interface file version, I am > > putting it off a bit to bundle with other possibly interface-breaking > > changes. > > > > * Our GSOC student has successfully completed first part of his > > project[2]. It involves native source code highlighting and perhaps more > > excitingly, source hyperlinking: you should now be able to click on > > identifiers to be taken to their definitions. This change is not in > > 2.16.1 as it is rather recent so we erred on the side of safety when > > picking what to release with GHC 7.10.2. You can try it by building > > current Haddock master, should work with 7.10.x family. > > > > As usual, if you want to contribute, please do so on GitHub. We're also > > on IRC under #haddock. > > > > Thanks! > > > > Changes in version 2.16.1 > > > > * Don't default to type constructors for out-of-scope names (#253 and > > #375) > > > > * Fix Hoogle display of constructors (#361) > > > > * Fully qualify names in Hoogle instances output (#263) > > > > * Output method documentation in Hoogle backend (#259) > > > > * Don't print instance safety information in Hoogle (#168) > > > > * Expand response files in arguments (#285) > > > > * Build the main executable with -threaded (#399) > > > > * Use SrcSpan of declarations for inferred type sigs (#207) > > > > * Fix cross-module instance locations (#383) > > > > * Fix alignment of Source link for instances in Firefox (#384) > > > > [1]: https://github.com/haskell/haddock/pull/397 > > [2]: https://github.com/haskell/haddock/pull/410 > > > > -- > > Mateusz K. > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.carnecky at gmail.com Fri Jul 24 10:24:04 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Fri, 24 Jul 2015 10:24:04 +0000 Subject: [Haskell-cafe] ANN: haddock-2.16.1 In-Reply-To: References: <55B0086D.8000801@fuuzetsu.co.uk> Message-ID: Will hackage rebuild all existing documentation or only when I upload a new version? If not automatically, can I manually tell hackage to rebuild the docs? On Wed, Jul 22, 2015 at 11:43 PM Matthew Pickering < matthewtpickering at gmail.com> wrote: > The curious can see an example of this new hyperlinked source here[1]. > > Great work ?ukasz and Mateusz! > > [1]: > https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html > > On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk > wrote: > > Hi, > > > > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I > > inline the changelog at the bottom. It should work fine with 7.10.x GHC > > family. The packages are already on Hackage: haddock for the executable, > > haddock-api for the guts and use from Haskell and haddock-library which > > is the comment parser. > > > > It should also be shipping with GHC 7.10.2. > > > > I think two things are worth mentioning before: > > > > * The pending mathjax PR[1] is going to be included in future release of > > Haddock. As it is likely to break the interface file version, I am > > putting it off a bit to bundle with other possibly interface-breaking > > changes. > > > > * Our GSOC student has successfully completed first part of his > > project[2]. It involves native source code highlighting and perhaps more > > excitingly, source hyperlinking: you should now be able to click on > > identifiers to be taken to their definitions. This change is not in > > 2.16.1 as it is rather recent so we erred on the side of safety when > > picking what to release with GHC 7.10.2. You can try it by building > > current Haddock master, should work with 7.10.x family. > > > > As usual, if you want to contribute, please do so on GitHub. We're also > > on IRC under #haddock. > > > > Thanks! > > > > Changes in version 2.16.1 > > > > * Don't default to type constructors for out-of-scope names (#253 and > > #375) > > > > * Fix Hoogle display of constructors (#361) > > > > * Fully qualify names in Hoogle instances output (#263) > > > > * Output method documentation in Hoogle backend (#259) > > > > * Don't print instance safety information in Hoogle (#168) > > > > * Expand response files in arguments (#285) > > > > * Build the main executable with -threaded (#399) > > > > * Use SrcSpan of declarations for inferred type sigs (#207) > > > > * Fix cross-module instance locations (#383) > > > > * Fix alignment of Source link for instances in Firefox (#384) > > > > [1]: https://github.com/haskell/haddock/pull/397 > > [2]: https://github.com/haskell/haddock/pull/410 > > > > -- > > Mateusz K. > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Fri Jul 24 11:23:02 2015 From: lambda.fairy at gmail.com (Chris Wong) Date: Fri, 24 Jul 2015 23:23:02 +1200 Subject: [Haskell-cafe] ANN: haddock-2.16.1 In-Reply-To: References: <55B0086D.8000801@fuuzetsu.co.uk> Message-ID: On Fri, Jul 24, 2015 at 10:24 PM, Tomas Carnecky wrote: > Will hackage rebuild all existing documentation or only when I upload a new > version? IIRC, it will only build a package when its documentation is not present. > If not automatically, can I manually tell hackage to rebuild the > docs? Go to the package page, and click the "edit package information" link at the bottom. There should be an option to clear and rebuild the docs. > > On Wed, Jul 22, 2015 at 11:43 PM Matthew Pickering > wrote: >> >> The curious can see an example of this new hyperlinked source here[1]. >> >> Great work ?ukasz and Mateusz! >> >> [1]: >> https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html >> >> On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk >> wrote: >> > Hi, >> > >> > We're glad to announce Haddock 2.16.1. It is mostly a bugfix release: I >> > inline the changelog at the bottom. It should work fine with 7.10.x GHC >> > family. The packages are already on Hackage: haddock for the executable, >> > haddock-api for the guts and use from Haskell and haddock-library which >> > is the comment parser. >> > >> > It should also be shipping with GHC 7.10.2. >> > >> > I think two things are worth mentioning before: >> > >> > * The pending mathjax PR[1] is going to be included in future release of >> > Haddock. As it is likely to break the interface file version, I am >> > putting it off a bit to bundle with other possibly interface-breaking >> > changes. >> > >> > * Our GSOC student has successfully completed first part of his >> > project[2]. It involves native source code highlighting and perhaps more >> > excitingly, source hyperlinking: you should now be able to click on >> > identifiers to be taken to their definitions. This change is not in >> > 2.16.1 as it is rather recent so we erred on the side of safety when >> > picking what to release with GHC 7.10.2. You can try it by building >> > current Haddock master, should work with 7.10.x family. >> > >> > As usual, if you want to contribute, please do so on GitHub. We're also >> > on IRC under #haddock. >> > >> > Thanks! >> > >> > Changes in version 2.16.1 >> > >> > * Don't default to type constructors for out-of-scope names (#253 and >> > #375) >> > >> > * Fix Hoogle display of constructors (#361) >> > >> > * Fully qualify names in Hoogle instances output (#263) >> > >> > * Output method documentation in Hoogle backend (#259) >> > >> > * Don't print instance safety information in Hoogle (#168) >> > >> > * Expand response files in arguments (#285) >> > >> > * Build the main executable with -threaded (#399) >> > >> > * Use SrcSpan of declarations for inferred type sigs (#207) >> > >> > * Fix cross-module instance locations (#383) >> > >> > * Fix alignment of Source link for instances in Firefox (#384) >> > >> > [1]: https://github.com/haskell/haddock/pull/397 >> > [2]: https://github.com/haskell/haddock/pull/410 >> > >> > -- >> > Mateusz K. >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Chris Wong (https://lambda.xyz) "Humans find such fascinating ways to waste their time." -- Steven Universe From J.Burton at brighton.ac.uk Fri Jul 24 12:22:10 2015 From: J.Burton at brighton.ac.uk (James Burton) Date: Fri, 24 Jul 2015 13:22:10 +0100 Subject: [Haskell-cafe] ANN: haddock-2.16.1 In-Reply-To: References: <55B0086D.8000801@fuuzetsu.co.uk> Message-ID: <55B22DF2.2090706@brighton.ac.uk> On 24/07/15 10:03, Alberto G. Corona wrote: > I know for sure that haddock in the future will have live examples in > the style of the School of Haskell Is it going to send email too? [0] ;-) [0] https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment > > 2015-07-22 23:43 GMT+02:00 Matthew Pickering > >: > > The curious can see an example of this new hyperlinked source here[1]. > > Great work ?ukasz and Mateusz! > > [1]: > https://hackage.haskell.org/package/ghc-exactprint-0.3/docs/src/Language.Haskell.GHC.ExactPrint.html > > On Wed, Jul 22, 2015 at 11:17 PM, Mateusz Kowalczyk > > wrote: > > Hi, > > > > We're glad to announce Haddock 2.16.1. It is mostly a bugfix > release: I > > inline the changelog at the bottom. It should work fine with > 7.10.x GHC > > family. The packages are already on Hackage: haddock for the > executable, > > haddock-api for the guts and use from Haskell and haddock-library > which > > is the comment parser. > > > > It should also be shipping with GHC 7.10.2. > > > > I think two things are worth mentioning before: > > > > * The pending mathjax PR[1] is going to be included in future > release of > > Haddock. As it is likely to break the interface file version, I am > > putting it off a bit to bundle with other possibly interface-breaking > > changes. > > > > * Our GSOC student has successfully completed first part of his > > project[2]. It involves native source code highlighting and > perhaps more > > excitingly, source hyperlinking: you should now be able to click on > > identifiers to be taken to their definitions. This change is not in > > 2.16.1 as it is rather recent so we erred on the side of safety when > > picking what to release with GHC 7.10.2. You can try it by building > > current Haddock master, should work with 7.10.x family. > > > > As usual, if you want to contribute, please do so on GitHub. We're > also > > on IRC under #haddock. > > > > Thanks! > > > > Changes in version 2.16.1 > > > > * Don't default to type constructors for out-of-scope names (#253 and > > #375) > > > > * Fix Hoogle display of constructors (#361) > > > > * Fully qualify names in Hoogle instances output (#263) > > > > * Output method documentation in Hoogle backend (#259) > > > > * Don't print instance safety information in Hoogle (#168) > > > > * Expand response files in arguments (#285) > > > > * Build the main executable with -threaded (#399) > > > > * Use SrcSpan of declarations for inferred type sigs (#207) > > > > * Fix cross-module instance locations (#383) > > > > * Fix alignment of Source link for instances in Firefox (#384) > > > > [1]: https://github.com/haskell/haddock/pull/397 > > [2]: https://github.com/haskell/haddock/pull/410 > > > > -- > > Mateusz K. > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > -- > Alberto. > > ___________________________________________________________ > This email has been scanned by MessageLabs' Email Security > System on behalf of the University of Brighton. > For more information see http://www.brighton.ac.uk/is/spam/ > ___________________________________________________________ > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Dr Jim Burton Senior Lecturer in Computing School of Computing, Engineering and Mathematics University of Brighton ___________________________________________________________ This email has been scanned by MessageLabs' Email Security System on behalf of the University of Brighton. For more information see http://www.brighton.ac.uk/is/spam/ ___________________________________________________________ From donn at avvanta.com Fri Jul 24 19:22:26 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 24 Jul 2015 12:22:26 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> Message-ID: <20150724192226.D2F63276CE1@mail.avvanta.com> Quoth David Turner , > Could you be a bit more specific? Which bits of pre-existing software > didn't have a FD_CLOEXEC bit and would be broken by this proposal? Well, of course to be precise, the bit's always there, it's just normally not set - that's the normal environment that anything written up to now would expect. And of course, anything that depends on a GHC-opened file to stay open over an exec would be broken. I can't enumerate the software that meets that criterion. > Since Python recently decided to go through this exact transition, their > experience should be instructive. Do you know if there was negative fallout > from PEP 0466? I gave up on Python a long time ago and don't follow what goes on. If recently means less than a decade or so, though, it's not much to go on. If the problem addressed by the O_CLOEXEC proposal is obscure, the problems it may create are even more so - I'll certainly concede that - and it could take a lot of experience before those problems would be well known enough to show up if you went looking for them. > When thinking about FDs from outside the Haskell runtime (whether inherited > or simply opened in an external library), can you give an example of a case > where such a FD causes a problem if inherited and yet cannot be set as > FD_CLOEXEC at source? Sorry, I'm confused here. Files opened within GHC and externally have equal potential to work as intended or to cause problems, it seems to me. If we infer from the proposal that GHC-opened files with CLOEXEC unset may cause a problem, then it follows that other files with CLOEXEC unset also may cause the same problem. The proposal addresses only the former, and not the latter, and only for normal files - while the ordinary solution, as implemented in UNIX popen(3), deals with all - pipes, sockets, etc. Donn From alexander.kjeldaas at gmail.com Fri Jul 24 22:29:18 2015 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Sat, 25 Jul 2015 00:29:18 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <55ACF281.6020707@nh2.me> References: <55ACF281.6020707@nh2.me> Message-ID: On Mon, Jul 20, 2015 at 3:07 PM, Niklas Hamb?chen wrote: > Hello Cafe, > > I would like to point out a problem common to all programming languages, > and that Haskell hasn't addressed yet while other languages have. > > It is about what happens to file descriptors when the `exec()` syscall > is used (whenever you `readProcess`, `createProcess`, `system`, use any > form of `popen()`, Shake's `cmd` etc.). > > (A Markdown-rendered version containing most of this email can be found > at https://github.com/ndmitchell/shake/issues/253.) > > Take the following function > > f :: IO () > f = do > inSomeTemporaryDirectory $ do > BS.writeFile "mybinary" binaryContents > setPermissions "mybinary" (setOwnerExecutable True emptyPermissions) > _ <- readProcess "./mybinary" [] "" > return () > > If this is happening in parallel, e.g. using, > > forkIO f >> forkIO f >> forkIO f >> threadDelay 5000000` > > then on Linux the `readProcess` might often fail wit the error message > > mybinary: Text file busy > > This error means "Cannot execute the program 'mybinary' because it is > open for writing by some process". > > How can this happen, given that we're writing all `mybinary` files in > completely separate temporary directories, and given that `BS.writeFile` > guarantees to close the file handle / file descriptor (`Fd`) before it > returns? > > The answer is that by default, child processes on Unix (`fork()+exec()`) > inherit all open file descriptors of the parent process. An ordering > that leads to the problematic case could be: > > * Thread 1 writes its file completely (opens and closes an Fd 1) > * Thread 2 starts writing its file (Fd 2 open for writing) > * Thread 1 executes "myBinary" (which calls `fork()` and `exec()`). Fd 2 > is inherited by the child process > * Thread 2 finishes writing (closes its Fd 2) > * Thread 2 executes "myBinary", which fails with `Text file busy` > because an Fd is still open to it in the child of Process 1 > > I think CLOEXEC should be the default, but it doesn't seem to solve your problem. What if thread 2 executes "myBinary" before thread 1 called exec()? Alexander -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Jul 25 17:24:44 2015 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 25 Jul 2015 19:24:44 +0200 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150724192226.D2F63276CE1@mail.avvanta.com> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> Message-ID: On 07/24/2015 09:22 PM, Donn Cave wrote: > Quoth David Turner , >> Could you be a bit more specific? Which bits of pre-existing software >> didn't have a FD_CLOEXEC bit and would be broken by this proposal? > > Well, of course to be precise, the bit's always there, it's just > normally not set - that's the normal environment that anything > written up to now would expect. And of course, anything that depends > on a GHC-opened file to stay open over an exec would be broken. > I can't enumerate the software that meets that criterion. > >> Since Python recently decided to go through this exact transition, their >> experience should be instructive. Do you know if there was negative fallout >> from PEP 0466? > > I gave up on Python a long time ago and don't follow what goes on. > If recently means less than a decade or so, though, it's not much to > go on. If the problem addressed by the O_CLOEXEC proposal is obscure, > the problems it may create are even more so - I'll certainly concede > that - and it could take a lot of experience before those problems > would be well known enough to show up if you went looking for them. > It seems to me that discovering a "FD-was-unexpectedly-closed-before-it-was-supposed-to" problem is a lot more likely than discovering FD leaks, no? (Not that I'm advocating any particular solution to this -- backward compatibility is a harsh mistress.) Regards, From donn at avvanta.com Sat Jul 25 19:09:11 2015 From: donn at avvanta.com (Donn Cave) Date: Sat, 25 Jul 2015 12:09:11 -0700 (PDT) Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> Message-ID: <20150725190911.ABEFD276CB6@mail.avvanta.com> Quoth Bardur Arantsson , > On 07/24/2015 09:22 PM, Donn Cave wrote: ... >> If recently means less than a decade or so, though, it's not much to >> go on. If the problem addressed by the O_CLOEXEC proposal is obscure, >> the problems it may create are even more so - I'll certainly concede >> that - and it could take a lot of experience before those problems >> would be well known enough to show up if you went looking for them. > > It seems to me that discovering a > "FD-was-unexpectedly-closed-before-it-was-supposed-to" problem is a lot > more likely than discovering FD leaks, no? Maybe ... Note that if it were exactly about FD leaks, that problem would be undiscovered yet. The reason anyone cares is that the leaked file descriptor may go on to inconveniently hold a file open. In what I think is the most common case, the file is a pipe, and the open write end makes a read hang when it should complete. Pipes aren't created by open(2) so won't be part of an O_CLOEXEC solution, but I imagine this is where the issue is usually first encountered, and why popen(3) closes all file descriptors. With disk files ... off the top of my head, the most likely effect might NOT be read/write I/O errors, because here we're talking about passing a file descriptor value through an exec, which I think is an unusual programming practice. It's easy enough to do, e.g. you can format the value into a shell command like "echo whatever >&6", but eccentric. But there are other things that could turn up. For example, you could use flock(2) (Berkeley, not POSIX fcntl lock) to keep an advisory file lock until the exec exits. If the file is closed prematurely, you lose the lock, and ... whatever happens then. Donn From mwm at mired.org Sat Jul 25 19:32:45 2015 From: mwm at mired.org (Mike Meyer) Date: Sat, 25 Jul 2015 19:32:45 +0000 Subject: [Haskell-cafe] Discussion: The CLOEXEC problem In-Reply-To: <20150725190911.ABEFD276CB6@mail.avvanta.com> References: <55AF8D8F.5000606@nh2.me> <20150723012352.3CBE2276D62@mail.avvanta.com> <20150723163327.4DB07276D63@mail.avvanta.com> <20150724192226.D2F63276CE1@mail.avvanta.com> <20150725190911.ABEFD276CB6@mail.avvanta.com> Message-ID: While this discussion has been about the programming errors that result from leaked file descriptors, can I point out what I think is a more important issue? A leaked file descriptor is a potential security hole. If you want your code to be secure - and in this age of internet-based applications built by plugging things together, that should always be the case - you want bugs from not dealing with an access issue to result in a permission denied error, not someone being able to read stuff they shouldn't. So while we can't fix all the holes related to this issue or the larger issues related to forking a threaded program, changing the default to automatically close things will result in improving the security of haskell programs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Sun Jul 26 12:45:05 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Sun, 26 Jul 2015 14:45:05 +0200 Subject: [Haskell-cafe] fun fact: value of truncate -Infinity depends on optimisation level Message-ID: <55B4D651.5030509@htwk-leipzig.de> Just for general amusement - I was debugging very strange behaviour in a straightforward deterministic program, where the output value seemed to depend on ghc's optimization level. Well, it turned out that I (accidentally) computed truncate (logBase 2 0) :: Int, and that's 0 with -O0, but -9223372036854775808 with -O2. https://github.com/jwaldmann/matchbox/issues/19 From chneukirchen at gmail.com Mon Jul 27 09:02:31 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Mon, 27 Jul 2015 11:02:31 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-07-29 @ 19:30 Message-ID: <87mvyikm6w.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 29 at Cafe Puck at 19h30. For details see here: http://www.haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2015/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From matthewtpickering at gmail.com Mon Jul 27 09:13:39 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Mon, 27 Jul 2015 11:13:39 +0200 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: <20150701083154.GB2283@cucumber.anchor.net.au> References: <20150701065452.GA29000@cucumber.anchor.net.au> <20150701083154.GB2283@cucumber.anchor.net.au> Message-ID: Hi Peter, Do you know when you have some time to go through the recently submitted patches? If it's not soon then please could you add myself and Christian to the maintainers so that we can perform some short term maintenance. My immediate plan of action would be 1. Immediately cut a 1.17 release from the master branch as it contains much better parsing of lifted constructors which are becoming more prevalent. 2. Review and merge recent pull requests. 3. Update the parser as far as possible with missing features. 4. Release 1.18 with these improvements within 1 month. Matt On Wed, Jul 1, 2015 at 10:31 AM, Christian Marie wrote: > On Wed, Jul 01, 2015 at 09:33:26AM +0200, Alan & Kim Zimmerman wrote: >> I am starting to wonder if it does not make sense to make a companion >> library for each GHC release with is just the parser/AST, and so can be >> used with any other compiler, even a non-ghc one. > > This would have been my intuition, I suspect it isn't that simple though. > > The duplication of effort does seem odd, and this would solve the problem of > linters and the like always playing catch up. > > This is affecting many users. I, personally, have avoided extensions in the > past when haskell-src-exts threw its toys out of the cot (specifically > LambdaCase, then DataKinds). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From eir at cis.upenn.edu Mon Jul 27 16:18:00 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 27 Jul 2015 12:18:00 -0400 Subject: [Haskell-cafe] Strange "ambiguity" problems thanks to GADTs In-Reply-To: References: <0b14396cadd0495d98362391d1ca0a02@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <677E6BD4-4227-46FD-AA23-4C656E9A629B@cis.upenn.edu> I take back my claim that this is the show/read ambiguity. Alex's recent explanation looks spot on to me. Richard On Jul 22, 2015, at 3:53 AM, Oleg Grenrus wrote: > Nailing down `abt` and `abt?`, but keeping `a` free makes the trick: > > {-# LANGUAGE DataKinds, PolyKinds, GADTs, RankNTypes, ScopedTypeVariables #-} > > data Type = Fun Type Type | Unit > > data Sing :: Type -> * where > SUnit :: Sing Unit > SFun :: Sing i -> Sing j -> Sing (Fun i j) > > data AST :: (Type -> *) -> Type -> * where > TT :: AST ast Unit > App :: ast (Fun a b) -> ast a -> AST ast b > > class ABT (abt :: Type -> *) where > view :: abt a -> AST abt a > unview :: AST abt a -> abt a > > class WellTypedABT (abt :: Type -> *) where > unviewWT :: Sing a -> AST abt a -> abt a > typeOf :: abt a -> Sing a > > type TypeCheckMonad = Maybe > > inferType > :: forall abt abt' a. (ABT abt, WellTypedABT abt') > => abt a > -> TypeCheckMonad (abt' a) > inferType e0 = go e0 > -- b is free, abt and abt' are bounded, class dictionaries come from above. > where go :: forall b. abt b -> TypeCheckMonad (abt' b) > go e0' = case view e0' of > TT -> return . unviewWT SUnit $ TT > App e1 e2 -> do > e1' <- go e1 > case typeOf e1' of > -- -Wall doesn't warn about missing SUnit case here, victory! > SFun _typ2 typ3 -> do > e2' <- inferType e2 > return . unviewWT typ3 $ App e1' e2' > >> On 07 Jul 2015, at 19:05, wren romano wrote: >> >> On Tue, Jul 7, 2015 at 3:35 AM, Simon Peyton Jones >> wrote: >>> If you post a repro case someone (even me) might help. The devil is always in the details. >> >> The smallest repro I can come up with (which is still related to the >> actual problem) is as follows. In case it matters for the solution, >> there are a number of important bits I've erased. Most importantly, >> the inferType function is actually mutually recursive with a checkType >> function, though that doesn't seem to be the cause of the problem. >> >> >> {-# LANGUAGE DataKinds, PolyKinds, GADTs #-} >> >> data Type = Fun Type Type >> >> data Sing :: Type -> * where >> SFun :: Sing i -> Sing j -> Sing (Fun i j) >> >> data AST :: (Type -> *) -> Type -> * where >> App :: ast (Fun a b) -> ast a -> AST ast b >> >> class ABT (abt :: Type -> *) where >> view :: abt a -> AST abt a >> unview :: AST abt a -> abt a >> >> class WellTypedABT (abt :: Type -> *) where >> unviewWT :: Sing a -> AST abt a -> abt a >> typeOf :: abt a -> Sing a >> >> data TypeCheckMonad a = TCM { unTCM :: a } >> >> instance Functor TypeCheckMonad where >> fmap f = TCM . f . unTCM >> >> instance Applicative TypeCheckMonad where >> pure = TCM >> TCM f <*> TCM x = TCM (f x) >> >> instance Monad TypeCheckMonad where >> return = pure >> TCM x >>= k = k x >> >> inferType >> :: (ABT abt, WellTypedABT abt') >> => abt a >> -> TypeCheckMonad (abt' a) >> inferType e0 = >> case view e0 of >> App e1 e2 -> do >> e1' <- inferType e1 >> case typeOf e1' of >> SFun typ2 typ3 -> do >> e2' <- inferType e2 >> return . unviewWT typ3 $ App e1' e2' >> -- >> Live well, >> ~wren >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mwm at mired.org Mon Jul 27 20:25:44 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 27 Jul 2015 20:25:44 +0000 Subject: [Haskell-cafe] Names in a record changes read behavior? Message-ID: Ok, this all works as expected: ?> data Point = Point Float Float deriving (Show, Read) ?> Point 1.0 1.0 Point 1.0 1.0 ?> read "Point 1.0 1.0" *** Exception: Prelude.read: no parse ?> read "Point 1.0 1.0" :: Point Point 1.0 1.0 But now we add names to the values in the Point, and things change: ?> data Point = Point {x :: Float, y :: Float } deriving (Show, Read) ?> Point 1.0 1.0 Point {x = 1.0, y = 1.0} ?> read "Point 1.0 1.0" *** Exception: Prelude.read: no parse ?> read "Point 1.0 1.0" :: Point *** Exception: Prelude.read: no parse ?> read "Point {x = 1.0, y = 1.0 }" :: Point Point {x = 1.0, y = 1.0} OK, why won't read accept the same syntax as the REPL? I can see wanting Read and Show to be inverses of each other, though I think it's a bit misguided. But if we're going to be that strict about them being inverses, shouldn't we also insist that the READ eval print loop only accept what read will accept? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jul 27 20:56:29 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 27 Jul 2015 16:56:29 -0400 Subject: [Haskell-cafe] Names in a record changes read behavior? In-Reply-To: References: Message-ID: On Mon, Jul 27, 2015 at 4:25 PM, Mike Meyer wrote: > OK, why won't read accept the same syntax as the REPL? I can see wanting > Read and Show to be inverses of each other, though I think it's a bit > misguided. But if we're going to be that strict about them being inverses, > shouldn't we also insist that the READ eval print loop only accept what > read will accept? Partly because ReadS isn't a very good parser, partly because of compliance with https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600011.4; notably: - If the constructor is defined using record syntax, the derived Read will parse only the record-syntax form, and furthermore, the fields must be given in the same order as the original declaration. -- 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 mwm at mired.org Mon Jul 27 21:01:44 2015 From: mwm at mired.org (Mike Meyer) Date: Mon, 27 Jul 2015 21:01:44 +0000 Subject: [Haskell-cafe] Names in a record changes read behavior? In-Reply-To: References: Message-ID: On Mon, Jul 27, 2015, 15:56 Brandon Allbery wrote: On Mon, Jul 27, 2015 at 4:25 PM, Mike Meyer wrote: OK, why won't read accept the same syntax as the REPL? I can see wanting Read and Show to be inverses of each other, though I think it's a bit misguided. But if we're going to be that strict about them being inverses, shouldn't we also insist that the READ eval print loop only accept what read will accept? Partly because ReadS isn't a very good parser, partly because of compliance with https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600011.4; notably:If the constructor is defined using record syntax, the derived Read will parse only the record-syntax form, and furthermore, the fields must be given in the same order as the original declaration. So why does the REPL read not follow those rules? And is there some way to use whatever the REPL is using as the read instance in my code? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jul 27 21:05:53 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 27 Jul 2015 17:05:53 -0400 Subject: [Haskell-cafe] Names in a record changes read behavior? In-Reply-To: References: Message-ID: On Mon, Jul 27, 2015 at 5:01 PM, Mike Meyer wrote: > > On Mon, Jul 27, 2015, 15:56 Brandon Allbery wrote: > > On Mon, Jul 27, 2015 at 4:25 PM, Mike Meyer wrote:= > > OK, why won't read accept the same syntax as the REPL? I can see wanting > Read and Show to be inverses of each other, though I think it's a bit > misguided. But if we're going to be that strict about them being inverses, > shouldn't we also insist that the READ eval print loop only accept what > read will accept? > > > Partly because ReadS isn't a very good parser, partly because of > compliance with > https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600011.4; > notably:If the constructor is defined using record syntax, the > derived Read will parse only the record-syntax form, and furthermore, the > fields must be given in the same order as the original declaration. > > So why does the REPL read not follow those rules? And is there some way to > use whatever the REPL is using as the read instance in my code? > The REPL is ghc itself, not a Read instance. You almost certainly do not want to have all of ghc linked into your program just to use its parser and bytecode interpreter as a read alternative --- especially since that would be an *independent* environment and cannot see any types you defined in your program unless you also compile your program into that instance of ghc, at runtime. -- 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 dagitj at gmail.com Mon Jul 27 22:27:28 2015 From: dagitj at gmail.com (Jason Dagit) Date: Mon, 27 Jul 2015 15:27:28 -0700 Subject: [Haskell-cafe] Names in a record changes read behavior? In-Reply-To: References: Message-ID: On Mon, Jul 27, 2015 at 1:25 PM, Mike Meyer wrote: > Ok, this all works as expected: > > ?> data Point = Point Float Float deriving (Show, Read) > ?> Point 1.0 1.0 > Point 1.0 1.0 > ?> read "Point 1.0 1.0" > *** Exception: Prelude.read: no parse > ?> read "Point 1.0 1.0" :: Point > Point 1.0 1.0 > > But now we add names to the values in the Point, and things change: > > ?> data Point = Point {x :: Float, y :: Float } deriving (Show, Read) > ?> Point 1.0 1.0 > Point {x = 1.0, y = 1.0} > This works because the type of Point is Point :: Float -> Float -> Point. You could have equally written: > let foo = Point > foo 1.0 1.0 The parser at the REPL is looking for arbitrary Haskell expressions, and "Point 1.0 1.0" just happens to be a function application expression. I hope that helps, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndmitchell at gmail.com Tue Jul 28 15:49:59 2015 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue, 28 Jul 2015 16:49:59 +0100 Subject: [Haskell-cafe] haskell-src-exts maintenance In-Reply-To: References: <20150701065452.GA29000@cucumber.anchor.net.au> <20150701083154.GB2283@cucumber.anchor.net.au> Message-ID: As a very heavy HSE user (HLint and Hoogle), who has had a reasonably close working relationship with all of Niklas (my SoC mentor and my SoC mentee), Roman and Peter (a fellow supercompiler developer) and Matt (currently hacking on HLint), I thought I should weigh in. The current state of HSE is a little forlorn - there are 22 open pull requests, everything from reducing algorithm complexity (an accidental n^3), fixing the default encoding (should be UTF8) and lots of actual parser fixes. A lot of this is good stuff, and the high level of external contributions is a really good sign. But they need to be merged and reviewed, and it seems the bandwidth just isn't there at the moment. Given Matt's comments on the existing tickets, and the triage he's already performing on the repo, I have high hopes that Matt could provide a bit more of the time and attention. Peter, perhaps a co-maintainer would be good for a little while? > If it's not soon then please could you add myself and Christian to the > maintainers so that we can perform some short term maintenance. My > immediate plan of action would be > > 1. Immediately cut a 1.17 release from the master branch as it > contains much better parsing of lifted constructors which are becoming > more prevalent. > 2. Review and merge recent pull requests. > 3. Update the parser as far as possible with missing features. > 4. Release 1.18 with these improvements within 1 month. Awesome! Although as a preference I'd go for as much of 2 as you can in a couple of days before doing 1 - a lot of the patches are simple and valuable, and a 2 day wait isn't going to be too problematic. Thanks, Neil From marcin.jan.mrotek at gmail.com Wed Jul 29 08:58:39 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 29 Jul 2015 10:58:39 +0200 Subject: [Haskell-cafe] ANN: hsqml-datamodel(-vinyl) = data model for QML Message-ID: Hello, I've just uploaded a package that enables using Haskell records in QML table- or listviews: http://hackage.haskell.org/package/hsqml-datamodel There's also an implementation for Vinyl: http://hackage.haskell.org/package/hsqml-datamodel-vinyl Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Wed Jul 29 09:48:48 2015 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Wed, 29 Jul 2015 09:48:48 +0000 Subject: [Haskell-cafe] ANN: hsqml-datamodel(-vinyl) = data model for QML In-Reply-To: References: Message-ID: Very cool! I'm currently on vacation, but I'll take a look when I'm back (and hopefully release reflex-qml then). Marcin Mrotek schrieb am Mi., 29. Juli 2015 10:58: > Hello, > > I've just uploaded a package that enables using Haskell records in QML > table- or listviews: http://hackage.haskell.org/package/hsqml-datamodel > > There's also an implementation for Vinyl: > http://hackage.haskell.org/package/hsqml-datamodel-vinyl > > Best regards, > Marcin Mrotek > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Jul 29 15:26:58 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 29 Jul 2015 17:26:58 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 Message-ID: <8761533ry5.fsf@smart-cactus.org> ===================================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 ===================================================================== The GHC Team is pleased to announce a new bug-fix release of GHC, 7.10.2. There have been a number of significant bug fixes since the 7.10.1 (with over 70 defects fixed). These include fixes affecting type-checker correctness, runtime stability, and compiler performance. For this reason we highly recommend that users of 7.10.1 upgrade quickly. Note that due to changes made in this release to GHC's optimizer, previously fragile-but-working rewrite rules may fail to fire. One example of this was found in the widely-used `text` package late in the release cycle, which manifested in long compilation times and poor code generation for `Text` literals (see [Trac #10528]). Users are advised to use text >=1.2.1.2 which includes more robust rewrite rules. The full release notes including a complete listing of the changes in this release can be found here, https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html [Trac #10528]: https://ghc.haskell.org/trac/ghc/ticket/10528 How to get it ~~~~~~~~~~~~~ Both binary and source tarballs of GHC itself are available on the release download page, https://www.haskell.org/ghc/download_ghc_7_10_2 For a more smoother, better integrated experience users are encouraged to find a Haskell distribution. While these alternatives may not yet include 7.10.2, they offer tools and libraries to quickly get users up and running, as well as potentially better integration with the host operating system and package manager. See, https://www.haskell.org/downloads for more details. 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 good 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 (C, whatever). 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), https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms supported by GHC and the people responsible for them can be found here, https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ If you enjoy using GHC, you will likely also enjoy contributing to it! We are always looking for new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC developer site, https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ In https://downloads.haskell.org/~ghc/7.10.2/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key, Benjamin Gamari Fingerprint: FFEB 7CE8 1E16 A36B 3E2D ED6F 2DE0 4D4E 97DB 64AD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From merijn at inconsistent.nl Wed Jul 29 15:43:23 2015 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Wed, 29 Jul 2015 17:43:23 +0200 Subject: [Haskell-cafe] Annotated ASTs, and the tension between Bound, Free, and Cofree... Message-ID: Hi, So I'm playing around with using bound to define a simple AST using the bound library to deal with substitution/abstraction. Being a lazy haskeller I figured that ASTs map nicely onto Free and that I could get all the necessary Applicative, Monad, etc. instances for free by using something like: newtype Expr a = Expr { unExpr :: Free (ExprF Expr) a } deriving (Functor,Applicative,Monad,Foldable,Traversable) data ExprF f a = App (f a) (f a) | Lam Type (Scope () f a) | TmTrue | TmFalse | If (f a) (f a) (f a) deriving (Eq,Ord,Show,Read,Functor,Foldable,Traversable) Now, for an AST to be useful, it has to be annotated with things like source location, type info, etc. So I started looking into how to accomplish this in a way where it's easy to add/modify annotations on any node of the AST. My initial idea was to use FreeT with ((,) a) as a base monad for annotations, but I quickly realised this fails, because "((,) a)" is only a Monad if 'a' is a Monoid and there's no sensible Monoid for type information/source locations. Then I looked around more and realised that this actually sounds a lot like Cofree. But here's where I run into problems. Bound expects the type of variables to be in the functor position of my Expr type, whereas Cofree expects the type of *annotations* to be in the functor position. So I can't figure out an elegant way to both use bound to deal with substitution for me *and* use Cofree to deal with annotations, since there's no way to make the types line up sanely. So my question boils down too: Has anyone done all the hard work for me already? i.e. how can I have an annotated AST with substitution *and* an easy way to modify the annotations, without writing a ton of boiler plate to deal with substitution and/or annotations? Cheers, Merijn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From alan.zimm at gmail.com Wed Jul 29 15:46:06 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 29 Jul 2015 17:46:06 +0200 Subject: [Haskell-cafe] Annotated ASTs, and the tension between Bound, Free, and Cofree... In-Reply-To: References: Message-ID: Have you looked at this? https://hackage.haskell.org/package/Annotations Alan On Wed, Jul 29, 2015 at 5:43 PM, Merijn Verstraaten wrote: > Hi, > > So I'm playing around with using bound to define a simple AST using the > bound library to deal with substitution/abstraction. > > Being a lazy haskeller I figured that ASTs map nicely onto Free and that I > could get all the necessary Applicative, Monad, etc. instances for free by > using something like: > > newtype Expr a = Expr { unExpr :: Free (ExprF Expr) a } > deriving (Functor,Applicative,Monad,Foldable,Traversable) > > data ExprF f a > = App (f a) (f a) > | Lam Type (Scope () f a) > | TmTrue > | TmFalse > | If (f a) (f a) (f a) > deriving (Eq,Ord,Show,Read,Functor,Foldable,Traversable) > > Now, for an AST to be useful, it has to be annotated with things like > source location, type info, etc. So I started looking into how to > accomplish this in a way where it's easy to add/modify annotations on any > node of the AST. > > My initial idea was to use FreeT with ((,) a) as a base monad for > annotations, but I quickly realised this fails, because "((,) a)" is only a > Monad if 'a' is a Monoid and there's no sensible Monoid for type > information/source locations. > > Then I looked around more and realised that this actually sounds a lot > like Cofree. But here's where I run into problems. Bound expects the type > of variables to be in the functor position of my Expr type, whereas Cofree > expects the type of *annotations* to be in the functor position. > > So I can't figure out an elegant way to both use bound to deal with > substitution for me *and* use Cofree to deal with annotations, since > there's no way to make the types line up sanely. > > So my question boils down too: Has anyone done all the hard work for me > already? i.e. how can I have an annotated AST with substitution *and* an > easy way to modify the annotations, without writing a ton of boiler plate > to deal with substitution and/or annotations? > > Cheers, > Merijn > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asr at eafit.edu.co Wed Jul 29 15:53:29 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 29 Jul 2015 10:53:29 -0500 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: Hi, On 29 July 2015 at 10:26, Ben Gamari wrote: > The GHC Team is pleased to announce a new bug-fix release of GHC, > 7.10.2. Thanks for the release! FYI, there are various missing *.tar.xz files in the SHA256SUMS file in http://downloads.haskell.org/~ghc/7.10.2/ Best regards, -- Andr?s From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Jul 29 15:56:19 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 29 Jul 2015 16:56:19 +0100 Subject: [Haskell-cafe] Annotated ASTs, and the tension between Bound, Free, and Cofree... In-Reply-To: References: Message-ID: <20150729155618.GD3872@weber> On Wed, Jul 29, 2015 at 05:43:23PM +0200, Merijn Verstraaten wrote: > newtype Expr a = Expr { unExpr :: Free (ExprF Expr) a } > deriving (Functor,Applicative,Monad,Foldable,Traversable) > > data ExprF f a > = App (f a) (f a) > | Lam Type (Scope () f a) > | TmTrue > | TmFalse > | If (f a) (f a) (f a) > deriving (Eq,Ord,Show,Read,Functor,Foldable,Traversable) > > Now, for an AST to be useful, it has to be annotated with things like > source location, type info, etc. So I started looking into how to > accomplish this in a way where it's easy to add/modify annotations on any > node of the AST. If you want *some* subterms to be annotated, can you just add another constructor to ExprF? | Annotation annotationType (f a) Or if you want *every* subterm annotated then how about newtype Expr f a = Expr { unExpr :: Free (ExprF (Compose f Expr)) a } From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Jul 29 16:01:16 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 29 Jul 2015 17:01:16 +0100 Subject: [Haskell-cafe] Annotated ASTs, and the tension between Bound, Free, and Cofree... In-Reply-To: References: Message-ID: <20150729160116.GE3872@weber> On Wed, Jul 29, 2015 at 05:43:23PM +0200, Merijn Verstraaten wrote: > Being a lazy haskeller I figured that ASTs map nicely onto Free and that I > could get all the necessary Applicative, Monad, etc. instances for free > by using something like: > > newtype Expr a = Expr { unExpr :: Free (ExprF Expr) a } > deriving (Functor,Applicative,Monad,Foldable,Traversable) > > data ExprF f a > = App (f a) (f a) > | Lam Type (Scope () f a) > | TmTrue > | TmFalse > | If (f a) (f a) (f a) > deriving (Eq,Ord,Show,Read,Functor,Foldable,Traversable) By the way, when I was playing around with bound and free I guessed that it would be more appropriate to define a "higher order" free thing which is called Mu here: Was bound but now I'm free: http://lpaste.net/136836 I'd be grateful if you'd take a look and see if you think it has any benefit over just using Free. Tom From ben at well-typed.com Wed Jul 29 16:28:52 2015 From: ben at well-typed.com (Ben Gamari) Date: Wed, 29 Jul 2015 18:28:52 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <87vbd32aij.fsf@smart-cactus.org> Andr?s Sicard-Ram?rez writes: > Hi, > > On 29 July 2015 at 10:26, Ben Gamari wrote: >> The GHC Team is pleased to announce a new bug-fix release of GHC, >> 7.10.2. > > Thanks for the release! > > FYI, there are various missing *.tar.xz files in the SHA256SUMS file in > > http://downloads.haskell.org/~ghc/7.10.2/ > I suspect this may be due to the (Content Delivery Network (CDN) caches being stale. Unfortunately this seems to be a persistent issue. You can likely fool the CDN by inserting superfluous / characters in the URL (thanks to Herbert for the tip). For instance, http://downloads.haskell.org/~ghc/7.10.2///SHA256SUMS Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From asr at eafit.edu.co Wed Jul 29 18:15:56 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 29 Jul 2015 13:15:56 -0500 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <87vbd32aij.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> <87vbd32aij.fsf@smart-cactus.org> Message-ID: On 29 July 2015 at 11:28, Ben Gamari wrote: >> FYI, there are various missing *.tar.xz files in the SHA256SUMS file in >> >> http://downloads.haskell.org/~ghc/7.10.2/ >> > I suspect this may be due to the (Content Delivery Network (CDN) caches > being stale. Unfortunately this seems to be a persistent issue. You can > likely fool the CDN by inserting superfluous / characters in the URL > (thanks to Herbert for the tip). For instance, > > http://downloads.haskell.org/~ghc/7.10.2///SHA256SUMS This fixed the issue. Thanks! -- Andr?s From manny at fpcomplete.com Wed Jul 29 23:09:03 2015 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Wed, 29 Jul 2015 16:09:03 -0700 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: I?m getting 403 Forbidden errors on the freebsd binaries: $ curl -sSL http://downloads.haskell.org/~ghc/7.10.2/ghc-7.10.2-i386-portbld-freebsd.tar.xz 403 Forbidden

403 Forbidden


nginx/1.6.2
$ curl -sSL http://downloads.haskell.org/~ghc/7.10.2/ghc-7.10.2-x86_64-portbld-freebsd.tar.xz 403 Forbidden

403 Forbidden


nginx/1.6.2
? -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.dead.shall.rise at gmail.com Thu Jul 30 07:11:07 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Thu, 30 Jul 2015 09:11:07 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: Hi, On 29 July 2015 at 17:26, Ben Gamari wrote: > [...] > The full release notes including a complete listing of the changes in > this release can be found here, > > https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html This gives me error 404. From ben at well-typed.com Thu Jul 30 08:18:29 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 10:18:29 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <87lhdy2h4a.fsf@smart-cactus.org> Mikhail Glushenkov writes: > Hi, > > On 29 July 2015 at 17:26, Ben Gamari wrote: >> [...] >> The full release notes including a complete listing of the changes in >> this release can be found here, >> >> https://downloads.haskell.org/~ghc/7.10.2/docs/html/users_guide/release-7-10-2.html > > This gives me error 404. > I'm not sure what else to say other than to suggest adding superfluous `/` characters to the URL as mentioned previously. The document is there, the CDN just still hasn't realized it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From mc.schroeder at gmail.com Thu Jul 30 11:11:15 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Thu, 30 Jul 2015 13:11:15 +0200 Subject: [Haskell-cafe] STM Finalizers Message-ID: Hi everyone, I want to finally announce some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function atomicallyWithIO :: STM a -> (a -> IO b) -> IO b Like the existing atomically operation, atomicallyWithIO performs an STM computation. Additionally, it takes a *finalizer*, which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that: 1. The finalizer is only performed if the STM transaction is guaranteed to commit. 2. The STM transaction only commits if the finalizer finishes without raising an exception. A motivation of why this is useful: Say we want to save the results of some STM transaction, i.e. persist them to disk. Currently, this is not possible in a transactionally safe way. The naive approach would be to first atomically perform some STM computation and then independently serialise its result: do x <- atomically m serialize x There are two issues with this. First, another thread could perform a second transaction and serialise it before we have finished serialising ours, which could result in an inconsistent state between the memory of our program and what is stored on disk. Secondly, the function serialize might not terminate at all; it could throw an exception or its thread could die. Again we would end up with an inconsistent state and possibly data loss. We might try to simply move serialisation into the atomic block, but to do this we have to circumvent the types, which should already be a huge red flag: atomically $ do x <- m unsafeIOToSTM (serialize x) The problem here is of course that an STM transaction can retry many times, which will also result in serialize being executed many times, which is probably not something we want. Furthermore, if the thread receives an asynchronous exception, the transaction will abort in an orderly fashion, while serialize, with its irrevocable side effects, cannot be undone. But with finalizers, the solution is easy: atomicallyWithIO m serialize I've written a small example application that uses finalizers and other stuff from my thesis to build a lightweight STM database framework: [2] There are more possible uses cases besides serialisation (such as interactive transactions) and some interesting issues surrounding finalizers (like nesting of transactions) which are discussed in greater detail in my thesis [1], which also includes a formal operational semantics of the whole thing. I have implemented finalizers in my fork of GHC [3], if any of you want to play around with them yourself. The atomicallyWithIO function is exported from the GHC.Conc.Sync module. Cheers, Michael [1] https://github.com/mcschroeder/thesis [2] https://github.com/mcschroeder/social-example [3] https://github.com/mcschroeder/ghc -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Jul 30 11:20:25 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 30 Jul 2015 14:20:25 +0300 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: <55BA0879.1070801@ro-che.info> Michael, This looks awesome! Will you try to merge your work into ghc? I look forward to reading your thesis. On 30/07/15 14:11, Michael Schr?der wrote: > Hi everyone, > > I want to finally announce some work I did as part of my master's thesis > [1]. It's an extension to GHC's STM implementation. The main idea is to > introduce a new primitive function > > atomicallyWithIO :: STM a -> (a -> IO b) -> IO b > > Like the existing atomically operation, atomicallyWithIO performs an STM > computation. Additionally, it takes a *finalizer*, which is an arbitrary > I/O action that can depend on the result of the STM computation, and > combines it with the transaction in such a way that: > > 1. The finalizer is only performed if the STM transaction is guaranteed > to commit. > 2. The STM transaction only commits if the finalizer finishes without > raising an exception. > > > > A motivation of why this is useful: > > Say we want to save the results of some STM transaction, i.e. persist > them to disk. Currently, this is not possible in a transactionally safe > way. The naive approach would be to first atomically perform some STM > computation and then independently serialise its result: > > do > x <- atomically m > serialize x > > There are two issues with this. First, another thread could perform a > second transaction and serialise it before we have finished serialising > ours, which could result in an inconsistent state between the memory of > our program and what is stored on disk. Secondly, the function serialize > might not terminate at all; it could throw an exception or its thread > could die. Again we would end up with an inconsistent state and possibly > data loss. > > We might try to simply move serialisation into the atomic block, but to > do this we have to circumvent the types, which should already be a huge > red flag: > > atomically $ do > x <- m > unsafeIOToSTM (serialize x) > > The problem here is of course that an STM transaction can retry many > times, which will also result in serialize being executed many times, > which is probably not something we want. Furthermore, if the thread > receives an asynchronous exception, the transaction will abort in an > orderly fashion, while serialize, with its irrevocable side effects, > cannot be undone. > > But with finalizers, the solution is easy: > > atomicallyWithIO m serialize > > > I've written a small example application that uses finalizers and other > stuff from my thesis to build a lightweight STM database framework: [2] > > There are more possible uses cases besides serialisation (such as > interactive transactions) and some interesting issues surrounding > finalizers (like nesting of transactions) which are discussed in greater > detail in my thesis [1], which also includes a formal operational > semantics of the whole thing. > > I have implemented finalizers in my fork of GHC [3], if any of you want > to play around with them yourself. The atomicallyWithIO function is > exported from the GHC.Conc.Sync module. > > > Cheers, > Michael > > > [1] https://github.com/mcschroeder/thesis > [2] https://github.com/mcschroeder/social-example > [3] https://github.com/mcschroeder/ghc > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- 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 Thu Jul 30 12:07:07 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 14:07:07 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <8761533ry5.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> Message-ID: <877fph3l3o.fsf@smart-cactus.org> Hello again! See below for an important announcement regarding the `text` issue described earlier. Ben Gamari writes: > ===================================================================== > The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 > ===================================================================== > > The GHC Team is pleased to announce a new bug-fix release of GHC, > 7.10.2. > > There have been a number of significant bug fixes since the 7.10.1 (with > over 70 defects fixed). These include fixes affecting type-checker > correctness, runtime stability, and compiler performance. For this > reason we highly recommend that users of 7.10.1 upgrade quickly. > > Note that due to changes made in this release to GHC's optimizer, > previously fragile-but-working rewrite rules may fail to fire. One > example of this was found in the widely-used `text` package late in the > release cycle, which manifested in long compilation times and poor code > generation for `Text` literals (see [Trac #10528]). Users are advised to > use text >=1.2.1.2 which includes more robust rewrite rules. > It has been brought to my attention that the fix included in text-1.2.1.2 does not in fact fix the rule issues triggered by GHC 7.10.2 (see the later comments on #10528 for details). I have pushed text-1.2.1.3 to Hackage which finally resolves this issue. Users of GHC 7.10.2 should upgrade to text >=1.2.1.3 at their earliest convenience. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From gombocarti at gmail.com Thu Jul 30 13:50:06 2015 From: gombocarti at gmail.com (=?ISO-8859-2?Q?Po=F3r_Art=FAr?=) Date: Thu, 30 Jul 2015 15:50:06 +0200 Subject: [Haskell-cafe] Taking over package erlang Message-ID: <55BA2B8E.20301@gmail.com> Hi, The package erlang (https://hackage.haskell.org/package/erlang) wasn't updated since 2008, and it became fairly outdated since then. The author was contacted half a year ago, but he didn't respond. So following the instructions on Hackage I state my intention to take over. I have made the package functional again, and I would like to make it available on Hackage. Art?r From silvio.frischi at gmail.com Thu Jul 30 15:00:54 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 30 Jul 2015 17:00:54 +0200 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types Message-ID: <55BA3C26.5010105@gmail.com> Protuct types have this nice tuple syntax (a,Char,Int),(a,'c',1). Why is there no syntax like this for Sum types (a|Char|Int),(||1). This would be very usefull for some more explicit error handling. I.E. You have a library that has errors. Error1, .. ErrorN. Currently there are only two ways of making a function that can throw Error3 and Error8. Use 'Dynamic' typed Exceptions or make a general Error type that is the sum of all Errors. In both cases it is not clear from the type of the function what Errors can occur. With sumTuples you could just return (Result|Error3|Error8). Also, I guess I'm just one of those people who occasionally confuse Left and Right :) Silvio Frischknecht From mc.schroeder at gmail.com Thu Jul 30 15:14:59 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Thu, 30 Jul 2015 17:14:59 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: <55BA0879.1070801@ro-che.info> References: <55BA0879.1070801@ro-che.info> Message-ID: > > This looks awesome! Will you try to merge your work into ghc? > Thanks! Yes, I'd love to get this into GHC, assuming enough people are interested. I guess the next step would be to submit a patch to Phabricator? -------------- next part -------------- An HTML attachment was scrubbed... URL: From strake888 at gmail.com Thu Jul 30 15:31:42 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Thu, 30 Jul 2015 07:31:42 -0800 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: <55BA3C26.5010105@gmail.com> References: <55BA3C26.5010105@gmail.com> Message-ID: <55ba3ff1.e201460a.47a3c.5fd5@mx.google.com> On 30/07/2015 at 17:00:54 +0200, Silvio Frischknecht wrote: > You have a library that has errors. > > Error1, .. ErrorN. > > Currently there are only two ways of making a function that can throw > Error3 and Error8. > > Use 'Dynamic' typed Exceptions or make a general Error type that is the > sum of all Errors. In both cases it is not clear from the type of the > function what Errors can occur. > > With sumTuples you could just return (Result|Error3|Error8). I doubt whether this would work so well for errors, as I think we would want to be able to combine the values of fallible terms such as to combine the possible errors associatively and commutatively, and these sum tuples would not. The non-associativity of product tuples sometimes bites me already in other use cases. That said, I sometimes thought this myself, tho with other syntax: (a;b;c) From strake888 at gmail.com Thu Jul 30 15:35:45 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Thu, 30 Jul 2015 07:35:45 -0800 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: <55ba40e4.6a32460a.386d.6769@mx.google.com> On 30/07/2015 at 13:11:15 +0200, Michael Schr?der wrote: > atomicallyWithIO :: STM a -> (a -> IO b) -> IO b Shiny! On 30/07/2015 at 17:14:59 +0200, Michael Schr?der wrote: > assuming enough people are interested. Not sure how many is enough, but count me interested ? From silvio.frischi at gmail.com Thu Jul 30 15:35:21 2015 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Thu, 30 Jul 2015 17:35:21 +0200 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: <55ba3ff1.e201460a.47a3c.5fd5@mx.google.com> References: <55BA3C26.5010105@gmail.com> <55ba3ff1.e201460a.47a3c.5fd5@mx.google.com> Message-ID: <55BA4439.7070507@gmail.com> > I doubt whether this would work so well for errors, as I think we > would want to be able to combine the values of fallible terms such as > to combine the possible errors associatively and commutatively, and > these sum tuples would not. The non-associativity of product tuples > sometimes bites me already in other use cases. Yeah I agree tuples are not very nice to work with because you can't recurse over them. I guess it would be cool to have them internally represented similar to this. http://stackoverflow.com/a/25609890/1117884 But even without this, tuples are useful and I think sum tuples would be similarly useful. Doing things explicitly/manually is not always a bad thing. Silvio From marcin.jan.mrotek at gmail.com Thu Jul 30 15:42:16 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Thu, 30 Jul 2015 17:42:16 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: <55ba40e4.6a32460a.386d.6769@mx.google.com> References: <55ba40e4.6a32460a.386d.6769@mx.google.com> Message-ID: > assuming enough people are interested. +1 from me, then. Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From midfield at gmail.com Thu Jul 30 16:24:55 2015 From: midfield at gmail.com (Ben) Date: Thu, 30 Jul 2015 09:24:55 -0700 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: what happens if an exception is thrown? what are the retry semantics? is there a at-most-once guarantees for the IO action? best regards, b > On Jul 30, 2015, at 4:11 AM, Michael Schr?der wrote: > > Hi everyone, > > I want to finally announce some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function > > atomicallyWithIO :: STM a -> (a -> IO b) -> IO b > > Like the existing atomically operation, atomicallyWithIO performs an STM computation. Additionally, it takes a finalizer, which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that: > ? The finalizer is only performed if the STM transaction is guaranteed to commit. > ? The STM transaction only commits if the finalizer finishes without raising an exception. > > > A motivation of why this is useful: > > Say we want to save the results of some STM transaction, i.e. persist them to disk. Currently, this is not possible in a transactionally safe way. The naive approach would be to first atomically perform some STM computation and then independently serialise its result: > > do > x <- atomically m > serialize x > > There are two issues with this. First, another thread could perform a second transaction and serialise it before we have finished serialising ours, which could result in an inconsistent state between the memory of our program and what is stored on disk. Secondly, the function serialize might not terminate at all; it could throw an exception or its thread could die. Again we would end up with an inconsistent state and possibly data loss. > > We might try to simply move serialisation into the atomic block, but to do this we have to circumvent the types, which should already be a huge red flag: > > atomically $ do > x <- m > unsafeIOToSTM (serialize x) > > The problem here is of course that an STM transaction can retry many times, which will also result in serialize being executed many times, which is probably not something we want. Furthermore, if the thread receives an asynchronous exception, the transaction will abort in an orderly fashion, while serialize, with its irrevocable side effects, cannot be undone. > > But with finalizers, the solution is easy: > > atomicallyWithIO m serialize > > > I've written a small example application that uses finalizers and other stuff from my thesis to build a lightweight STM database framework: [2] > > There are more possible uses cases besides serialisation (such as interactive transactions) and some interesting issues surrounding finalizers (like nesting of transactions) which are discussed in greater detail in my thesis [1], which also includes a formal operational semantics of the whole thing. > > I have implemented finalizers in my fork of GHC [3], if any of you want to play around with them yourself. The atomicallyWithIO function is exported from the GHC.Conc.Sync module. > > > Cheers, > Michael > > > [1] https://github.com/mcschroeder/thesis > [2] https://github.com/mcschroeder/social-example > [3] https://github.com/mcschroeder/ghc > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From jmartin at eecs.berkeley.edu Thu Jul 30 16:52:16 2015 From: jmartin at eecs.berkeley.edu (James M) Date: Thu, 30 Jul 2015 18:52:16 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: <877fph3l3o.fsf@smart-cactus.org> References: <8761533ry5.fsf@smart-cactus.org> <877fph3l3o.fsf@smart-cactus.org> Message-ID: There was talk from an earlier email thread of releasing the Haskell Platform at the same time as 7.10.2. I am referring to the weekly news of 2015/05/11: https://ghc.haskell.org/trac/ghc/blog/weekly20150511 and this email thread: https://mail.haskell.org/pipermail/ghc-devs/2015-May/008911.html Was this plan abandoned? Or was there something unexpected that is delaying it? James On Thu, Jul 30, 2015 at 2:07 PM, Ben Gamari wrote: > Hello again! > > See below for an important announcement regarding the `text` issue > described earlier. > > > Ben Gamari writes: > > > ===================================================================== > > The (Interactive) Glasgow Haskell Compiler -- version 7.10.2 > > ===================================================================== > > > > The GHC Team is pleased to announce a new bug-fix release of GHC, > > 7.10.2. > > > > There have been a number of significant bug fixes since the 7.10.1 (with > > over 70 defects fixed). These include fixes affecting type-checker > > correctness, runtime stability, and compiler performance. For this > > reason we highly recommend that users of 7.10.1 upgrade quickly. > > > > Note that due to changes made in this release to GHC's optimizer, > > previously fragile-but-working rewrite rules may fail to fire. One > > example of this was found in the widely-used `text` package late in the > > release cycle, which manifested in long compilation times and poor code > > generation for `Text` literals (see [Trac #10528]). Users are advised to > > use text >=1.2.1.2 which includes more robust rewrite rules. > > > It has been brought to my attention that the fix included in > text-1.2.1.2 does not in fact fix the rule issues triggered by GHC > 7.10.2 (see the later comments on #10528 for details). I have pushed > text-1.2.1.3 to Hackage which finally resolves this issue. > > Users of GHC 7.10.2 should upgrade to text >=1.2.1.3 at their earliest > convenience. > > Cheers, > > - Ben > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Jul 30 16:55:35 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 30 Jul 2015 12:55:35 -0400 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> <877fph3l3o.fsf@smart-cactus.org> Message-ID: On Thu, Jul 30, 2015 at 12:52 PM, James M wrote: > There was talk from an earlier email thread of releasing the Haskell > Platform at the same time as 7.10.2. I think the right place to ask this is libraries at haskell.org. I would imagine they're in final testing and/or getting release packages in place. (Note as previously mentioned that "text" was just updated, and the Platform needs that; this presumably means they had to start over making release packages.) -- 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 ben at well-typed.com Thu Jul 30 17:04:33 2015 From: ben at well-typed.com (Ben Gamari) Date: Thu, 30 Jul 2015 19:04:33 +0200 Subject: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2 In-Reply-To: References: <8761533ry5.fsf@smart-cactus.org> <877fph3l3o.fsf@smart-cactus.org> Message-ID: <87mvyd1sri.fsf@smart-cactus.org> James M writes: > There was talk from an earlier email thread of releasing the Haskell > Platform at the same time as 7.10.2. > > I am referring to the weekly news of 2015/05/11: > https://ghc.haskell.org/trac/ghc/blog/weekly20150511 > > and this email thread: > https://mail.haskell.org/pipermail/ghc-devs/2015-May/008911.html > > > Was this plan abandoned? Or was there something unexpected that is delaying > it? > Not at all! There ended up being a bit of timing skew between the Platform and GHC releases but an approximately concurrent release is still the plan. The Platform folks are hard at work as we speak, in the final stages of pushing out their release. I expect it will be announced shortly. Unfortunately due to the late notice of the text issue, the initial release will ship with text-1.2.1.1, which is still affected by the rewrite issue. That being said, the impact of this issue is mostly on compile time, in most cases you shouldn't see much impact on runtime performance. Moreover, they will be working to push out another release with text-1.2.1.3 in the coming days. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From zemyla at gmail.com Thu Jul 30 17:38:52 2015 From: zemyla at gmail.com (Zemyla) Date: Thu, 30 Jul 2015 12:38:52 -0500 Subject: [Haskell-cafe] Different forms for RandomT? In-Reply-To: References: Message-ID: Normally, a monad transformer to provide a random number generator would be of the form StateT g, where g is a RandomGen. But I've seen some libraries (like QuickCheck) define their RandomT as: newtype RandomT g m a = RandomT { runRandomT :: g -> m a } with their monadic bind operation defined as (RandomT m) >>= f = RandomT $ \g -> let (ga, gb) = split g in m ga >>= (\a -> runRandomT (f a) gb) and return and fail as in ReaderT. Can someone describe the advantages and disadvantages of doing RandomT this way? I mean, if your generator has a subpar split operation (and most do), this will obviously exacerbate any problems with it. Does it give any comparable advantages? -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu Jul 30 18:14:37 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 30 Jul 2015 21:14:37 +0300 Subject: [Haskell-cafe] Different forms for RandomT? In-Reply-To: References: Message-ID: <55BA698D.9090806@ro-che.info> On 30/07/15 20:38, Zemyla wrote: > Normally, a monad transformer to provide a random number generator would > be of the form StateT g, where g is a RandomGen. But I've seen some > libraries (like QuickCheck) define their RandomT as: > > newtype RandomT g m a = RandomT { runRandomT :: g -> m a } > > with their monadic bind operation defined as > > (RandomT m) >>= f = RandomT $ \g -> let (ga, gb) = split g in m ga >>= > (\a -> runRandomT (f a) gb) > > and return and fail as in ReaderT. > > Can someone describe the advantages and disadvantages of doing RandomT > this way? I mean, if your generator has a subpar split operation (and > most do), this will obviously exacerbate any problems with it. tf-random addresses this. > Does it give any comparable advantages? It doesn't introduce data dependencies. Let's say you generate a random binary tree. With the split approach, you can take the right subtree without evaluating the left one. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mark.lentczner at gmail.com Thu Jul 30 19:08:19 2015 From: mark.lentczner at gmail.com (Mark Lentczner) Date: Thu, 30 Jul 2015 12:08:19 -0700 Subject: [Haskell-cafe] ANNOUNCE: Haskell Platform 7.10.2 Message-ID: Haskellers, we are pleased to announce the release of Haskell Platform 7.10.2 *get it here... * Highlights include: - GHC 7.10.2 - packages & tools bumped to very latest - major package updates to: - attoparsec - case-insensitive - cgi - GLUT, GLURaw, OpenGL, & OpenGLRaw - mtl - network - primitive & vector - QuickCheck - random - syb - text - new website - new installer script for linux - 10 bugs closed: Issues ? haskell/haskell-platform This is our first release concurrent with GHC's release. You'll notice that the version number has changed to reflect that from now on, our aim is to keep HP releases sync'd to GHC releases. *Note:* Haskell Platform download pages are often cached - you may need to hit reload to see the release. *About the last minute update to text package:* *tl;dr: Vast majority of code will never notice the difference. Go ahead and get the HP now and start enjoying 7.10.2 You can always update to the point release when it comes out.* Despite all the testing, GHC central noticed just a day before release that there was a regression with text literals in 7.10.2. It was possible to work around the issue via a change to the text package, and text-1.2.1.3 was released just today. Alas, there wasn't enough time to re-build and test the platform installers between then and now, so this release has text-1.2.1.1. There will be a point release (7.10.2.1) of the Platform this weekend or next with the updated text package. The issue does not result in incorrect code, only slow compilation times for very text literal laden code (as in thousands of literals), and slightly higher one-time construction cost at run-time. In full stack builds and many other test builds, these slow downs were inconsequential. *Windows Notes:* The Haskell Platform on Windows now provides the MSys2 tools. These tools are needed when installing packages that use conf-tools (generally rare). These tools are not automatically placed onto the PATH in order avoid troubles due to MSys2 tools which have the same name as a standard Windows tool (e.g., echo, find, dir). - Mark "release monad" Lentczner Special thanks to Erik Rantappa, Wasif Hasan Baig, & Ben Gamari for the new web site. Randy Polen for Windows build wrangling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc.schroeder at gmail.com Thu Jul 30 21:19:25 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Thu, 30 Jul 2015 23:19:25 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: > > what happens if an exception is thrown? In normal STM, if an exception occurs during a transaction, the transaction is gracefully aborted & none of its effects are made visible. Exactly the same thing is true in the presence of finalizers: if an exception occurs in the finalizer, the transaction is aborted & its effects discarded (you are still responsible for cleaning up any side effects that happened as part of the I/O action, of course). > what are the retry semantics? The finalizer is only run once the transaction is guaranteed to commit. The STM part of the transaction might retry many times, but once the system determines there are no conflicts, it runs the finalizer. When the finalizer has finished, the transaction commits & makes its effects visible. If during the time the finalizer is running another transaction comes along and makes a conflicting write and tries to commit, the other transaction has to retry (in reality, the other transaction's thread is put to sleep and woken up once it actually has a chance to commit, i.e. once the finalizer of the first transaction has finished). > is there a at-most-once guarantees for the IO action? Yes (see above). A much more detailed description of all of this can be found in Sections 2.4 and 2.5 of my thesis [1], in which I give a complete formal semantics of STM with finalizers. [1]: https://github.com/mcschroeder/thesis -------------- next part -------------- An HTML attachment was scrubbed... URL: From midfield at gmail.com Thu Jul 30 21:31:47 2015 From: midfield at gmail.com (Ben) Date: Thu, 30 Jul 2015 14:31:47 -0700 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: <7931D85C-D281-4834-8FD9-CBDF2E184545@gmail.com> looks very nice. thanks for the pointers. best, ben > On Jul 30, 2015, at 2:19 PM, Michael Schr?der wrote: > > what happens if an exception is thrown? > > In normal STM, if an exception occurs during a transaction, the transaction is gracefully aborted & none of its effects are made visible. Exactly the same thing is true in the presence of finalizers: if an exception occurs in the finalizer, the transaction is aborted & its effects discarded (you are still responsible for cleaning up any side effects that happened as part of the I/O action, of course). > > what are the retry semantics? > > The finalizer is only run once the transaction is guaranteed to commit. > > The STM part of the transaction might retry many times, but once the system determines there are no conflicts, it runs the finalizer. When the finalizer has finished, the transaction commits & makes its effects visible. If during the time the finalizer is running another transaction comes along and makes a conflicting write and tries to commit, the other transaction has to retry (in reality, the other transaction's thread is put to sleep and woken up once it actually has a chance to commit, i.e. once the finalizer of the first transaction has finished). > > is there a at-most-once guarantees for the IO action? > > Yes (see above). > > > A much more detailed description of all of this can be found in Sections 2.4 and 2.5 of my thesis [1], in which I give a complete formal semantics of STM with finalizers. > > [1]: https://github.com/mcschroeder/thesis > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From felipe.lessa at gmail.com Fri Jul 31 02:37:58 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 30 Jul 2015 23:37:58 -0300 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: <55BADF86.6070504@gmail.com> Em 30-07-2015 08:11, Michael Schr?der escreveu: > my master's thesis [...] > atomicallyWithIO :: STM a -> (a -> IO b) -> IO b Isn't it beautiful? I wish mine could be summarized into a nice type signature :). Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From will.yager at gmail.com Fri Jul 31 03:12:26 2015 From: will.yager at gmail.com (William Yager) Date: Thu, 30 Jul 2015 20:12:26 -0700 Subject: [Haskell-cafe] New GHC fails to specialize imported function Message-ID: Hello all, I just installed the new Haskell platform for OS X. It seems to have caused a major performance regression for a program I'm working on, making it well over 25x slower. The culprit appears to be that the new GHC (7.10.2) fails to specialize an imported function. If I manually add a SPECIALIZE pragma, performance goes back to around what it used to be. The code in question is located at https://github.com/wyager/HNet . As it stands, the code takes about 30 seconds to run on my machine. With the previous haskell-platform, it only took about .9 seconds. If I modify Operations.hs and uncomment the SPECIALIZE pragma, runtime goes down to about 1.1 seconds (still slower for some reason, but not awful). To test, compile with -O2 (as the program makes heavy use of Data.Vector, which requires -fspec-constr for performance). Additionally, my experience doesn't seem to match https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/pragmas.html#specialize-pragma in that if I add an INLINABLE pragma at the site of (??)'s definition and then try to SPECIALIZE it in a different file after importing, GHC tells me "Warning: SPECIALISE pragma on INLINE function probably won't fire: ????". Cheers, Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From creswick at gmail.com Fri Jul 31 03:17:12 2015 From: creswick at gmail.com (Rogan Creswick) Date: Thu, 30 Jul 2015 20:17:12 -0700 Subject: [Haskell-cafe] Excessive whitespace with tasty all of a sudden Message-ID: I recently have been refactoring chatter, and finally got the test suite semi-operational (after lots of extensive changes, both to the library and to the tests to add tests and to make them compatible with the new APIs). Somewhere during the changes, the whitespace output by tasty to format the test status lines nicely has grown out of hand. For example, tests that used to show the OK message on the same line, now look like this (see below). Has anyone else run across this? Does anyone have debugging suggestions? Thanks! Rogan NLP.POS.LiteralTagger Empty tagger always tags as UNK: OK +++ OK, passed 100 tests. Initial training Simple training test: OK Duplicate entries -- use the last value.: OK From hanche at math.ntnu.no Fri Jul 31 07:14:55 2015 From: hanche at math.ntnu.no (Harald Hanche-Olsen) Date: Fri, 31 Jul 2015 09:14:55 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: References: Message-ID: <55BB206F.2090400@math.ntnu.no> I notice that the OS X version is still installing binaries in /usr/bin. If I have understood correctly, in the upcoming OS X 10.11 /usr/bin and various other directories will be locked down hard, and no third party software will be allowed there. So perhaps the installer should be changed to install the binaries elsewhere, such as /usr/local/bin? ? Harald Mark Lentczner wrote: > Haskellers, we are pleased to announce the release of > > Haskell Platform 7.10.2 > /get it here... / From dct25-561bs at mythic-beasts.com Fri Jul 31 08:14:33 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 31 Jul 2015 09:14:33 +0100 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Hi Michael, Good work - what a lovely topic for your master's thesis! There's something a little bit odd about the real world being able to access the result of a transaction that hasn't yet (and may still yet not be) committed, but your arguments for why this is a good thing are compelling. It is also a bit odd that a STM transaction nested running within the finalizer won't see the results of the previous transaction as it's not yet committed. Not too surprising once you read your justification, but surprising beforehand. A finalizer which has non-atomic real-world effects needs to be quite careful about undoing those effects when exceptions are thrown. For instance, looking at your example code[1]: ------------------------------------------------------------------------------ durably :: DatabaseHandle d -> TX d a -> IO a durably h (TX m) = atomicallyWithIO action finalizer where action = runStateT m (database h, []) finalizer (a, (_,ops)) = serialize ops h >> return a serialize :: [Operation d] -> DatabaseHandle d -> IO () serialize ops (DatabaseHandle _ h) = withMVar h (\h -> forM_ ops $ B.hPut h . runPut . safePut) ------------------------------------------------------------------------------ [1] https://github.com/mcschroeder/social-example/blob/8925056c/tx/TX.hs#L98 If some of those B.hPut calls succeed but then one fails (e.g. the disk is full) then the transaction will be rolled back, but the on-disk state will be left partially written. You're in good company with this problem, by the way - I've known large, expensive, commercial database products fail horribly and irretrievably in exactly this fashion when encountering a full disk at the wrong moment! Even if the finalizer did include exception handling to deal with this situation, what happens with asynchronous exceptions? Does the finalizer run with async exceptions masked? I think it needs to: if not, then it seems it could run past the point where cleanup could occur and then receive an exception: essentially the finalizer runs to completion and then the STM transaction rolls back. Async exceptions get a brief mention in your thesis but I can't see anything about this point there - apologies if I've missed it. Cheers, David On 30 July 2015 at 12:11, Michael Schr?der wrote: > Hi everyone, > > I want to finally announce some work I did as part of my master's thesis > [1]. It's an extension to GHC's STM implementation. The main idea is to > introduce a new primitive function > > atomicallyWithIO :: STM a -> (a -> IO b) -> IO b > > Like the existing atomically operation, atomicallyWithIO performs an STM > computation. Additionally, it takes a *finalizer*, which is an arbitrary > I/O action that can depend on the result of the STM computation, and > combines it with the transaction in such a way that: > > 1. The finalizer is only performed if the STM transaction is > guaranteed to commit. > 2. The STM transaction only commits if the finalizer finishes without > raising an exception. > > > > A motivation of why this is useful: > > Say we want to save the results of some STM transaction, i.e. persist them > to disk. Currently, this is not possible in a transactionally safe way. The > naive approach would be to first atomically perform some STM computation > and then independently serialise its result: > > do > x <- atomically m > serialize x > > There are two issues with this. First, another thread could perform a > second transaction and serialise it before we have finished serialising > ours, which could result in an inconsistent state between the memory of our > program and what is stored on disk. Secondly, the function serialize > might not terminate at all; it could throw an exception or its thread could > die. Again we would end up with an inconsistent state and possibly data > loss. > > We might try to simply move serialisation into the atomic block, but to do > this we have to circumvent the types, which should already be a huge red > flag: > > atomically $ do > x <- m > unsafeIOToSTM (serialize x) > > The problem here is of course that an STM transaction can retry many > times, which will also result in serialize being executed many times, > which is probably not something we want. Furthermore, if the thread > receives an asynchronous exception, the transaction will abort in an > orderly fashion, while serialize, with its irrevocable side effects, > cannot be undone. > > But with finalizers, the solution is easy: > > atomicallyWithIO m serialize > > > I've written a small example application that uses finalizers and other > stuff from my thesis to build a lightweight STM database framework: [2] > > There are more possible uses cases besides serialisation (such as > interactive transactions) and some interesting issues surrounding > finalizers (like nesting of transactions) which are discussed in greater > detail in my thesis [1], which also includes a formal operational semantics > of the whole thing. > > I have implemented finalizers in my fork of GHC [3], if any of you want to > play around with them yourself. The atomicallyWithIO function is exported > from the GHC.Conc.Sync module. > > > Cheers, > Michael > > > [1] https://github.com/mcschroeder/thesis > [2] https://github.com/mcschroeder/social-example > [3] https://github.com/mcschroeder/ghc > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri Jul 31 12:17:23 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 31 Jul 2015 08:17:23 -0400 Subject: [Haskell-cafe] New GHC fails to specialize imported function In-Reply-To: References: Message-ID: This sounds terrible. Please post a bug report at https://ghc.haskell.org/trac/ghc/wiki/ReportABug Thanks! Richard On Jul 30, 2015, at 11:12 PM, William Yager wrote: > Hello all, > > I just installed the new Haskell platform for OS X. > > It seems to have caused a major performance regression for a program I'm working on, making it well over 25x slower. > > The culprit appears to be that the new GHC (7.10.2) fails to specialize an imported function. If I manually add a SPECIALIZE pragma, performance goes back to around what it used to be. > > The code in question is located at https://github.com/wyager/HNet . > > As it stands, the code takes about 30 seconds to run on my machine. With the previous haskell-platform, it only took about .9 seconds. > > If I modify Operations.hs and uncomment the SPECIALIZE pragma, runtime goes down to about 1.1 seconds (still slower for some reason, but not awful). > > To test, compile with -O2 (as the program makes heavy use of Data.Vector, which requires -fspec-constr for performance). > > > > Additionally, my experience doesn't seem to match https://downloads.haskell.org/~ghc/7.8.4/docs/html/users_guide/pragmas.html#specialize-pragma in that if I add an INLINABLE pragma at the site of (??)'s definition and then try to SPECIALIZE it in a different file after importing, GHC tells me "Warning: SPECIALISE pragma on INLINE function probably won't fire: ????". > > Cheers, > Will > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From mc.schroeder at gmail.com Fri Jul 31 12:18:22 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Fri, 31 Jul 2015 14:18:22 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Hi David, I appreciate your interest in my thesis! A finalizer which has non-atomic real-world effects needs to be quite > careful about undoing those effects when exceptions are thrown. [...] If > some of those B.hPut calls succeed but then one fails (e.g. the disk is > full) then the transaction will be rolled back, but the on-disk state will > be left partially written. > Yes, you are absolutely right! The example application lacks some of the safeguards one would expect in a production-ready system. It was intended to be more of a demonstration of how easily one can in principle build a database-like system on top of STM using finalizers. It still requires some engineering effort to make it entirely safe and practical. I should have documented this better?or just gone the extra mile and actually made it safe! > Even if the finalizer did include exception handling to deal with this > situation, what happens with asynchronous exceptions? Does the finalizer > run with async exceptions masked? > The finalizer does not run with async exceptions masked and you're right that one needs to be careful about how to deal with side-effects & async exceptions & cleanup within the finalizer?just like with any kind of I/O, really. In the TX example code, serialize should probably use withMVarMasked instead of withMVar. But I don't think the finalizer should run with async exceptions masked by default. There are uses cases where you really do want the finalizer to be interruptible from another thread, e.g. if you want to be able to timeout the whole transaction (STM part + finalizer part, as in: timeout n $ atomicallyWithIO ...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Fri Jul 31 13:06:42 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 31 Jul 2015 15:06:42 +0200 Subject: [Haskell-cafe] Taking over package erlang In-Reply-To: <55BA2B8E.20301@gmail.com> References: <55BA2B8E.20301@gmail.com> Message-ID: Hi, I opened an issue to track progress: https://github.com/haskell-infra/hackage-trustees/issues/45 - Adam On Thu, Jul 30, 2015 at 3:50 PM, Po?r Art?r wrote: > Hi, > > The package erlang (https://hackage.haskell.org/package/erlang) wasn't > updated since 2008, and it became fairly outdated since then. > > The author was contacted half a year ago, but he didn't respond. So > following the instructions on Hackage I state my intention to take over. I > have made the package functional again, and I would like to make it > available on Hackage. > > Art?r > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Fri Jul 31 13:06:57 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Fri, 31 Jul 2015 14:06:57 +0100 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Hi Michael, I wholeheartedly agreed that timeout n $ atomicallyWithIO ... is important, but that would generally work even if the finalizer ran masked wouldn't it? Most actions that block are interruptible. Put another way, I'd be interested to see how you could make serialize safe without this. Something like this: serialize :: [Operation d] -> DatabaseHandle d -> IO () serialize ops (DatabaseHandle _ h) = withMVar h (\h -> forM_ ops $ B.hPut h . runPut . safePut) `onException` magicalFileRollback h (ignoring the tedious implementation of magicalFileRollback) doesn't look quite right as if you got an async exception in the tiny window between onException exiting and serialize exiting then the STM transaction would roll back but the file wouldn't. I'm not convinced I totally understand async exceptions so if you (or anyone else) can point out why this works I'd be very grateful. Cheers, David On 31 July 2015 at 13:18, Michael Schr?der wrote: > Hi David, I appreciate your interest in my thesis! > > A finalizer which has non-atomic real-world effects needs to be quite >> careful about undoing those effects when exceptions are thrown. [...] If >> some of those B.hPut calls succeed but then one fails (e.g. the disk is >> full) then the transaction will be rolled back, but the on-disk state will >> be left partially written. >> > > Yes, you are absolutely right! The example application lacks some of the > safeguards one would expect in a production-ready system. It was intended > to be more of a demonstration of how easily one can in principle build a > database-like system on top of STM using finalizers. It still requires some > engineering effort to make it entirely safe and practical. I should have > documented this better?or just gone the extra mile and actually made it > safe! > > >> Even if the finalizer did include exception handling to deal with this >> situation, what happens with asynchronous exceptions? Does the finalizer >> run with async exceptions masked? >> > > The finalizer does not run with async exceptions masked and you're right > that one needs to be careful about how to deal with side-effects & async > exceptions & cleanup within the finalizer?just like with any kind of I/O, > really. In the TX example code, serialize should probably use > withMVarMasked instead of withMVar. But I don't think the finalizer > should run with async exceptions masked by default. There are uses cases > where you really do want the finalizer to be interruptible from another > thread, e.g. if you want to be able to timeout the whole transaction (STM > part + finalizer part, as in: timeout n $ atomicallyWithIO ...) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Jul 31 14:45:38 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 31 Jul 2015 16:45:38 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: References: Message-ID: 2015-07-30 21:08 GMT+02:00 Mark Lentczner : > Haskellers, we are pleased to announce the release of > > Haskell Platform 7.10.2 > *get it here... * > [...] > Nice! I've just tested things under Windows, and everything works for me so far, only one tiny nit remains: In the documentation index (file:///.../Haskell%20Platform/7.10.2/lib/extralibs/doc/index.html) package names for the non-GHC packages are still missing in the right column, see attached picture. I'm not sure if this is a glitch in the HP build or a bug in Cabal or a bug in Haddock or..., so I don't know where to open an issue. Does anybody have a clue what might cause this? If I build packages locally in a sandbox, their documentation shows similar bugs. Is this working for other people or do they experience the same behavior? Nevertheless, great work! Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hp7102.png Type: image/png Size: 95281 bytes Desc: not available URL: From allbery.b at gmail.com Fri Jul 31 14:55:37 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 31 Jul 2015 10:55:37 -0400 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: <55BB206F.2090400@math.ntnu.no> References: <55BB206F.2090400@math.ntnu.no> Message-ID: On Fri, Jul 31, 2015 at 3:14 AM, Harald Hanche-Olsen wrote: > I notice that the OS X version is still installing binaries in /usr/bin. > If I have understood correctly, in the upcoming OS X 10.11 /usr/bin and > various other directories will be locked down hard, and no third party > software will be allowed there. > So perhaps the installer should be changed to install the binaries > elsewhere, such as /usr/local/bin? > Mostly correct. I would argue against /usr/local though because Homebrew uses it and I'd want to avoid possible collisions, especially if someone were to e.g. install git-annex or pandoc via HB without realizing they're written in Haskell. (Yes, this happens!) Many third party packages already use /opt, e.g. /opt/haskell or /opt/haskell-platform. (See for example XQuartz or calibre.) -- 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 svenpanne at gmail.com Fri Jul 31 16:33:00 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 31 Jul 2015 18:33:00 +0200 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: References: Message-ID: [ re-posted with a link instead of an attachment, the mail size limit seems to be a bit small on some lists... ] 2015-07-30 21:08 GMT+02:00 Mark Lentczner : > Haskellers, we are pleased to announce the release of > > Haskell Platform 7.10.2 > *get it here... * > [...] > Nice! I've just tested things under Windows, and everything works for me so far, only one tiny nit remains: In the documentation index (file:///.../Haskell%20Platform/7.10.2/lib/extralibs/doc/index.html) package names for the non-GHC packages are still missing in the right column, see http://i.imgur.com/jh0u8EP.png. I'm not sure if this is a glitch in the HP build or a bug in Cabal or a bug in Haddock or..., so I don't know where to open an issue. Does anybody have a clue what might cause this? If I build packages locally in a sandbox, their documentation shows similar bugs. Is this working for other people or do they experience the same behavior? Nevertheless, great work! Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Jul 31 16:39:05 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 31 Jul 2015 12:39:05 -0400 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: Haskell Platform 7.10.2 In-Reply-To: References: <55BB206F.2090400@math.ntnu.no> Message-ID: On Fri, Jul 31, 2015 at 10:55 AM, Brandon Allbery wrote: > Many third party packages already use /opt, e.g. /opt/haskell or > /opt/haskell-platform. (See for example XQuartz or calibre.) Whoops, sorry, calibre does so on Linux but is a self-contained app bundle on OS X. -- 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 mc.schroeder at gmail.com Fri Jul 31 18:12:24 2015 From: mc.schroeder at gmail.com (=?UTF-8?Q?Michael_Schr=C3=B6der?=) Date: Fri, 31 Jul 2015 20:12:24 +0200 Subject: [Haskell-cafe] STM Finalizers In-Reply-To: References: Message-ID: Ah, of course you're right, I forgot that masking /= completely uninterruptible. And yes, it does seem like the finalizer needs to be masked by default, in order to prevent the kind of race condition you describe. Should be an easy change. Thanks for pointing that out! On 31 July 2015 at 15:06, David Turner wrote: > Hi Michael, > > I wholeheartedly agreed that timeout n $ atomicallyWithIO ... is > important, but that would generally work even if the finalizer ran masked > wouldn't it? Most actions that block are interruptible. > > Put another way, I'd be interested to see how you could make serialize safe > without this. Something like this: > > serialize :: [Operation d] -> DatabaseHandle d -> IO () > serialize ops (DatabaseHandle _ h) = > withMVar h (\h -> forM_ ops $ B.hPut h . runPut . safePut) > `onException` > magicalFileRollback h > > (ignoring the tedious implementation of magicalFileRollback) doesn't look > quite right as if you got an async exception in the tiny window between > onException exiting and serialize exiting then the STM transaction would > roll back but the file wouldn't. I'm not convinced I totally understand > async exceptions so if you (or anyone else) can point out why this works > I'd be very grateful. > > Cheers, > > David > > > > > On 31 July 2015 at 13:18, Michael Schr?der wrote: > >> Hi David, I appreciate your interest in my thesis! >> >> A finalizer which has non-atomic real-world effects needs to be quite >>> careful about undoing those effects when exceptions are thrown. [...] If >>> some of those B.hPut calls succeed but then one fails (e.g. the disk is >>> full) then the transaction will be rolled back, but the on-disk state will >>> be left partially written. >>> >> >> Yes, you are absolutely right! The example application lacks some of the >> safeguards one would expect in a production-ready system. It was intended >> to be more of a demonstration of how easily one can in principle build a >> database-like system on top of STM using finalizers. It still requires some >> engineering effort to make it entirely safe and practical. I should have >> documented this better?or just gone the extra mile and actually made it >> safe! >> >> >>> Even if the finalizer did include exception handling to deal with this >>> situation, what happens with asynchronous exceptions? Does the finalizer >>> run with async exceptions masked? >>> >> >> The finalizer does not run with async exceptions masked and you're right >> that one needs to be careful about how to deal with side-effects & async >> exceptions & cleanup within the finalizer?just like with any kind of I/O, >> really. In the TX example code, serialize should probably use >> withMVarMasked instead of withMVar. But I don't think the finalizer >> should run with async exceptions masked by default. There are uses cases >> where you really do want the finalizer to be interruptible from another >> thread, e.g. if you want to be able to timeout the whole transaction (STM >> part + finalizer part, as in: timeout n $ atomicallyWithIO ...) >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Fri Jul 31 22:44:29 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Fri, 31 Jul 2015 18:44:29 -0400 Subject: [Haskell-cafe] Why is the no tuple syntax for sum types In-Reply-To: <55BA3C26.5010105@gmail.com> References: <55BA3C26.5010105@gmail.com> Message-ID: For sum types you need a way to construct them and pattern match them. Without a way to _name_ them, it would probably look like this: showError :: (Result | Error3 | Error8) -> String showError (result ||) = "no error" showError (| error3 |) = "error3: " ++ show error3 showError (|| error8 |) = "error8: " ++ show error8 It's not the most readable code, so I'd generally avoid using it for anything greater than 3 (same applies to tuples). It also suffers the same flaw as tuples: no way to extend them easily. Imagine adding a new error: you have to edit _all_ of the patterns: showError :: (Result | Error3 | Error8 | Error11 ) -> String showError (result |||) = "no error" showError (| error3 ||) = "error3: " ++ show error3 showError (|| error8 |) = "error8: " ++ show error8 showError (||| error11 ) = "error11: " ++ show error11 Extensible records and variants might be able to solve these problems, but that's a rabbit-hole of its own though. From neilcjensen at gmail.com Fri Jul 31 22:55:53 2015 From: neilcjensen at gmail.com (Neil) Date: Fri, 31 Jul 2015 15:55:53 -0700 (PDT) Subject: [Haskell-cafe] digestive-functors and listOf Message-ID: <830a2734-eca1-47c4-855c-d71b35a4a5f5@googlegroups.com> I've been able to use digestive-functors with simple forms successfully in a snap application; however, I'm getting stuck when trying to handle a list of hidden inputs. There is something I'm not quite getting on how to use 'listOf'. Can anyone point me in the right direction? Thanks. The rendered html from a previous page includes the following hidden fields:
The data types are: data ConfirmMessage = ConfirmMessage { isoDate :: T.Text, subject :: T.Text, body :: T.Text, action :: T.Text, recipients :: [Recipient]} deriving (Show) data Recipient = Recipient { email :: T.Text } deriving (Show) The forms are: messageForm :: (Monad m) => Form T.Text m ConfirmMessagemessageForm = ConfirmMessage <$> "isoDate" .: stringRead "Missing ISOdate" Nothing <*> "subject" .: stringRead "Subject required" Nothing <*> "body" .: stringRead "Body required" Nothing <*> "action" .: stringRead "Missing action" Nothing <*> "recipients" .: listOf recipientForm' Nothing recipientForm' :: (Monad m) => Formlet T.Text m RecipientrecipientForm'= Recipient <$> "email" .: stringRead "Missing email" Nothing Error message: Couldn't match type `Text.Digestive.Form.Internal.FormTree m0 v0 m0 Recipient' with `Maybe Recipient -> Form T.Text m Recipient' Expected type: Formlet T.Text m Recipient Actual type: Text.Digestive.Form.Internal.FormTree m0 v0 m0 Recipient Relevant bindings include recipientForm' :: Formlet T.Text m Recipient (bound at src/Handler/TradeNotifyConfirm.hs:224:1) In the expression: Recipient <$> "email" .: stringRead "Missing email" Nothing In an equation for `recipientForm'': recipientForm' = Recipient <$> "email" .: stringRead "Missing email" Nothing Thanks in advance, Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: