From wren at community.haskell.org Thu Sep 1 02:21:50 2016 From: wren at community.haskell.org (wren romano) Date: Wed, 31 Aug 2016 19:21:50 -0700 Subject: [Haskell-cafe] Announcing containers 0.5.8.1 In-Reply-To: References: Message-ID: On Wed, Aug 31, 2016 at 6:44 AM, Alexey Khudyakov wrote: > On 31 August 2016 at 12:10, Henning Thielemann wrote: >> Sometimes I hope that availability of portable libraries would help >> non-mainstream compilers to gain ground. > > Compiler that doesn't support bang patterns (and half of GHC > extensions) cannot gain ground. Bang patterns (i.e., the kind we are using which are always top-level, not intermixed with patterns) are an extremely simple extension. Every time someone says "it's so easy to avoid BangPatterns, you can just..."— well, yes: it's so easy, alternative compilers can do exactly what you suggest in order to implement BangPatterns. The whole point of BangPatterns is not to increase expressivity of Haskell, it's to clean up code by saying what you mean. In Haskell we value saying what we mean, and avoiding exposing implementation-detail cruftiness; and this is simply another example of that. By avoiding CPP hackery we (a) make the containers code much cleaner and easier to read, (b) avoid needing to worry about CPP possibly doing unexpected things, and (c) avoid needing to worry about whether our tests actually test what we mean (since using CPP means doing variational programming, so we don't necessarily run the variant of the code we think we are). -- Live well, ~wren From Graham.Hutton at nottingham.ac.uk Thu Sep 1 08:58:54 2016 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Thu, 1 Sep 2016 08:58:54 +0000 Subject: [Haskell-cafe] New edition of "Programming in Haskell" Message-ID: <2D262316-CD19-4F24-96C5-38B2FA6E28CF@exmail.nottingham.ac.uk> Dear all, I'm delighted to announce that the new edition of "Programming in Haskell" is now available! Further details are provided below, and are also available from: http://tinyurl.com/hnfjdgc. Best wishes, Graham ================================================================= *** BOOK ANNOUNCEMENT *** Programming in Haskell - 2nd Edition Graham Hutton, University of Nottingham Cambridge University Press, 1st September 2016 320 pages, 120 exercises, ISBN 9781316626221 http://tinyurl.com/hnfjdgc ================================================================= DESCRIPTION: Haskell is a purely functional language that allows programmers to rapidly develop clear, concise, and correct software. The language has grown in popularity in recent years, both in teaching and in industry. This book is based on the author's experience of teaching Haskell for more than twenty years. All concepts are explained from first principles and no programming experience is required, making this book accessible to a broad spectrum of readers. While Part I focuses on basic concepts, Part II introduces the reader to more advanced topics. This new edition has been extensively updated and expanded to include recent and more advanced features of Haskell, new examples and exercises, selected solutions, and freely downloadable lecture slides and example code. The presentation is clean and simple, while also being fully compliant with the latest version of the language, including recent changes concerning applicative, monadic, foldable, and traversable types. ================================================================= CONTENTS: Foreword Preface Part I. Basic Concepts: 1. Introduction 2. First steps 3. Types and classes 4. Defining functions 5. List comprehensions 6. Recursive functions 7. Higher-order functions 8. Declaring types and classes 9. The countdown problem Part II. Going Further: 10. Interactive programming 11. Unbeatable tic-tac-toe 12. Monads and more 13. Monadic parsing 14. Foldables and friends 15. Lazy evaluation 16. Reasoning about programs 17. Calculating compilers Appendix A. Selected solutions Appendix B. Standard prelude Bibliography Index ================================================================= AUTHOR: Graham Hutton is Professor of Computer Science at the University of Nottingham. He has taught Haskell to thousands of students and received numerous best lecturer awards. Hutton has served as an editor of the Journal of Functional Programming, Chair of the Haskell Symposium and the International Conference on Functional Programming, and Vice-Chair of the ACM Special Interest Group on Programming Languages, and he is an ACM Distinguished Scientist. ================================================================= This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From friedrichwiemer at gmail.com Thu Sep 1 09:23:33 2016 From: friedrichwiemer at gmail.com (Friedrich Wiemer) Date: Thu, 1 Sep 2016 11:23:33 +0200 Subject: [Haskell-cafe] New edition of "Programming in Haskell" In-Reply-To: <2D262316-CD19-4F24-96C5-38B2FA6E28CF@exmail.nottingham.ac.uk> References: <2D262316-CD19-4F24-96C5-38B2FA6E28CF@exmail.nottingham.ac.uk> Message-ID: <0870f9ad-7f39-b583-3840-6b0cd25a09eb@gmail.com> Cool! Actually, this was my first book about Haskell, and is the reason, I fell in love with this beautiful language. Nice work! Friedrich On 01.09.2016 10:58, Graham Hutton wrote: > Dear all, > > I'm delighted to announce that the new edition of "Programming in > Haskell" is now available! Further details are provided below, > and are also available from: http://tinyurl.com/hnfjdgc. > > Best wishes, > > Graham > > ================================================================= > > *** BOOK ANNOUNCEMENT *** > > Programming in Haskell - 2nd Edition > > Graham Hutton, University of Nottingham > > Cambridge University Press, 1st September 2016 > > 320 pages, 120 exercises, ISBN 9781316626221 > > http://tinyurl.com/hnfjdgc > > ================================================================= > > DESCRIPTION: > > Haskell is a purely functional language that allows programmers > to rapidly develop clear, concise, and correct software. The > language has grown in popularity in recent years, both in teaching > and in industry. This book is based on the author's experience > of teaching Haskell for more than twenty years. All concepts > are explained from first principles and no programming experience > is required, making this book accessible to a broad spectrum > of readers. While Part I focuses on basic concepts, Part II > introduces the reader to more advanced topics. > > This new edition has been extensively updated and expanded to > include recent and more advanced features of Haskell, new examples > and exercises, selected solutions, and freely downloadable lecture > slides and example code. The presentation is clean and simple, > while also being fully compliant with the latest version of > the language, including recent changes concerning applicative, > monadic, foldable, and traversable types. > > ================================================================= > > CONTENTS: > > Foreword > Preface > Part I. Basic Concepts: > 1. Introduction > 2. First steps > 3. Types and classes > 4. Defining functions > 5. List comprehensions > 6. Recursive functions > 7. Higher-order functions > 8. Declaring types and classes > 9. The countdown problem > Part II. Going Further: > 10. Interactive programming > 11. Unbeatable tic-tac-toe > 12. Monads and more > 13. Monadic parsing > 14. Foldables and friends > 15. Lazy evaluation > 16. Reasoning about programs > 17. Calculating compilers > Appendix A. Selected solutions > Appendix B. Standard prelude > Bibliography > Index > > ================================================================= > > AUTHOR: > > Graham Hutton is Professor of Computer Science at the University > of Nottingham. He has taught Haskell to thousands of students > and received numerous best lecturer awards. Hutton has served as > an editor of the Journal of Functional Programming, Chair of the > Haskell Symposium and the International Conference on Functional > Programming, and Vice-Chair of the ACM Special Interest Group on > Programming Languages, and he is an ACM Distinguished Scientist. > > ================================================================= > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From raabe at froglogic.com Thu Sep 1 09:57:40 2016 From: raabe at froglogic.com (Frerich Raabe) Date: Thu, 01 Sep 2016 11:57:40 +0200 Subject: [Haskell-cafe] New edition of "Programming in Haskell" In-Reply-To: <2D262316-CD19-4F24-96C5-38B2FA6E28CF@exmail.nottingham.ac.uk> References: <2D262316-CD19-4F24-96C5-38B2FA6E28CF@exmail.nottingham.ac.uk> Message-ID: On 2016-09-01 10:58, Graham Hutton wrote: > I'm delighted to announce that the new edition of "Programming in > Haskell" is now available! Further details are provided below, > and are also available from: http://tinyurl.com/hnfjdgc. That's great news! "Programming in Haskell" has been my favourite introduction to recommend to friends and colleagues for many years, and with this new edition I suspect it will keep being my recommendation for many years to come. I just wish *I* would have been aware of it when I started programming in Haskell. :-] Thanks a lot of revisiting the content! -- Frerich Raabe - raabe at froglogic.com www.froglogic.com - Multi-Platform GUI Testing From guthrie at mum.edu Thu Sep 1 12:37:37 2016 From: guthrie at mum.edu (Gregory Guthrie) Date: Thu, 1 Sep 2016 07:37:37 -0500 Subject: [Haskell-cafe] new edition of "Programming in Haskell" Message-ID: <08EF9DA445C4B5439C4733E1F35705BA064961646626@MAIL.cs.mum.edu> >> I'm delighted to announce that the new edition of "Programming in >> Haskell" is now available! Further details are provided below, >> and are also available from: http://tinyurl.com/hnfjdgc. This is great, and a welcome update, thank you! +1 for book and update :-) -1 for DRM on eBook :-( ------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From novadenizen at gmail.com Thu Sep 1 23:06:37 2016 From: novadenizen at gmail.com (Ken Bateman) Date: Thu, 1 Sep 2016 19:06:37 -0400 Subject: [Haskell-cafe] StdGen Reliability Across Versions / Systems In-Reply-To: <01614b31-b843-4cd7-b44b-d435d86f132c@googlegroups.com> References: <57C1216D.1010002@zoho.com> <01614b31-b843-4cd7-b44b-d435d86f132c@googlegroups.com> Message-ID: Changes to the instance Random for Int and other basic types have recently occurred without modifying anything about StdGen. I successfully submitted a patch a while back that had that effect. On Aug 31, 2016 4:49 PM, "Paolo Giarrusso" wrote: > On Saturday, August 27, 2016 at 7:13:28 AM UTC+2, Christopher Howard wrote: >> >> I know that, ff you feed mkStdGen a particular seed, and pull a list of >> random numbers from that StdGen, that that the list will always be the >> same if your run your compiled program over and over again on that same >> system. But which of the following will cause you to get different >> output?: >> >> 2) Changes in "random" library version >> > > Here's my semi-informed two cents: > > In principle yes if they change random-generation algorithm. > > 1) Changes in GHC version >> > > 3) Compiling / Running on a different host computer (but compiling with >> the same GHC & random versions. >> > > IIUC no: the actual random number generator is not only a fully > deterministic algorithm, but is written using simple integer arithmetic > (not even bitwise operations) which should always have the same semantics > (my only doubt is about the size of `Int`). > OTOH generating random floating-point numbers does more hackery which > would require a closer inspection. > > Reference: stdNext and stdSplit in http://hackage.haskell.org/ > package/random-1.1/docs/src/System-Random.html#StdGen > > For further details and better reassurances, you might have better luck > asking the authors (on GitHub). Maybe this could be documented? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Sep 2 05:04:33 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Sep 2016 01:04:33 -0400 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Gabriel Gonzalez has gotten Cabal benchmark integration working for containers, and then I broke it without realizing I'd done so because Travis CI wasn't building the benchmarks. When I got them working again locally and tried enabling them in .travis.yml (just adding --enable-benchmarks to the cabal configure line), things went kablooey: https://travis-ci.org/haskell/containers/jobs/156997144 Does anyone know how to interpret those entrails? Is this something that can be fixed? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Fri Sep 2 05:13:29 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 01 Sep 2016 22:13:29 -0700 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: <1472793110-sup-2585@sabre> Hello David, I can take a closer work, but here's how you can debug it yourself: 1. Repro it on not-Travis (given that it's a solver error, should be easy) 2. Turn on -v 3. Look through the entrails to see why criterion is not satisfiable. Maybe even just look at the dependencies in the benchmarks section. Could it be a cyclic dependency problem? Edward Excerpts from David Feuer's message of 2016-09-02 01:04:33 -0400: > Gabriel Gonzalez has gotten Cabal benchmark integration working for > containers, and then I broke it without realizing I'd done so because > Travis CI wasn't building the benchmarks. When I got them working again > locally and tried enabling them in .travis.yml (just adding > --enable-benchmarks to the cabal configure line), things went kablooey: > https://travis-ci.org/haskell/containers/jobs/156997144 > > Does anyone know how to interpret those entrails? Is this something that > can be fixed? From moritz.kiefer at purelyfunctional.org Fri Sep 2 05:38:55 2016 From: moritz.kiefer at purelyfunctional.org (Moritz Kiefer) Date: Fri, 02 Sep 2016 07:38:55 +0200 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: <87twdyrhcg.fsf@purelyfunctional.org> David Feuer writes: > Gabriel Gonzalez has gotten Cabal benchmark integration working for > containers, and then I broke it without realizing I'd done so because > Travis CI wasn't building the benchmarks. When I got them working again > locally and tried enabling them in .travis.yml (just adding > --enable-benchmarks to the cabal configure line), things went kablooey: > https://travis-ci.org/haskell/containers/jobs/156997144 > > Does anyone know how to interpret those entrails? Is this something that > can be fixed? I think you just need to add --enable-tests and --enable-benchmarks to "cabal install --only-dependencies". Then you should also be able to remove the manual install of test-framework and friends. Cheers Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From mikhail.glushenkov at gmail.com Fri Sep 2 11:36:46 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Fri, 2 Sep 2016 12:36:46 +0100 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Hi, On 2 September 2016 at 06:04, David Feuer wrote: > Does anyone know how to interpret those entrails? Is this something that can > be fixed? I think you just need to install the benchmark suite deps manually, like you do for the test suite: https://github.com/haskell/containers/blob/master/.travis.yml#L31 Then you should be able to do 'configure --enable-benchmarks'. The problem is that criterion itself depends on containers, and the solver can't handle such circular deps currently: https://github.com/haskell/cabal/issues/1575 From david.feuer at gmail.com Fri Sep 2 14:52:43 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Sep 2016 10:52:43 -0400 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Thanks a lot. I think that's it. On Sep 2, 2016 7:36 AM, "Mikhail Glushenkov" wrote: > Hi, > > On 2 September 2016 at 06:04, David Feuer wrote: > > Does anyone know how to interpret those entrails? Is this something that > can > > be fixed? > > I think you just need to install the benchmark suite deps manually, > like you do for the test suite: > > https://github.com/haskell/containers/blob/master/.travis.yml#L31 > > Then you should be able to do 'configure --enable-benchmarks'. > > The problem is that criterion itself depends on containers, and the > solver can't handle such circular deps currently: > > https://github.com/haskell/cabal/issues/1575 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Sep 2 15:55:06 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Sep 2016 11:55:06 -0400 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Indeed, that fixed the problem. Unfortunately, now I have a different problem. The CI build with benchmarks takes *much* longer than the one without (I think this is mostly because of the time required to install Criterion's dependencies). Is there some way to make Travis build benchmarks for just one GHC version, and let the rest build just the library and tests? On Fri, Sep 2, 2016 at 10:52 AM, David Feuer wrote: > Thanks a lot. I think that's it. > > > On Sep 2, 2016 7:36 AM, "Mikhail Glushenkov" > wrote: >> >> Hi, >> >> On 2 September 2016 at 06:04, David Feuer wrote: >> > Does anyone know how to interpret those entrails? Is this something that >> > can >> > be fixed? >> >> I think you just need to install the benchmark suite deps manually, >> like you do for the test suite: >> >> https://github.com/haskell/containers/blob/master/.travis.yml#L31 >> >> Then you should be able to do 'configure --enable-benchmarks'. >> >> The problem is that criterion itself depends on containers, and the >> solver can't handle such circular deps currently: >> >> https://github.com/haskell/cabal/issues/1575 From fa-ml at ariis.it Fri Sep 2 15:51:12 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 2 Sep 2016 17:51:12 +0200 Subject: [Haskell-cafe] [ANN] lentil - frugal issue tracker Message-ID: <20160902155112.GA13979@casa.casa> I am pleased to announce the release of lentil 1.0 [0]. [0] http://hackage.haskell.org/package/lentil-1.0.0.1 ============================= lentil - frugal issue tracker ============================= lentil is a minimum effort issue tracker; if you litter your code with: -- FIXME: does outPop work with b/w terminals? [ansi] lentil can help you listing, sorting, exporting, tagging slicing and dicing those `todo`s. To see it in action just type: cabal install lentil # or use stack cd ~/your-project-folder/ lentil . Any repo will do, not only Haskell ones! For further information, check the project homepage [1] and the user manual [2]. [1] http://ariis.it/static/articles/lentil/page.html [2] http://ariis.it/static/articles/lentil-manual/page.html Heartfelt "thank you!" to anyone who contributed [3] by providing valuable feedback, suggestions, patches! [3] http://ariis.it/link/repos/lentil/contributors.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From mikhail.glushenkov at gmail.com Fri Sep 2 15:57:44 2016 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Fri, 2 Sep 2016 16:57:44 +0100 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Hi, On 2 September 2016 at 16:55, David Feuer wrote: > Indeed, that fixed the problem. Unfortunately, now I have a different > problem. The CI build with benchmarks takes *much* longer than the one > without (I think this is mostly because of the time required to > install Criterion's dependencies). Try enabling caching on Travis: https://docs.travis-ci.com/user/caching/#Arbitrary-directories https://github.com/haskell/cabal/blob/master/.travis.yml#L86 From david.feuer at gmail.com Fri Sep 2 16:04:40 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 2 Sep 2016 12:04:40 -0400 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: Last I spoke to Herbert, he didn't think the caching stuff was likely to be feasible for containers, because of its unusual place in the ecosystem. There may be some way around it though. On Fri, Sep 2, 2016 at 11:57 AM, Mikhail Glushenkov wrote: > Hi, > > On 2 September 2016 at 16:55, David Feuer wrote: >> Indeed, that fixed the problem. Unfortunately, now I have a different >> problem. The CI build with benchmarks takes *much* longer than the one >> without (I think this is mostly because of the time required to >> install Criterion's dependencies). > > Try enabling caching on Travis: > > https://docs.travis-ci.com/user/caching/#Arbitrary-directories > https://github.com/haskell/cabal/blob/master/.travis.yml#L86 From ezyang at mit.edu Fri Sep 2 21:27:10 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 02 Sep 2016 14:27:10 -0700 Subject: [Haskell-cafe] Travis/Cabal help In-Reply-To: References: Message-ID: <1472851551-sup-9886@sabre> The way that Cabal's CI does it is that it uses new-build, and places .cabal/store and some related directories in the cache. Here's the snippet: cache: directories: - $HOME/.cabal/packages - $HOME/.cabal/store - $HOME/.cabal/bin # We remove the index because it churns quite a bit and we don't want # to pay the cost of repeatedly caching it even though we don't care # about most changing packages. before_cache: - rm -fv $HOME/.cabal/packages/hackage.haskell.org/build-reports.log - rm -fv $HOME/.cabal/packages/hackage.haskell.org/00-index* Full yaml: https://github.com/haskell/cabal/blob/master/.travis.yml Edward Excerpts from David Feuer's message of 2016-09-02 12:04:40 -0400: > Last I spoke to Herbert, he didn't think the caching stuff was likely > to be feasible for containers, because of its unusual place in the > ecosystem. There may be some way around it though. > > On Fri, Sep 2, 2016 at 11:57 AM, Mikhail Glushenkov > wrote: > > Hi, > > > > On 2 September 2016 at 16:55, David Feuer wrote: > >> Indeed, that fixed the problem. Unfortunately, now I have a different > >> problem. The CI build with benchmarks takes *much* longer than the one > >> without (I think this is mostly because of the time required to > >> install Criterion's dependencies). > > > > Try enabling caching on Travis: > > > > https://docs.travis-ci.com/user/caching/#Arbitrary-directories > > https://github.com/haskell/cabal/blob/master/.travis.yml#L86 From michael at schmong.org Sat Sep 3 17:37:06 2016 From: michael at schmong.org (Michael Litchard) Date: Sat, 3 Sep 2016 10:37:06 -0700 Subject: [Haskell-cafe] Data.Conduit.Binary question Message-ID: I'd like to use conduits to (1) read a binary file in chunks (2) take an md5 of that chunk (3) write the chunk to a file (4) write md5 to file. I'm looking at Data.Conduit.Binary. Do I want sourceFileRange for (1)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Sat Sep 3 17:49:27 2016 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Sat, 3 Sep 2016 18:49:27 +0100 Subject: [Haskell-cafe] Data.Conduit.Binary question In-Reply-To: References: Message-ID: Hi Michael, The sourceFile function reads the file in chunks and passes each chunk down the conduit, although the sizes of the chunks are not specified. If that's ok with you, you may be able to do something as simple as this: sourceFile inFile `fuse` accumulateMD5 `fuseUpstream` sinkFile outFile where accumulateMD5 does the MD5 calculation. If you need control over the sizes of the chunks, I'd add something else to the pipeline between sourceFile and accumulateMD5 that sorts that out, rather than using sourceFileRange which will open the file and seek to the right place each time you call it. Hope that helps, On 3 September 2016 at 18:37, Michael Litchard wrote: > I'd like to use conduits to (1) read a binary file in chunks > (2) take an md5 of that chunk (3) write the chunk to a > file > (4) write md5 to file. I'm looking at > Data.Conduit.Binary. > Do I want sourceFileRange for (1)? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Sat Sep 3 20:20:06 2016 From: michael at schmong.org (Michael Litchard) Date: Sat, 3 Sep 2016 13:20:06 -0700 Subject: [Haskell-cafe] Data.Conduit.Binary question In-Reply-To: References: Message-ID: That does help, thanks! On Sat, Sep 3, 2016 at 10:49 AM, David Turner wrote: > Hi Michael, > > The sourceFile function reads the file in chunks and passes each chunk > down the conduit, although the sizes of the chunks are not specified. If > that's ok with you, you may be able to do something as simple as this: > > sourceFile inFile `fuse` accumulateMD5 `fuseUpstream` sinkFile outFile > > where accumulateMD5 does the MD5 calculation. > > If you need control over the sizes of the chunks, I'd add something else > to the pipeline between sourceFile and accumulateMD5 that sorts that out, > rather than using sourceFileRange which will open the file and seek to the > right place each time you call it. > > Hope that helps, > > > > > > On 3 September 2016 at 18:37, Michael Litchard > wrote: > >> I'd like to use conduits to (1) read a binary file in chunks >> (2) take an md5 of that chunk (3) write the chunk to a >> file >> (4) write md5 to file. I'm looking at >> Data.Conduit.Binary. >> Do I want sourceFileRange for (1)? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yallop at gmail.com Sun Sep 4 00:24:26 2016 From: yallop at gmail.com (Jeremy Yallop) Date: Sun, 4 Sep 2016 01:24:26 +0100 Subject: [Haskell-cafe] PEPM 2017 Final Call for Papers (submission deadline extension: 30th Sep.) Message-ID: FINAL CALL FOR PAPERS Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM 2017) NEWS: Deadline extension to 30th September (see below) NEWS: Keynote talk by Neil Jones, DIKU (see below). http://conf.researchr.org/home/PEPM-2017 Paris, France, January 16th - 17th, 2017 (co-located with POPL 2017) PEPM is the premier forum for discussion of semantics-based program manipulation. The first ACM SIGPLAN PEPM symposium took place in 1991, and meetings have been held in affiliation with POPL every year since 2006. PEPM 2017 will be based on a broad interpretation of semantics-based program manipulation, reflecting the expanded scope of PEPM in recent years beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM 2017 will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to maintain the dynamic and interactive nature of PEPM and to encourage participation by practitioners, we also solicit submissions of short papers, including tool demonstrations, and of posters. Scope ----- Topics of interest for PEPM 2017 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing applications of semantics-based program manipulation techniques in new domains. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme chairs. Submission categories and guidelines ------------------------------------ Three kinds of submissions will be accepted: Regular Research Papers, Short Papers and Posters. * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance and clarity. Regular research papers must not exceed 12 pages in ACM Proceedings style (including appendix). * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages in ACM Proceedings style (including appendix). * Posters should describe work relevant to the PEPM community, and must not exceed 2 pages in ACM Proceedings style. We invite poster submissions that present early work not yet ready for submission to a conference or journal, identify new research problems, showcase tools and technologies developed by the author(s), or describe student research projects. At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM 2017 web site. Student participants with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses and other support. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page. Publication and special issue ----------------------------- All accepted papers, short papers and posters included, will appear in formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library. Authors of selected papers from PEPM 2016 and PEPM 2017 will also be invited to expand their papers for publication in a special issue of the journal Computer Languages, Systems and Structures (COMLAN, Elsevier). Keynote ------- Neil Jones (DIKU) will give the PEPM keynote talk, titled Compiling Untyped Lambda Calculus to Lower-level Code by Game Semantics and Partial Evaluation Best paper award ---------------- PEPM 2017 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Submission ---------- Papers should be submitted electronically via HotCRP. https://pepm17.hotcrp.com/ Authors using LaTeX to prepare their submissions should use the new improved SIGPLAN proceedings style, and specifically the sigplanconf.cls 9pt template. Important Dates --------------- UPDATE: following feedback from potential authors, we have extended the PEPM submission dates by two weeks to avoid clashes with other events. The new deadlines are consequently strict, and there will be no further extensions. For Regular Research Papers and Short Papers: * Abstract submission : Tuesday 27th September 2016 * Paper submission : Friday 30th September 2016 * Author notification : Friday 4th November 2016 * Camera ready : Monday 28th November 2016 For Posters: * Poster submission : Tuesday 8th November 2016 * Author notification : Friday 18th November 2016 * Camera ready : Monday 28th November 2016 PEPM workshop: * Workshop : Monday 16th - Tuesday 17th January 2017 The proceedings will be published 2 weeks pre-conference. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. (For those rare conferences whose proceedings are published in the ACM Digital Library after the conference is over, the official publication date remains the first day of the conference.). PEPM'17 Programme Committee --------------------------- Elvira Albert (Complutense University of Madrid, Spain) Don Batory (University of Texas at Austin, USA) Martin Berger (University of Sussex, UK) Sebastian Erdweg (TU Delft, Netherlands) Andrew Farmer (Facebook, USA) Matthew Flatt (University of Utah, USA) John Gallagher (Roskilde University, Denmark) Robert Glück (DIKU, Denmark) Jurriaan Hage (Utrecht University, Netherlands) Zhenjiang Hu (National Institute of Informatics, Japan) Yukiyoshi Kameyama (University of Tsukuba, Japan) Ilya Klyuchnikov (Facebook, UK) Huiqing Li (EE, UK) Annie Liu (Stony Brook University, USA) Markus Püschel (ETH Zurich, Switzerland) Ryosuke SATO (University of Tokyo, Japan) Sven-Bodo Scholz (Heriot-Watt University, UK) Ulrik Schultz (co-chair) (University of Southern Denmark) Ilya Sergey (University College London, UK) Chung-chieh Shan (Indiana University, USA) Tijs van der Storm (Centrum Wiskunde & Informatica, Netherlands) Jeremy Yallop (co-chair) (University of Cambridge, UK) From lsp at informatik.uni-kiel.de Sun Sep 4 15:27:21 2016 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Sun, 4 Sep 2016 17:27:21 +0200 Subject: [Haskell-cafe] [ANN] brittany - haskell source code formatting tool - experimental/alpha Message-ID: <0de3e66e-f6d6-316a-7a0c-59df8a5c54b8@informatik.uni-kiel.de> Greetings, I am happy to announce a first alpha release of brittany (0.7.0.0), a haskell source code formatting tool based on ghc-exactprint [2] (and thus ghc's parser). https://github.com/lspitzner/brittany Two small feature cases that brittany would produce/leave unmodified: > -- Newlines are used sparingly: Only after "do" and when the > -- `liftBaseOpDiscard` application would lead to overflowing 80 columns. > main :: IO () > main = do > pool <- createPostgresqlPool (toS databaseConnectionString) 10 > initiate $ \chan -> forever $ do > flip runDbConn pool $ do > makeSureQueueIsFull chan > void $ liftBaseOpDiscard (consumeMsgs chan responseQueue Ack) > (uncurry processMsg) > threadDelay 1000000 > -- Alignment of patterns > go [] "" = True > go [WildCard ] "" = True > go (WildCard :rest) (c:cs) = go rest (c : cs) || go (WildCard : rest) cs > go (Union globs:rest) cs = any (\glob -> go (glob ++ rest) cs) globs > go [] (_:_) = False > go (_:_) "" = False Yet this is an alpha release, for the following reasons: - Brittany currently only transforms top-level type signatures and (function) bindings. - Not all syntactical constructs (even of plain 2010 haskell) are understood. All common constructs should work, but "common" is purely subjective. - Not all (syntactic) extensions are supported, either. - Needs more testing. (And less than a hundred automated testcases is not very much to explore every syntactic corner of haskell.) On the other hand - I have started using the tool successfully, albeit selectively. - There are checks in place that detect 1) if output is not valid haskell or 2) if source comments are not transcribed to the output. That is, running into non-handled cases should lead to error messages that are harmless, not into any silent it-overwrote-my-code-with-garbage. *How to build?* Brittany requires ghc-8. See https://github.com/lspitzner/brittany#building A hackage release is not planned yet. *Brittany's formatting style* Currently brittany does _not_ give the user many choices. A few flags exist, most prominently to change the indentation (default 2) or the columns (default 80). I am open to suggestions of how to improve the style, but trying to make everyone happy is not a fulfilling goal for me. *Implementation/documentation/performance* The implementation and its core ideas are not documented. The core algorithm in theory has linear complexity in input size; the implementation probably is quadratic dues to some misuses of plain lists or other such implementation details. Providing at least a high-level overview is on my to-do list. [1] https://github.com/lspitzner/brittany [2] https://hackage.haskell.org/package/ghc-exactprint -- lennart From bhurt at spnz.org Mon Sep 5 18:54:20 2016 From: bhurt at spnz.org (Brian Hurt) Date: Mon, 5 Sep 2016 14:54:20 -0400 Subject: [Haskell-cafe] Applicative Monoid instance Message-ID: This may be a stupid question, but I'm wondering why the following instance isn't in prelude: instance (Applicative m, Monoid a) => Monoid (m a) where mempty = pure mempty mappend a b = mappend <$> a <*> b ? I ask, because being able to use a WriterT (IO ()) STM a to debug complex STM expressions would be really nice. But it depends upon IO () being a monoid. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Mon Sep 5 19:28:21 2016 From: will.yager at gmail.com (Will Yager) Date: Mon, 5 Sep 2016 14:28:21 -0500 Subject: [Haskell-cafe] Applicative Monoid instance In-Reply-To: References: Message-ID: Probably something to do with not making overlapping instances. Not sure. Easiest/best approach is probably to make a newtype wrapper around IO or IO (). Then you can define the monoid instance you want. Will > On Sep 5, 2016, at 13:54, Brian Hurt wrote: > > > This may be a stupid question, but I'm wondering why the following instance isn't in prelude: > > instance (Applicative m, Monoid a) => Monoid (m a) where > mempty = pure mempty > mappend a b = mappend <$> a <*> b > > ? > > I ask, because being able to use a WriterT (IO ()) STM a to debug complex STM expressions would be really nice. But it depends upon IO () being a monoid. > > Brian > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jhenahan at me.com Mon Sep 5 19:32:42 2016 From: jhenahan at me.com (Jack Henahan) Date: Mon, 05 Sep 2016 15:32:42 -0400 Subject: [Haskell-cafe] Applicative Monoid instance In-Reply-To: References: Message-ID: Instance overlap would break a lot of Monad instances (notably [a]), IIRC. This instance comes up on the mailing list every two or three years, it looks like. 2007: https://mail.haskell.org/pipermail/libraries/2007-March/006997.html 2011: https://mail.haskell.org/pipermail/libraries/2011-December/017369.html 2013: http://haskell.1045720.n5.nabble.com/MonadPlus-instance-for-ContT-tp5732028p5732039.html There's a newtype-wrapped version of this in Control.Compose [1] [1]: https://hackage.haskell.org/package/TypeCompose-0.9.11/docs/Control-Compose.html#g:10 Brian Hurt writes: > This may be a stupid question, but I'm wondering why the following instance > isn't in prelude: > > instance (Applicative m, Monoid a) => Monoid (m a) where > mempty = pure mempty > mappend a b = mappend <$> a <*> b > > ? > > I ask, because being able to use a WriterT (IO ()) STM a to debug complex > STM expressions would be really nice. But it depends upon IO () being a > monoid. > > Brian > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Sep 5 20:01:06 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 5 Sep 2016 21:01:06 +0100 Subject: [Haskell-cafe] Applicative Monoid instance In-Reply-To: References: Message-ID: <20160905200106.GE9529@weber> On Mon, Sep 05, 2016 at 02:54:20PM -0400, Brian Hurt wrote: > This may be a stupid question, but I'm wondering why the following instance > isn't in prelude: > > instance (Applicative m, Monoid a) => Monoid (m a) where > mempty = pure mempty > mappend a b = mappend <$> a <*> b > > ? Is 'liftA2 (<>)' not good enough? From guillaumh at gmail.com Mon Sep 5 20:19:41 2016 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Mon, 5 Sep 2016 17:19:41 -0300 Subject: [Haskell-cafe] [ANN] Darcs 2.12.1 release Message-ID: Hi all, The Darcs team is pleased to announce the release of Darcs 2.12.1. The most important changes are: * fixes for building with GHC 8 * drop support for GHC 7.6 and 7.8, i.e., require GHC 7.10 * improvements in `darcs whatsnew` output with irrelevant files (Ben Franksen) This release can be installed via cabal or (soon) stack. The 2.12 branch is also available as a darcs repository from http://darcs.net/releases/branch-2.12 . Thanks! Guillaume Hoffmann From amindfv at gmail.com Mon Sep 5 22:09:13 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 5 Sep 2016 18:09:13 -0400 Subject: [Haskell-cafe] [ANN] Microspec Message-ID: <81D62C63-2304-4F2E-AA22-EF8BADCBCFF5@gmail.com> Happy to announce the release of a new, tiny property-based test framework: Microspec. Microspec has a clean RSpec/HSpec-style API, depends only on base and QuickCheck, runs unit and property-based tests, and is well under 500 lines of code. If you'd like to add tests to your code but don't like increasing the amount of code you depend on, give Microspec a try: https://hackage.haskell.org/package/microspec Happy hacking! Tom From hesselink at gmail.com Tue Sep 6 09:07:11 2016 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 6 Sep 2016 11:07:11 +0200 Subject: [Haskell-cafe] Applicative Monoid instance In-Reply-To: References: Message-ID: I believe this is the App newtype in the monoids package [0]. Erik [0] https://hackage.haskell.org/package/monoids-0.3.2/docs/ Data-Monoid-Applicative.html#t:App On 5 September 2016 at 20:54, Brian Hurt wrote: > > This may be a stupid question, but I'm wondering why the following > instance isn't in prelude: > > instance (Applicative m, Monoid a) => Monoid (m a) where > mempty = pure mempty > mappend a b = mappend <$> a <*> b > > ? > > I ask, because being able to use a WriterT (IO ()) STM a to debug complex > STM expressions would be really nice. But it depends upon IO () being a > monoid. > > Brian > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Sep 6 18:50:04 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 6 Sep 2016 14:50:04 -0400 Subject: [Haskell-cafe] [ANN] brittany - haskell source code formatting tool - experimental/alpha In-Reply-To: <0de3e66e-f6d6-316a-7a0c-59df8a5c54b8@informatik.uni-kiel.de> References: <0de3e66e-f6d6-316a-7a0c-59df8a5c54b8@informatik.uni-kiel.de> Message-ID: Congrats! I look forward to seeing how this develops. On Sun, Sep 4, 2016 at 11:27 AM, lennart spitzner wrote: > Greetings, > > I am happy to announce a first alpha release of brittany (0.7.0.0), > a haskell source code formatting tool based on ghc-exactprint [2] > (and thus ghc's parser). > > > https://github.com/lspitzner/brittany > > > Two small feature cases that brittany would produce/leave unmodified: > >> -- Newlines are used sparingly: Only after "do" and when the >> -- `liftBaseOpDiscard` application would lead to overflowing 80 columns. >> main :: IO () >> main = do >> pool <- createPostgresqlPool (toS databaseConnectionString) 10 >> initiate $ \chan -> forever $ do >> flip runDbConn pool $ do >> makeSureQueueIsFull chan >> void $ liftBaseOpDiscard (consumeMsgs chan responseQueue Ack) >> (uncurry processMsg) >> threadDelay 1000000 > >> -- Alignment of patterns >> go [] "" = True >> go [WildCard ] "" = True >> go (WildCard :rest) (c:cs) = go rest (c : cs) || go (WildCard : rest) cs >> go (Union globs:rest) cs = any (\glob -> go (glob ++ rest) cs) globs >> go [] (_:_) = False >> go (_:_) "" = False > > > Yet this is an alpha release, for the following reasons: > > - Brittany currently only transforms top-level type signatures and (function) > bindings. > - Not all syntactical constructs (even of plain 2010 haskell) are understood. > All common constructs should work, but "common" is purely subjective. > - Not all (syntactic) extensions are supported, either. > - Needs more testing. > (And less than a hundred automated testcases is not very much to explore > every syntactic corner of haskell.) > > On the other hand > > - I have started using the tool successfully, albeit selectively. > - There are checks in place that detect > 1) if output is not valid haskell or > 2) if source comments are not transcribed to the output. > That is, running into non-handled cases should lead to error messages that > are harmless, not into any silent it-overwrote-my-code-with-garbage. > > > *How to build?* > > Brittany requires ghc-8. See https://github.com/lspitzner/brittany#building > > A hackage release is not planned yet. > > > *Brittany's formatting style* > > Currently brittany does _not_ give the user many choices. A few flags exist, > most prominently to change the indentation (default 2) or the columns > (default 80). I am open to suggestions of how to improve the style, but trying > to make everyone happy is not a fulfilling goal for me. > > > *Implementation/documentation/performance* > > The implementation and its core ideas are not documented. The core algorithm > in theory has linear complexity in input size; the implementation probably is > quadratic dues to some misuses of plain lists or other such implementation > details. Providing at least a high-level overview is on my to-do list. > > > [1] https://github.com/lspitzner/brittany > [2] https://hackage.haskell.org/package/ghc-exactprint > > -- lennart > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From siddu.druid at gmail.com Wed Sep 7 17:43:20 2016 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Wed, 07 Sep 2016 17:43:20 +0000 Subject: [Haskell-cafe] Summer 2017 Functional Programming / Math internship Message-ID: Hello, I'm a comp. sci undergrad student in my second year. I'm studying at IIIT-Hyderabad in India. I'm looking for companies that want summer interns for functional programming or pure mathematics related to FP (category theory, type theory, HoTT..). My github is here: http://github.com/bollu Math.stackexhcange: http://math.stackexchange.com/ users/261373/siddharth-bhat Thanks, Siddharth -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjt464 at gmail.com Wed Sep 7 23:06:43 2016 From: mjt464 at gmail.com (mike thomas) Date: Thu, 8 Sep 2016 09:06:43 +1000 Subject: [Haskell-cafe] Aeson parsing of GeoJSON geometries Message-ID: Hi all. Having returned to commercial software development after a 10 year break in environmental regulation and travel, it was not long before I was using my favorite language Haskell, fortunately, as part of my job this time. Haskell has changed in many ways since last I used it, and I am having an internal (lack of) knowledge collision with the problem below: As set out in the example below, given a polygon as GeoJSON from a Postgis enabled Postgres datasbase, I want to get to a list of Double tuples: [(Double,Double)], using Aeson, to draw some polygons. I am stopped at the point of dismembering the nested coordinate arrays. With Stackage nightly-2016-09-01 ghci, and the series of functions defined at the end of this message, I get a runtime type error regarding Vectors, which baffles me. Question 1. Why does Aeson nest the arrays using list syntax around the Array type constructor arguments? Question 2. How do I best convert this part of the AST: "(Array [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]])" to a list of Double tuples? I've tried several variations of the function dropOuterArray to try and resolve this run-time error, with no success. All help welcome, and thanks for your time Mike. ========= GHCI Session With Error ====================== p = parseGeoJSONGeometry "{\"type\":\"Polygon\",\"coordinates\":[[[4.5305923601,50.6585120423],[4.5307511543,50.657719833],[4.5310580333,50.657539732],[4.5309023972,50.6584422261],[4.5308797482,50.6586166629],[4.5305923601,50.6585120423]]]}" p (Just (String "Polygon"),Just (Array [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]])) p1 = dropOuterArrayJ (snd p) p1 [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]] p2 = dropOuterArray p1 :151:21: error: • Couldn't match type ‘Data.Vector.Vector Value’ with ‘Value’ Expected type: Value Actual type: Array • In the first argument of ‘dropOuterArray’, namely ‘p1’ In the expression: dropOuterArray p1 In an equation for ‘p2’: p2 = dropOuterArray p1 ============ Code ==================== {-# LANGUAGE OverloadedStrings, DeriveGeneric, DeriveAnyClass, ScopedTypeVariables, LambdaCase, FlexibleContexts #-} module GeoJSONGeometry ( parseGeoJSONGeometry ,Coordinates ,dropOuterArrayJ ,dropOuterArray ,Pt ,gTypeString ) where import Data.Aeson import Data.Aeson.Types --(parse, parseMaybe, parseEither, Value(..)) import GHC.Generics import Data.ByteString.Lazy.Char8 import Data.HashMap.Strict import qualified Data.Vector as V import Data.Either.Extra (fromRight) import Data.Maybe (fromJust) import Control.Applicative import Codec.Picture import Graphics.Rasterific import Graphics.Rasterific.Texture import GHC.Generics parseGeoJSONGeometry gjg = let eresult = (eitherDecode (pack gjg)) :: Either String Object -- Value -- Object result = (fromRight eresult) gType = Data.HashMap.Strict.lookup "type" result gCoords = Data.HashMap.Strict.lookup "coordinates" result in (gType, gCoords) gTypeString (Just (Data.Aeson.Types.String s)) = s dropOuterArrayJ (Just (Array u)) = u dropOuterArray (Array u) = u -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at brisammon.fastmail.fm Thu Sep 8 01:21:43 2016 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Wed, 7 Sep 2016 21:21:43 -0400 Subject: [Haskell-cafe] regex and Unicode Message-ID: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> I tried to write a program using Text.Regex.PCRE to search through a UTF8-encoded document. It appears that the presence of non-breaking-space characters (code point 160) triggers some weird behavior in my program. This is using the Debian stable(Jessie) packages of ghc 7.6.3 and libraries. Now I find myself at a fork in the road, not sure which direction to head in. Do I: 1) Continue looking (or get help with looking) for bugs in my code? (I have this reduced to a pretty small test case) 2) Assemble a bug-report against debian? 3) Assemble a bug-report against Text.Regex.PCRE (or Text.Regex.Base) for "upstream" 4) Uninstall Text.Regex.PCRE (and/or some other packages) and switch to something that works with Unicode/UTF8? Any ideas? From fa-ml at ariis.it Thu Sep 8 02:46:10 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 8 Sep 2016 04:46:10 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> Message-ID: <20160908024610.GA1178@casa.casa> On Wed, Sep 07, 2016 at 09:21:43PM -0400, Brian Sammon wrote: > I tried to write a program using Text.Regex.PCRE to search through a UTF8-encoded document. It appears that the presence of non-breaking-space characters (code point 160) triggers some weird behavior in my program. > > This is using the Debian stable(Jessie) packages of ghc 7.6.3 and libraries. > > Now I find myself at a fork in the road, not sure which direction to head in. > > Do I: > 1) Continue looking (or get help with looking) for bugs in my code? (I > have this reduced to a pretty small test case) > 2) Assemble a bug-report against debian? > 3) Assemble a bug-report against Text.Regex.PCRE (or Text.Regex.Base) for > "upstream" > 4) Uninstall Text.Regex.PCRE (and/or some other packages) and switch to > something that works with Unicode/UTF8? I am pretty sure pcre-light has an utf8 mode. Is swapping the two modules to check if bug persists feasible? From simons at nospf.cryp.to Thu Sep 8 06:42:10 2016 From: simons at nospf.cryp.to (Peter Simons) Date: Thu, 08 Sep 2016 08:42:10 +0200 Subject: [Haskell-cafe] regex and Unicode References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> Message-ID: <874m5qvqnx.fsf@write-only.cryp.to> Hi Brian, > I tried to write a program using Text.Regex.PCRE to search through a > UTF8-encoded document. It appears that the presence of non-breaking-space > characters (code point 160) triggers some weird behavior in my program. I seem to recall that regex-pcre simply binds to the system's pcre library and effectively lets that library do all the work. Now, libpcre has full Unicode support, but that needs to be enabled at compile time to be available. I believe "--enable-unicode-properties" is the appropriate configure flag, but I don't know for sure. Anyway, my point is that your system's libpcre may or may not have that feature enabled. If it does not, then regex-pcre won't be able to deal with Unicode characters properly and that issue should be reported to Debian. If your system library *has* Unicode support, then this issue might be a caused by a bug in regex-pcre (unlikely) or in your code that uses it (more likely). I hope this helps, Peter From jo at durchholz.org Thu Sep 8 08:30:49 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 8 Sep 2016 10:30:49 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <874m5qvqnx.fsf@write-only.cryp.to> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> Message-ID: <67ec868e-d190-f1ca-d0b0-22158af4541a@durchholz.org> Am 08.09.2016 um 08:42 schrieb Peter Simons: > Anyway, my point > is that your system's libpcre may or may not have that feature enabled. > If it does not, then regex-pcre won't be able to deal with Unicode > characters properly and that issue should be reported to Debian. I'd be surprised if that's what's happening; Debian has been all-Unicode for quite a while now, and PCRE libraries are high-profile enough that lack of Unicode support would have been reported long ago. I dimly recall that there are multiple PCRE libraries in Debian, with subtle differences. I could imagine that one of them operates in 8-bit mode by default and wants a flag somewhere to activate Unicode processing. From haskell-cafe at brisammon.fastmail.fm Thu Sep 8 08:53:13 2016 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Thu, 8 Sep 2016 04:53:13 -0400 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <874m5qvqnx.fsf@write-only.cryp.to> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> Message-ID: <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> I have a test-case here if anyone would like to look at it and give me a "Works For Me" or "Your code's wrong" or something. The program should (i.e. I expect it to) report that it found "Page Title", but in my case, it says it found "age Title'". -------------- next part -------------- A non-text attachment was scrubbed... Name: test Type: application/octet-stream Size: 399 bytes Desc: not available URL: From fa-ml at ariis.it Thu Sep 8 08:52:46 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 8 Sep 2016 10:52:46 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> Message-ID: <20160908085246.GA2383@casa.casa> On Thu, Sep 08, 2016 at 04:53:13AM -0400, Brian Sammon wrote: > I have a test-case here if anyone would like to look at it and give > me a "Works For Me" or "Your code's wrong" or something. > > The program should (i.e. I expect it to) report that it found "Page > Title", but in my case, it says it found "age Title'". $ runghc test.hs title is |Page Title| Debian stable (Jessie). Maybe locale is interfering with something? Mine is LANG=en_GB.UTF-8 LANGUAGE=en_GB:en From haskell-cafe at brisammon.fastmail.fm Thu Sep 8 09:14:11 2016 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Thu, 8 Sep 2016 05:14:11 -0400 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160908085246.GA2383@casa.casa> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> <20160908085246.GA2383@casa.casa> Message-ID: <20160908051411.4827f1d3e21c43134eb7c1c1@brisammon.fastmail.fm> On Thu, 8 Sep 2016 10:52:46 +0200 Francesco Ariis wrote: > $ runghc test.hs > title is |Page Title| > > Debian stable (Jessie). Maybe locale is interfering with something? Hmm... are you running debian-packaged ghc 7.6.3 , as I am? From fa-ml at ariis.it Thu Sep 8 09:36:58 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 8 Sep 2016 11:36:58 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160908051411.4827f1d3e21c43134eb7c1c1@brisammon.fastmail.fm> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> <20160908085246.GA2383@casa.casa> <20160908051411.4827f1d3e21c43134eb7c1c1@brisammon.fastmail.fm> Message-ID: <20160908093658.GA3627@casa.casa> On Thu, Sep 08, 2016 at 05:14:11AM -0400, Brian Sammon wrote: > On Thu, 8 Sep 2016 10:52:46 +0200 > Francesco Ariis wrote: > > > $ runghc test.hs > > title is |Page Title| > > > > Debian stable (Jessie). Maybe locale is interfering with something? > > Hmm... are you running debian-packaged ghc 7.6.3 , as I am? No, GHC 8.0.1, regex-pcre-0.94.4. From fa-ml at ariis.it Thu Sep 8 09:45:22 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 8 Sep 2016 11:45:22 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160908093658.GA3627@casa.casa> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> <20160908085246.GA2383@casa.casa> <20160908051411.4827f1d3e21c43134eb7c1c1@brisammon.fastmail.fm> <20160908093658.GA3627@casa.casa> Message-ID: <20160908094522.GA3879@casa.casa> On Thu, Sep 08, 2016 at 11:36:58AM +0200, Francesco Ariis wrote: > No, GHC 8.0.1, regex-pcre-0.94.4. I'll add that documentation states Using the provided CompOption and ExecOption values and if configUTF8 is True, then you might be able to send UTF8 encoded ByteStrings to PCRE and get sensible results. This is currently untested. Is configUTF8 True on your system (on mine it is)? From monkleyon at googlemail.com Thu Sep 8 10:15:16 2016 From: monkleyon at googlemail.com (MarLinn) Date: Thu, 8 Sep 2016 12:15:16 +0200 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> <874m5qvqnx.fsf@write-only.cryp.to> <20160908045313.f00e5ea5634944d5dd4c8a54@brisammon.fastmail.fm> Message-ID: > I have a test-case here if anyone would like to look at it and give me a "Works For Me" or "Your code's wrong" or something. I got the same wrong output as you. regex-base: 0.93.2 regex-pcre: 0.94.4 GHC: 7.10.3 LANG: en_GB.UTF-8 LANGUAGE: en_GB:en system: debian 8.5 (jessie) configUTF8: returns True pcre lib: 8.35 2014-04-04 From haskell-cafe at brisammon.fastmail.fm Thu Sep 8 19:48:33 2016 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Thu, 8 Sep 2016 15:48:33 -0400 Subject: [Haskell-cafe] regex and Unicode In-Reply-To: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> References: <20160907212143.87bd9324150742bb0704dba7@brisammon.fastmail.fm> Message-ID: <20160908154833.a9565dcd9ccc5f98c90a8b54@brisammon.fastmail.fm> On Wed, 7 Sep 2016 21:21:43 -0400 Brian Sammon wrote: > I tried to write a program using Text.Regex.PCRE to search through a UTF8-> encoded document. It appears that the presence of non-breaking-space > characters (code point 160) triggers some weird behavior in my program. Not sure why I didn't find it with earlier google searches, but today I found this rather interesting thread from a few years back on haskell-cafe: http://haskell-cafe.haskell.narkive.com/OU9UhI0y/ It describes a problem someone was having with GHC 7 and passing strings to Text.Regex.PCRE. There is also a suggested workaround and an explanation that seems to be a very good match for the off-by-one error I was seeing. I can't tell (from that thread or elsewhere on google) if/when/how this bug was fixed, but based on other responses here, it sounds like it was fixed by the time of GHC 8. From dek5 at yandex.ru Thu Sep 8 22:21:11 2016 From: dek5 at yandex.ru (dek5) Date: Fri, 9 Sep 2016 01:21:11 +0300 Subject: [Haskell-cafe] many beautiful things Message-ID: <000048e62b3f$83ee303b$99f58b30$@yandex.ru> Dear! Just take a look at this stuff! There are so many beautiful things here, you should visit the store Sincerely yours, dek5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Fri Sep 9 13:01:31 2016 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 9 Sep 2016 15:01:31 +0200 Subject: [Haskell-cafe] Aeson parsing of GeoJSON geometries In-Reply-To: References: Message-ID: On Thu, Sep 8, 2016 at 1:06 AM, mike thomas wrote: > Hi all. > > Having returned to commercial software development after a 10 year break > in environmental regulation and travel, it was not long before I was using > my favorite language Haskell, fortunately, as part of my job this time. > > Haskell has changed in many ways since last I used it, and I am having an > internal (lack of) knowledge collision with the problem below: > > As set out in the example below, given a polygon as GeoJSON from a Postgis > enabled Postgres datasbase, I want to get to a list of Double tuples: > [(Double,Double)], using Aeson, to draw some polygons. I am stopped at the > point of dismembering the nested coordinate arrays. > > With Stackage nightly-2016-09-01 ghci, and the series of functions defined > at the end of this message, I get a runtime type error regarding Vectors, > which baffles me. > > Question 1. Why does Aeson nest the arrays using list syntax around the > Array type constructor arguments? > This is just the Show instance for Values, you can `encode' to print the actual json representation. > Question 2. How do I best convert this part of the AST: > > "(Array [Array [Array [Number 4.5305923601,Number 50.6585120423],Array > [Number 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number > 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array > [Number 4.5308797482,Number 50.6586166629],Array [Number > 4.5305923601,Number 50.6585120423]]])" > > to a list of Double tuples? > I usually try to avoid doing custom parsing, it's much easier to use an existing instance when you can. Try this: #!/usr/bin/env stack -- stack --resolver nightly-2016-09-01 --install-ghc runghc --package aeson {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE OverloadedStrings #-} module Main (main) where import GHC.Generics import Data.Aeson data Geo = Geo { coordinates :: [[(Double, Double)]] } deriving (Generic, Show) instance ToJSON Geo instance FromJSON Geo main :: IO () main = do let ex1 = eitherDecode "[[1,2]]" :: Either String Value print ex1 print $ fmap encode ex1 let ex2 = "{\"type\":\"Polygon\",\"coordinates\":[[[4.5305923601,50.6585120423],[4.5307511543,50.657719833],[4.5310580333,50.657539732],[4.5309023972,50.6584422261],[4.5308797482,50.6586166629],[4.5305923601,50.6585120423]]]}" print (eitherDecode ex2 :: Either String Geo) > I've tried several variations of the function dropOuterArray to try and > resolve this run-time error, with no success. > > All help welcome, and thanks for your time > > Mike. > > ========= GHCI Session With Error ====================== > > p = parseGeoJSONGeometry "{\"type\":\"Polygon\",\" > coordinates\":[[[4.5305923601,50.6585120423],[4.5307511543, > 50.657719833],[4.5310580333,50.657539732],[4.5309023972, > 50.6584422261],[4.5308797482,50.6586166629],[4.5305923601, > 50.6585120423]]]}" > > p (Just (String "Polygon"),Just (Array [Array [Array [Number > 4.5305923601,Number 50.6585120423],Array [Number 4.5307511543,Number > 50.657719833],Array [Number 4.5310580333,Number 50.657539732],Array [Number > 4.5309023972,Number 50.6584422261],Array [Number 4.5308797482,Number > 50.6586166629],Array [Number 4.5305923601,Number 50.6585120423]]])) > > p1 = dropOuterArrayJ (snd p) > > p1 [Array [Array [Number 4.5305923601,Number 50.6585120423],Array [Number > 4.5307511543,Number 50.657719833],Array [Number 4.5310580333,Number > 50.657539732],Array [Number 4.5309023972,Number 50.6584422261],Array > [Number 4.5308797482,Number 50.6586166629],Array [Number > 4.5305923601,Number 50.6585120423]]] > > p2 = dropOuterArray p1 > > :151:21: error: • Couldn't match type ‘Data.Vector.Vector Value’ with > ‘Value’ Expected type: Value Actual type: Array • In the first argument of > ‘dropOuterArray’, namely ‘p1’ In the expression: dropOuterArray p1 In an > equation for ‘p2’: p2 = dropOuterArray p1 > > ============ Code ==================== > > {-# LANGUAGE OverloadedStrings, DeriveGeneric, DeriveAnyClass, > ScopedTypeVariables, LambdaCase, FlexibleContexts #-} > > module GeoJSONGeometry ( > parseGeoJSONGeometry > ,Coordinates > ,dropOuterArrayJ > ,dropOuterArray > ,Pt > ,gTypeString > ) where > > import Data.Aeson > import Data.Aeson.Types --(parse, parseMaybe, parseEither, Value(..)) > import GHC.Generics > import Data.ByteString.Lazy.Char8 > import Data.HashMap.Strict > import qualified Data.Vector as V > import Data.Either.Extra (fromRight) > import Data.Maybe (fromJust) > import Control.Applicative > > import Codec.Picture > import Graphics.Rasterific > import Graphics.Rasterific.Texture > > import GHC.Generics > > > parseGeoJSONGeometry gjg = > let > eresult = (eitherDecode (pack gjg)) :: Either String Object -- Value > -- Object > result = (fromRight eresult) > gType = Data.HashMap.Strict.lookup "type" result > gCoords = Data.HashMap.Strict.lookup "coordinates" result > in > (gType, gCoords) > > gTypeString (Just (Data.Aeson.Types.String s)) = s > > dropOuterArrayJ (Just (Array u)) = u > > > dropOuterArray (Array u) = u > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian.nadales at gmail.com Fri Sep 9 14:34:33 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Fri, 9 Sep 2016 16:34:33 +0200 Subject: [Haskell-cafe] Haskell conferences in Europe Message-ID: Hi, Do you know of any Haskell conferences in Europe for 2016/2017? Also, do you know if there is a centralized place where this information can be found? Thanks in advance, Damian. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Sep 9 14:38:09 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 9 Sep 2016 15:38:09 +0100 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: References: Message-ID: <20160909143809.GU12700@weber> On Fri, Sep 09, 2016 at 04:34:33PM +0200, Damian Nadales wrote: > Do you know of any Haskell conferences in Europe for 2016/2017? Haskell eXchange (London) is on 6th and 7th October 2016: https://skillsmatter.com/conferences/7276-haskell-exchange-2016 (I'm a bit surprised I haven't seen it advertised on this list yet.) Tom From damian.nadales at gmail.com Fri Sep 9 14:40:26 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Fri, 9 Sep 2016 16:40:26 +0200 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: <20160909143809.GU12700@weber> References: <20160909143809.GU12700@weber> Message-ID: On Fri, Sep 9, 2016 at 4:38 PM, Tom Ellis wrote: > On Fri, Sep 09, 2016 at 04:34:33PM +0200, Damian Nadales wrote: >> Do you know of any Haskell conferences in Europe for 2016/2017? > > Haskell eXchange (London) is on 6th and 7th October 2016: > > https://skillsmatter.com/conferences/7276-haskell-exchange-2016 > > (I'm a bit surprised I haven't seen it advertised on this list yet.) > Indeed. That's the first match I got in Google. I'll do my best to be there! Thanks. > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From dominic.p.mulligan at googlemail.com Fri Sep 9 14:53:01 2016 From: dominic.p.mulligan at googlemail.com (Dominic Mulligan) Date: Fri, 9 Sep 2016 15:53:01 +0100 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: References: Message-ID: Not restricted to Haskell, but: the fourth iteration of the South of England Regional Programming Languages Seminar is being held at Imperial College on 27th September (details, and a list of accepted talks is available here: http://srepls4.doc.ic.ac.uk/). Attendance and lunch is free provided you fill out the Doodle poll on the meeting website beforehand, and many of the talks and will be of interest to Haskellers and other functional programmers, as anybody on this list who has attended previous iterations can hopefully attest. On 9 September 2016 at 15:34, Damian Nadales wrote: > Hi, > > Do you know of any Haskell conferences in Europe for 2016/2017? Also, > do you know if there is a centralized place where this information can > be found? > > Thanks in advance, > Damian. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From malcolm.wallace at me.com Fri Sep 9 15:10:12 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 09 Sep 2016 16:10:12 +0100 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: References: Message-ID: <2340B12F-A63F-4ACE-B023-3B7D3D0A6427@me.com> Also, ICFP 2017 and associated workshops (e.g. Haskell Symposium) will be in Oxford, UK, Sun 3 - Sat 9 September 2017. Fuller information will probably appear on http://www.icfpconference.org shortly after this year's ICFP in Japan concludes, in a couple of weeks time. Regards, Malcolm On 9 Sep 2016, at 15:53, Dominic Mulligan wrote: > Not restricted to Haskell, but: the fourth iteration of the South of > England Regional Programming Languages Seminar is being held at > Imperial College on 27th September (details, and a list of accepted > talks is available here: http://srepls4.doc.ic.ac.uk/). Attendance > and lunch is free provided you fill out the Doodle poll on the meeting > website beforehand, and many of the talks and will be of interest to > Haskellers and other functional programmers, as anybody on this list > who has attended previous iterations can hopefully attest. > > On 9 September 2016 at 15:34, Damian Nadales wrote: >> Hi, >> >> Do you know of any Haskell conferences in Europe for 2016/2017? Also, >> do you know if there is a centralized place where this information can >> be found? >> >> Thanks in advance, >> Damian. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From andres at well-typed.com Fri Sep 9 15:32:13 2016 From: andres at well-typed.com (Andres =?iso-8859-1?B?TPZo?=) Date: Fri, 9 Sep 2016 16:32:13 +0100 Subject: [Haskell-cafe] Haskell eXchange and related events -- Call for Participation Message-ID: <20160909153213.xk2tsj6asqwj55og@nullzig.kosmikus.org> Hi everyone. As Tom Ellis has correctly pointed out in another thread, I should have announced the Haskell eXchange on this list. Let me do that now: ===================================================================== Haskell eXchange 2016 London, 6-7 October 2016 ===================================================================== The Haskell eXchange is a general Haskell conference aimed at Haskell enthusiasts of all skill levels. The Haskell eXchange is organized annually, and 2016 is its fifth year. For the second year in a row, the venue will be Skills Matter’s CodeNode, where we have space for three parallel tracks. New this year: a large number of beginner-focused talks. At all times, at least one track will be available with a talk aimed at (relative) newcomers to Haskell. Of course, there are also plenty of talks on more advanced topics. Keynote speakers: Don Stewart, Conor McBride, Graham Hutton, Simon Peyton Jones Talks and workshops (some changes may still occur) by: Julian Arni, Christiaan Baaij, Thomas van Binsbergen, Mathieu Boespflug, Lars Brünjes, Ben Clifford, Philip Cunningham, Tom Ellis, Matthias Fischmann, Oleg Grenrus, Nickolay Kudasov, Robert Henderson, Csaba Hruska, Robin Kay, Csongor Kiss, Steven Kutsch, Kris Jenkins, David Luposchainsky, Neil Mitchell, Andrey Mokhov, Romeo Moura, Jann Müller, Boldizsár Németh, Andor Penzes, Ivan Perez, Michał Płachta, Nicolas Pouillard, Arian van Putten, Andrzej Rybczak, Jeremy Singer, Nicolas Wu Homepage and registration: https://skillsmatter.com/conferences/7276-haskell-exchange-2016 If you're interested in the Haskell eXchange, you might also be interested in the Haskell eXchange Haskell Hackathon and/or in the Haskell courses (2-day introductory, 1-day on types, 2-day on performance) offered by Well-Typed on the surrounding days. More info here: http://www.well-typed.com/blog/125/ Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England From mail at joachim-breitner.de Fri Sep 9 18:31:35 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 09 Sep 2016 14:31:35 -0400 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: References: Message-ID: <1473445895.8077.5.camel@joachim-breitner.de> Hi, Am Freitag, den 09.09.2016, 16:34 +0200 schrieb Damian Nadales: > Do you know of any Haskell conferences in Europe for 2016/2017? Also, > do you know if there is a centralized place where this information > can be found? just next week, there is HAL: http://hal2016.haskell.org/ Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From ch.howard at zoho.com Sat Sep 10 03:12:56 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Fri, 9 Sep 2016 19:12:56 -0800 Subject: [Haskell-cafe] Stable Random Number Generator? Message-ID: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> Hi. What would be a good library if I want a pseudo-RNG which is stable across platforms and compiler versions? By "stable" I mean always produces the same values after being given a particular seed. I have a number of projects which involve generating some kind of pattern or graphic, where the algorithm is either fed values from a RNG, or starts with initial conditions generated by an RNG. So, I want an RNG which which produce the same results when different users on different systems enter the same seed. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu). From thomas.dubuisson at gmail.com Sat Sep 10 03:23:44 2016 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Fri, 9 Sep 2016 20:23:44 -0700 Subject: [Haskell-cafe] Stable Random Number Generator? In-Reply-To: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> References: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> Message-ID: My recommendation in the past, and now, continues to be this: If you want something stable then use something that implements a standard. I believe MWC generators implement a standard (up to you if you like them). The DRBG package Hash and HMAC generators implement a standard. The stream ciphers available on Hackage all implement a well specified unchanging algorithm and produce a stream of random bits from a seed (ChaCha20 from cryptonite, AES-CTR from many places, etc etc). -Thomas On Fri, Sep 9, 2016 at 8:12 PM, Christopher Howard wrote: > Hi. What would be a good library if I want a pseudo-RNG which is stable > across platforms and compiler versions? By "stable" I mean always produces > the same values after being given a particular seed. I have a number of > projects which involve generating some kind of pattern or graphic, where the > algorithm is either fed values from a RNG, or starts with initial conditions > generated by an RNG. So, I want an RNG which which produce the same results > when different users on different systems enter the same seed. > > -- > https://qlfiles.net > My PGP public key ID is 0x340EA95A (pgp.mit.edu). > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From damian.nadales at gmail.com Sat Sep 10 06:22:10 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Sat, 10 Sep 2016 08:22:10 +0200 Subject: [Haskell-cafe] Haskell conferences in Europe In-Reply-To: <1473445895.8077.5.camel@joachim-breitner.de> References: <1473445895.8077.5.camel@joachim-breitner.de> Message-ID: Thank you all for your answers. Also, feel free to update the wiki if necessary: https://wiki.haskell.org/Conferences I hope I can make it to any of these. Best, Damian. On Fri, Sep 9, 2016 at 8:31 PM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 09.09.2016, 16:34 +0200 schrieb Damian Nadales: >> Do you know of any Haskell conferences in Europe for 2016/2017? Also, >> do you know if there is a centralized place where this information >> can be found? > > just next week, there is HAL: > http://hal2016.haskell.org/ > > Greetings, > Joachim > > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From stephen.tetley at gmail.com Sat Sep 10 08:08:36 2016 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat, 10 Sep 2016 09:08:36 +0100 Subject: [Haskell-cafe] Stable Random Number Generator? In-Reply-To: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> References: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> Message-ID: Jerzy Karczmarzcuk has often mentioned ergodic functions on this mailing list which have the stability properties you are after, and for the generation of graphics and the like their "not quite randomness" should have no dishonour. You should be able to crib the one (written in Clean) from this paper. https://karczmarczuk.users.greyc.fr/arpap/texturf.pdf On 10 September 2016 at 04:12, Christopher Howard wrote: > Hi. What would be a good library if I want a pseudo-RNG which is stable > across platforms and compiler versions? By "stable" I mean always produces > the same values after being given a particular seed. I have a number of > projects which involve generating some kind of pattern or graphic, where the > algorithm is either fed values from a RNG, or starts with initial conditions > generated by an RNG. So, I want an RNG which which produce the same results > when different users on different systems enter the same seed. > > -- > https://qlfiles.net > My PGP public key ID is 0x340EA95A (pgp.mit.edu). > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From novadenizen at gmail.com Sat Sep 10 17:41:24 2016 From: novadenizen at gmail.com (Ken Bateman) Date: Sat, 10 Sep 2016 13:41:24 -0400 Subject: [Haskell-cafe] Stable Random Number Generator? In-Reply-To: References: <0988549f-f549-5986-2996-32bac64208d0@zoho.com> Message-ID: I agree with the answers so far. I just want to warn you away from the default Random class instances for basic datatypes from the random package. They are not guaranteed stable across library versions. Their implementations have changed. On Sep 10, 2016 4:08 AM, "Stephen Tetley" wrote: > Jerzy Karczmarzcuk has often mentioned ergodic functions on this > mailing list which have the stability properties you are after, and > for the generation of graphics and the like their "not quite > randomness" should have no dishonour. > > > You should be able to crib the one (written in Clean) from this paper. > https://karczmarczuk.users.greyc.fr/arpap/texturf.pdf > > On 10 September 2016 at 04:12, Christopher Howard > wrote: > > Hi. What would be a good library if I want a pseudo-RNG which is stable > > across platforms and compiler versions? By "stable" I mean always > produces > > the same values after being given a particular seed. I have a number of > > projects which involve generating some kind of pattern or graphic, where > the > > algorithm is either fed values from a RNG, or starts with initial > conditions > > generated by an RNG. So, I want an RNG which which produce the same > results > > when different users on different systems enter the same seed. > > > > -- > > https://qlfiles.net > > My PGP public key ID is 0x340EA95A (pgp.mit.edu). > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Sat Sep 10 20:14:39 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 11 Sep 2016 01:44:39 +0530 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets Message-ID: Hi, Some time back I wrote a small Haskell library to parse the old MS excel format (.xls). There were libraries to parse ".xlsx" but there was none for ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) so that others looking for something similar can find and use it. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sat Sep 10 20:26:00 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 10 Sep 2016 22:26:00 +0200 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: Message-ID: <20160910202600.GA8986@casa.casa> On Sun, Sep 11, 2016 at 01:44:39AM +0530, Harendra Kumar wrote: > Some time back I wrote a small Haskell library to parse the old MS excel > format (.xls). There were libraries to parse ".xlsx" but there was none for > ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) so > that others looking for something similar can find and use it. Sweet, this is extremely useful! From 123.wizek at gmail.com Sat Sep 10 22:43:04 2016 From: 123.wizek at gmail.com (=?UTF-8?Q?Mil=C3=A1n_Nagy?=) Date: Sat, 10 Sep 2016 15:43:04 -0700 (PDT) Subject: [Haskell-cafe] [ANN] hs-di; dependency injection library for Haskell; deterministic even for fairly arbitrary and complex IO code Message-ID: Hi, Are there people here who are interested in the techniques of unit testing, mocking, dependency injection? Reproducible, deterministic tests, even for fairly arbitrary and complex IO code? There is a recent project of mine that strives to do all of the above: https://github.com/Wizek/hs-di I'd be curious to hear what some of you may think about it. I'm also looking to find at least one other person who can get excited about the potential of these techniques; someone who could be interested in discussing certain details of this project and related questions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sat Sep 10 23:24:35 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sat, 10 Sep 2016 16:24:35 -0700 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: <20160910202600.GA8986@casa.casa> References: <20160910202600.GA8986@casa.casa> Message-ID: Why not Hackage? :) On Sat, Sep 10, 2016 at 1:26 PM, Francesco Ariis wrote: > On Sun, Sep 11, 2016 at 01:44:39AM +0530, Harendra Kumar wrote: > > Some time back I wrote a small Haskell library to parse the old MS excel > > format (.xls). There were libraries to parse ".xlsx" but there was none > for > > ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) > so > > that others looking for something similar can find and use it. > > Sweet, this is extremely useful! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Sun Sep 11 00:10:32 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 11 Sep 2016 05:40:32 +0530 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> Message-ID: Even though it works perfectly well for my use cases, I wanted to carefully review and also fix a couple of todos before pushing to Hackage. But never got time to do that yet, its been more than 6 months I wrote this. I thought I will at least let people know in case someone is looking for something like this. -harendra On 11 September 2016 at 04:54, Theodore Lief Gannon wrote: > Why not Hackage? :) > > On Sat, Sep 10, 2016 at 1:26 PM, Francesco Ariis wrote: > >> On Sun, Sep 11, 2016 at 01:44:39AM +0530, Harendra Kumar wrote: >> > Some time back I wrote a small Haskell library to parse the old MS excel >> > format (.xls). There were libraries to parse ".xlsx" but there was none >> for >> > ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) >> so >> > that others looking for something similar can find and use it. >> >> Sweet, this is extremely useful! >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Sun Sep 11 07:43:09 2016 From: tdammers at gmail.com (Tobias Dammers) Date: Sun, 11 Sep 2016 09:43:09 +0200 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> Message-ID: I think you should upload it to hackage anyway. There are plenty of work-in-progress packages there, it's not like "it's on Hackage" indicates "production ready", and it would lower the barrier to adoption and contribution. And if you don't want to maintain it yourself, maybe you can find someone who does. On Sep 11, 2016 2:10 AM, "Harendra Kumar" wrote: > Even though it works perfectly well for my use cases, I wanted to > carefully review and also fix a couple of todos before pushing to Hackage. > But never got time to do that yet, its been more than 6 months I wrote > this. I thought I will at least let people know in case someone is looking > for something like this. > > -harendra > > On 11 September 2016 at 04:54, Theodore Lief Gannon > wrote: > >> Why not Hackage? :) >> >> On Sat, Sep 10, 2016 at 1:26 PM, Francesco Ariis wrote: >> >>> On Sun, Sep 11, 2016 at 01:44:39AM +0530, Harendra Kumar wrote: >>> > Some time back I wrote a small Haskell library to parse the old MS >>> excel >>> > format (.xls). There were libraries to parse ".xlsx" but there was >>> none for >>> > ".xls". I uploaded it on github (https://github.com/harendra-kumar/xls) >>> so >>> > that others looking for something similar can find and use it. >>> >>> Sweet, this is extremely useful! >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Sep 11 08:18:13 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 11 Sep 2016 10:18:13 +0200 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> Message-ID: <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> Am 11.09.2016 um 02:10 schrieb Harendra Kumar: > Even though it works perfectly well for my use cases, I wanted to carefully > review and also fix a couple of todos before pushing to Hackage. But never > got time to do that yet, its been more than 6 months I wrote this. As Tobias said, you should upload it anyway. Just make sure to properly document what it can and cannot do, and make that information readily accessible to anybody who takes a first look at it in Hackage. From tanuki at gmail.com Sun Sep 11 10:48:38 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sun, 11 Sep 2016 03:48:38 -0700 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> References: <20160910202600.GA8986@casa.casa> <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> Message-ID: In fact, there's a "Stability" field where you can indicate that it's officially experimental. On Sun, Sep 11, 2016 at 1:18 AM, Joachim Durchholz wrote: > Am 11.09.2016 um 02:10 schrieb Harendra Kumar: > >> Even though it works perfectly well for my use cases, I wanted to >> carefully >> review and also fix a couple of todos before pushing to Hackage. But never >> got time to do that yet, its been more than 6 months I wrote this. >> > > As Tobias said, you should upload it anyway. > Just make sure to properly document what it can and cannot do, and make > that information readily accessible to anybody who takes a first look at it > in Hackage. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sun Sep 11 11:01:06 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 11 Sep 2016 12:01:06 +0100 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> Message-ID: <20160911110106.GF22712@weber> On Sun, Sep 11, 2016 at 03:48:38AM -0700, Theodore Lief Gannon wrote: > In fact, there's a "Stability" field where you can indicate that it's > officially experimental. Six years ago Simon Marlow pronounced that the "Stability" field was "mostly defunct now, and shouldn't be used" https://stackoverflow.com/questions/3841218/conventions-for-stability-field-of-cabal-packages/3847493#3847493 Tom From tanuki at gmail.com Mon Sep 12 09:49:34 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Mon, 12 Sep 2016 02:49:34 -0700 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: <20160911110106.GF22712@weber> References: <20160910202600.GA8986@casa.casa> <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> <20160911110106.GF22712@weber> Message-ID: ...and, "it will probably be replaced by something meaningful in the future." But it hasn't, nor has it been removed, and it's a better signal than no signal at all. On Sun, Sep 11, 2016 at 4:01 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Sun, Sep 11, 2016 at 03:48:38AM -0700, Theodore Lief Gannon wrote: > > In fact, there's a "Stability" field where you can indicate that it's > > officially experimental. > > Six years ago Simon Marlow pronounced that the "Stability" field was > "mostly > defunct now, and shouldn't be used" > > https://stackoverflow.com/questions/3841218/conventions- > for-stability-field-of-cabal-packages/3847493#3847493 > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erbalrajs at gmail.com Mon Sep 12 18:08:47 2016 From: erbalrajs at gmail.com (Balraj Singh) Date: Mon, 12 Sep 2016 23:38:47 +0530 Subject: [Haskell-cafe] =?utf-8?q?Facing_issue=3A_=22No_instance_for_=28Fr?= =?utf-8?q?actional_a0=29_arising_from_a_use_of_=E2=80=98it?= =?utf-8?b?4oCZIFRoZSB0eXBlIHZhcmlhYmxlIOKAmGEw4oCZIGlzIGFtYmlndW91?= =?utf-8?q?s=22?= Message-ID: Hi, I am writing a sample code below and getting an error. Please help to resolve it: Code: import Data.List findLoot val [] = 0.0 findLoot val ((x:y:[]):xs) | val == 0 = 0.0 | val < y = ((fromIntegral val) * (fromIntegral x)) / fromIntegral y | val > y = ((div val y)*x) + (findLoot (mod val y) xs) Error: No instance for (Fractional a0) arising from a use of ‘it’ The type variable ‘a0’ is ambiguous Note: there are several potential instances: instance HasResolution a => Fractional (Fixed a) -- Defined in ‘Data.Fixed’ instance Integral a => Fractional (Ratio a) -- Defined in ‘GHC.Real’ instance Fractional Double -- Defined in ‘GHC.Float’ ...plus one other In the first argument of ‘print’, namely ‘it’ In a stmt of an interactive GHCi command: print it Sample Input and Output: Input 1:- val = 50 ((x:y:[]):xs) = [[120, 30], [100,50],[60, 20]] Output 1:- 180.0000 Input 2:- val = 10((x:y:[]):xs) = [[500,30]] Output 2:- 166.6667 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhenahan at me.com Mon Sep 12 18:31:22 2016 From: jhenahan at me.com (Jack Henahan) Date: Mon, 12 Sep 2016 14:31:22 -0400 Subject: [Haskell-cafe] =?utf-8?q?Facing_issue=3A_=22No_instance_for_=28Fr?= =?utf-8?q?actional_a0=29_arising_from_a_use_of_=E2=80=98it=E2=80=99_The_t?= =?utf-8?b?eXBlIHZhcmlhYmxlIOKAmGEw4oCZIGlzIGFtYmlndW91cyI=?= In-Reply-To: References: Message-ID: The inferred type of findLoot is findLoot :: (Integral a, Fractional a) => a -> [[a]] -> a It's impossible to satisfy those constraints. Rewriting like this does what you want, but there's likely a cleaner way to express this algorithm. findLoot :: (Integral a, Fractional b) => a -> [[a]] -> b findLoot val [] = 0.0 findLoot val ((x:y:[]):xs) | val == 0 = 0.0 | val < y = ((fromIntegral val) * (fromIntegral x)) / fromIntegral y | val > y = fromIntegral ((div val y)*x) + (findLoot (mod val y) xs) Balraj Singh writes: > Hi, > > I am writing a sample code below and getting an error. Please help to resolve > it: > > Code: > > import Data.List > > > findLoot val [] = 0.0 > > findLoot val ((x:y:[]):xs) | val == 0 = 0.0 > > | val < y = ((fromIntegral val) * (fromIntegral x)) > / fromIntegral y > > | val > y = ((div val y)*x) + (findLoot (mod val y) > xs) > > > Error: > > No instance for (Fractional a0) arising from a use of ‘it’ > > The type variable ‘a0’ is ambiguous > > Note: there are several potential instances: > > instance HasResolution a => Fractional (Fixed a) > > -- Defined in ‘Data.Fixed’ > > instance Integral a => Fractional (Ratio a) > > -- Defined in ‘GHC.Real’ > > instance Fractional Double -- Defined in ‘GHC.Float’ > > ...plus one other > > In the first argument of ‘print’, namely ‘it’ > > In a stmt of an interactive GHCi command: print it > > > Sample Input and Output: > > Input 1:- > val = 50 > ((x:y:[]):xs) = [[120, 30], [100,50],[60, 20]] > Output 1:- > 180.0000 > > Input 2:- > val = 10 > ((x:y:[]):xs) = [[500,30]] > Output 2:- > 166.6667 -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From jo at durchholz.org Mon Sep 12 18:52:55 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 12 Sep 2016 20:52:55 +0200 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> <20160911110106.GF22712@weber> Message-ID: <71513412-2ac0-d101-7f3b-ed4349b759eb@durchholz.org> The best signal is a compact description of what the library does, and, more importantly, what it does not do. Stability isn't a particularly interesting metric anyway. You want metrics like use case coverage, interface complexity, performance predictability, and you also want the update intensity over time (the shape of the curve correlates with kinds of team activity - you need to validate anything you infer from the curve, but it tells you what things to validate). Am 12.09.2016 um 11:49 schrieb Theodore Lief Gannon: > ...and, "it will probably be replaced by something meaningful in the > future." But it hasn't, nor has it been removed, and it's a better signal > than no signal at all. > > On Sun, Sep 11, 2016 at 4:01 AM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> On Sun, Sep 11, 2016 at 03:48:38AM -0700, Theodore Lief Gannon wrote: >>> In fact, there's a "Stability" field where you can indicate that it's >>> officially experimental. >> >> Six years ago Simon Marlow pronounced that the "Stability" field was >> "mostly >> defunct now, and shouldn't be used" >> >> https://stackoverflow.com/questions/3841218/conventions- >> for-stability-field-of-cabal-packages/3847493#3847493 >> >> Tom From david.feuer at gmail.com Mon Sep 12 20:28:19 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 12 Sep 2016 16:28:19 -0400 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <20160910202600.GA8986@casa.casa> <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> <20160911110106.GF22712@weber> <71513412-2ac0-d101-7f3b-ed4349b759eb@durchholz.org> Message-ID: Also important is the extent to which the maintainers are willing and able to change the library to respond to changes in users' needs and expectations. Parsec, for example, seems to have been largely supplanted by Megaparsec because it failed to evolve. And some libraries need to track developments in implementation techniques, either replacing old techniques or adding new ones alongside. On Sep 12, 2016 2:53 PM, "Joachim Durchholz" wrote: The best signal is a compact description of what the library does, and, more importantly, what it does not do. Stability isn't a particularly interesting metric anyway. You want metrics like use case coverage, interface complexity, performance predictability, and you also want the update intensity over time (the shape of the curve correlates with kinds of team activity - you need to validate anything you infer from the curve, but it tells you what things to validate). Am 12.09.2016 um 11:49 schrieb Theodore Lief Gannon: > ...and, "it will probably be replaced by something meaningful in the > future." But it hasn't, nor has it been removed, and it's a better signal > than no signal at all. > > On Sun, Sep 11, 2016 at 4:01 AM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > On Sun, Sep 11, 2016 at 03:48:38AM -0700, Theodore Lief Gannon wrote: >> >>> In fact, there's a "Stability" field where you can indicate that it's >>> officially experimental. >>> >> >> Six years ago Simon Marlow pronounced that the "Stability" field was >> "mostly >> defunct now, and shouldn't be used" >> >> https://stackoverflow.com/questions/3841218/conventions- >> for-stability-field-of-cabal-packages/3847493#3847493 >> >> Tom >> > _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Mon Sep 12 20:47:55 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 12 Sep 2016 22:47:55 +0200 Subject: [Haskell-cafe] xls: A library for parsing MS excel spreadsheets In-Reply-To: References: <005a4c7b-c5c1-fdb6-308a-ffa0e3ac9399@durchholz.org> <20160911110106.GF22712@weber> <71513412-2ac0-d101-7f3b-ed4349b759eb@durchholz.org> Message-ID: <20160912204755.GA19986@casa.casa> On Mon, Sep 12, 2016 at 04:28:19PM -0400, David Feuer wrote: > Also important is the extent to which the maintainers are willing and able > to change the library to respond to changes in users' needs and > expectations. Parsec, for example, seems to have been largely supplanted by > Megaparsec because it failed to evolve. (probably OT) megaparsec has 24 hackage projects depending on it, parsec 816. Some of this 31-to-1 ratio might be explained by folks being slow to adopt new tools, but I bet for 95% of people parsec is fine as it is. From erbalrajs at gmail.com Tue Sep 13 03:09:14 2016 From: erbalrajs at gmail.com (Balraj Singh) Date: Tue, 13 Sep 2016 08:39:14 +0530 Subject: [Haskell-cafe] =?utf-8?q?Facing_issue=3A_=22No_instance_for_=28Fr?= =?utf-8?q?actional_a0=29_arising_from_a_use_of_=E2=80=98it?= =?utf-8?b?4oCZIFRoZSB0eXBlIHZhcmlhYmxlIOKAmGEw4oCZIGlzIGFtYmlndW91?= =?utf-8?q?s=22?= In-Reply-To: References: Message-ID: Thanks Jack it works. On Tue, Sep 13, 2016 at 12:01 AM, Jack Henahan wrote: > > The inferred type of findLoot is > > findLoot :: (Integral a, Fractional a) => a -> [[a]] -> a > > It's impossible to satisfy those constraints. > > Rewriting like this does what you want, but there's likely a cleaner way > to express this algorithm. > > findLoot :: (Integral a, Fractional b) => a -> [[a]] -> b > findLoot val [] = 0.0 > findLoot val ((x:y:[]):xs) | val == 0 = 0.0 > | val < y = ((fromIntegral val) * (fromIntegral x)) / > fromIntegral y > | val > y = fromIntegral ((div val y)*x) + (findLoot (mod val > y) xs) > > > > Balraj Singh writes: > > > Hi, > > > > I am writing a sample code below and getting an error. Please help to > resolve > > it: > > > > Code: > > > > import Data.List > > > > > > findLoot val [] = 0.0 > > > > findLoot val ((x:y:[]):xs) | val == 0 = 0.0 > > > > | val < y = ((fromIntegral val) * (fromIntegral x)) > > / fromIntegral y > > > > | val > y = ((div val y)*x) + (findLoot (mod val y) > > xs) > > > > > > Error: > > > > No instance for (Fractional a0) arising from a use of ‘it’ > > > > The type variable ‘a0’ is ambiguous > > > > Note: there are several potential instances: > > > > instance HasResolution a => Fractional (Fixed a) > > > > -- Defined in ‘Data.Fixed’ > > > > instance Integral a => Fractional (Ratio a) > > > > -- Defined in ‘GHC.Real’ > > > > instance Fractional Double -- Defined in ‘GHC.Float’ > > > > ...plus one other > > > > In the first argument of ‘print’, namely ‘it’ > > > > In a stmt of an interactive GHCi command: print it > > > > > > Sample Input and Output: > > > > Input 1:- > > val = 50 > > ((x:y:[]):xs) = [[120, 30], [100,50],[60, 20]] > > Output 1:- > > 180.0000 > > > > Input 2:- > > val = 10 > > ((x:y:[]):xs) = [[500,30]] > > Output 2:- > > 166.6667 > > > -- > Jack > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bence.kodaj at gmail.com Tue Sep 13 08:22:20 2016 From: bence.kodaj at gmail.com (Bence Kodaj) Date: Tue, 13 Sep 2016 10:22:20 +0200 Subject: [Haskell-cafe] Haskell eXchange and related events -- Call for Participation Message-ID: Hi all, If you haven't registered yet for the Haskell eXchange, please get in touch - I bought an early bird ticket but I cannot attend after all. I'd be happy to sell my ticket to anybody for 80 GBP (originally it was 95 GBP + VAT). Cheers, Bence On Friday, 9 September 2016 17:32:24 UTC+2, Andres Löh wrote: > > Hi everyone. > > As Tom Ellis has correctly pointed out in another thread, I should > have announced the Haskell eXchange on this list. Let me do that now: > > ===================================================================== > Haskell eXchange 2016 > London, 6-7 October 2016 > ===================================================================== > > The Haskell eXchange is a general Haskell conference aimed at Haskell > enthusiasts of all skill levels. The Haskell eXchange is organized > annually, and 2016 is its fifth year. For the second year in a row, the > venue will be Skills Matter’s CodeNode, where we have space for three > parallel tracks. New this year: a large number of beginner-focused > talks. At all times, at least one track will be available with a talk > aimed at (relative) newcomers to Haskell. Of course, there are also > plenty of talks on more advanced topics. > > Keynote speakers: > > Don Stewart, Conor McBride, Graham Hutton, Simon Peyton Jones > > Talks and workshops (some changes may still occur) by: > > Julian Arni, Christiaan Baaij, Thomas van Binsbergen, Mathieu Boespflug, > Lars Brünjes, Ben Clifford, Philip Cunningham, Tom Ellis, Matthias > Fischmann, Oleg Grenrus, Nickolay Kudasov, Robert Henderson, Csaba > Hruska, Robin Kay, Csongor Kiss, Steven Kutsch, Kris Jenkins, David > Luposchainsky, Neil Mitchell, Andrey Mokhov, Romeo Moura, Jann Müller, > Boldizsár Németh, Andor Penzes, Ivan Perez, Michał Płachta, Nicolas > Pouillard, Arian van Putten, Andrzej Rybczak, Jeremy Singer, Nicolas Wu > > Homepage and registration: > > https://skillsmatter.com/conferences/7276-haskell-exchange-2016 > > If you're interested in the Haskell eXchange, you might also be > interested in the Haskell eXchange Haskell Hackathon and/or in the > Haskell courses (2-day introductory, 1-day on types, 2-day on > performance) offered by Well-Typed on the surrounding days. More info > here: http://www.well-typed.com/blog/125/ > > Cheers, > Andres > > -- > Andres Löh, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > > Registered in England & Wales, OC335890 > 250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England > -------------- next part -------------- An HTML attachment was scrubbed... URL: From komendantskaya at gmail.com Tue Sep 13 10:34:07 2016 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Tue, 13 Sep 2016 11:34:07 +0100 Subject: [Haskell-cafe] Workshop on Coalgebra, Horn Clause Logic, and Types Message-ID: Call for Papers, Presentations and Participation Workshop on Coalgebra, Horn Clause Logic Programming and Types 28-29 November 2016, Edinburgh, UK https://ff32.host.cs.st-andrews.ac.uk/lpti16/ =================================================== The workshop marks the end of the EPSRC Grant Coalgebraic Logic Programming for Type Inference, by K. Komendantskaya and J. Power and will consist of two parts: Part 1 - Semantics: Lawvere theories and Coalgebra in Logic and Functional Programming Part 2 - Programming languages: Horn Clause Logic for Type Inference in Functional Languages and Beyond We invite all colleagues working in related areas to present and share their results. We envisage a friendly meeting with many stimulating discussions, and therefore welcome presentations of already published research as well as novel results. Authors of original contributions will be invited to submit their papers to EPTCS post-proceedings. We especially encourage early career researchers to present and participate. ======================= Venue ----- The workshop will be held at the International Center for Mathematical Sciences, in Edinburgh city center, just 2 minutes walk from the Informatics Forum. Invited speakers and tutorials ------------------------------ * Relational Specification of type systems using Logic Programming, Ki Yung Ahn, Nanyang Techological University, Singapore * Logic programming for type inference in object-oriented languages, Davide Ancona, University of Genoa, Italy * Logic programming: laxness and saturation, John Power, University of Bath, UK * Classes for the masses, Claudio Russo, Microsoft Research Cambridge, UK * Comodels and interaction, Tarmo Ustalu, Tallinn University of Technology, Estonia =============================== Proceedings publication ----------------------- Presentations: We invite submission of 2-page extended abstracts via Easychair, by the 15th October 2016. These will be subject to light review process. Preliminary proceedings will be made available at the conference in electronic form. Post-proceedings: Authors presenting original work will be invited to submit full papers to the post-proceedings of the workshop. The post-proceedings volume will be published in Electronic Proceedings in Theoretical Computer Science and peer-reviewed according to EPTCS standards by the PC members. ================================ Important dates --------------- Extended Abstract Submission: 15 October, 2016 Author notification: 25 October, 2016 Workshop: 28–29 November, 2016 EPTCS post-proceedings invitations: 15 December, 2016 EPTCS final version submission: 30 January, 2017 ======================== Programme committee ------------------- Ki Yung Ahn, Nanyang Techological University, Singapore Davide Ancona, University of Genoa, Italy Filippo Bonchi, CNRS, ENS de Lyon, France Iavor Diatchki, Galois, Inc, USA Peng Fu, Heriot-Watt University, Edinburgh, UK Neil Ghani, University of Strathclyde, UK Patricia Johann, Appalachian State University, USA Ekaterina Komendantskaya, Heriot-Watt University, Edinburgh, UK Clemens Kupke, University of Strathclyde, UK J. Garrett Morris, University of Edinburgh, UK Fredrik Nordvall Forsberg, University of Strathclyde, UK John Power, University of Bath, UK Claudio Russo, Microsoft Research Cambridge, UK Martin Schmidt, DHBW Stuttgart and University of Osnabrueck, Germany Stephan Schulz, DHBW Stuttgart, Germany Aaron Stump, The University of Iowa, USA Niki Vazou, University of California, San Diego, USA Joe Wells, Heriot-Watt University, Edinburgh, UK Fabio Zanassi, Radboud University of Nijmegen, Netherlands Workschop chairs -------- Ekaterina Komendantskaya, Heriot-Watt University, UK John Power, University of Bath, UK Publicity chair --------------- František Farka, University of Dundee, UK and University of St Andrews, UK -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Sep 13 18:58:45 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 13 Sep 2016 14:58:45 -0400 Subject: [Haskell-cafe] technical thoughts on stack Message-ID: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. My approach: 1. `brew install haskell-stack`. Success. At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > Right Nothing At the end, I am helpfully told > To use this GHC and packages outside of a project, consider using: > stack ghc, stack ghci, stack runghc, or stack exec > So I then 3. `stack ghci`. My computer’s first reaction is to say > Run from outside a project, using implicit global project config > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > Error parsing targets: The specified targets matched no packages. > Perhaps you need to run 'stack init'? > Warning: build failed, but optimistically launching GHCi anyway > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I 4. `stack ghc --version`. This command reports > Invalid option `--version’ Grumble. It seems I can’t interact with GHC directly. ———— At this point, I am reminded why I dislike stack: **It’s optimized for a different workflow than I use.** And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). There’s more good news here! Both of these problems are really easy to fix. To fix (A), someone just has to write the tutorial. To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? I’m looking forward to hearing your thoughts. Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae From tanuki at gmail.com Tue Sep 13 19:07:52 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Tue, 13 Sep 2016 12:07:52 -0700 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: Stack *does* allow direct interaction with GHC: stack exec -- ghc version Granted this lacks a bit in brevity, but if you want to issue multiple commands from "inside" stack's private environment, you can also just do this: stack exec sh On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This > machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I > really just want the ability to run Haskell expressions in GHCi. So I skip > `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages > along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: > /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed > delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I > got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you > prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a > project-based workflow, and don’t use it when you want a compiler-based > workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The > downloads page right now is not serving us well. (I was legitimately > scratching my head at first trying to figure out how to provision a new > computer.) Sadly, I don’t see a good option presenting itself. Both > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > Platform Minimal) does appear to lack a “here’s what you do first” > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > discover — you have to choose the oft-maligned Haskell Platform link before > you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > warnings every time GHC is invoked outside of a project. Furthermore, stack > prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a > system GHC. Perhaps it would even be sufficient for `stack setup` to > clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we > should consider writing up criteria that potential users should consider > when choosing what workflow to start with. We’ll need to have a tighter > recommendation for those with no experience programming, but most > developers should be able to recognize what workflow they prefer and choose > accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > we’ll really be in a quandary about which installation procedure to put > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps > identified part of the burning black heart of the reason behind the vitriol > of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle at ondy.me Tue Sep 13 19:13:15 2016 From: kyle at ondy.me (Kyle Ondy) Date: Tue, 13 Sep 2016 15:13:15 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> On 16-09-13 12:07, Theodore Lief Gannon wrote: > Stack *does* allow direct interaction with GHC: > > stack exec -- ghc version > I find `stack ghc -- --version` to be a bit easier. Anything after the `--` is passed as an argument to ghc. From the help documentation: stack ghc -- X.hs -o x > Granted this lacks a bit in brevity, but if you want to issue multiple > commands from "inside" stack's private environment, you can also just do > this: > > stack exec sh > > On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg > wrote: > > > I’ve watched the recent back-and-forth about stack with quite a bit of > > interest (as many of us have). The discussion inspired me to take another > > look at stack. Here are the results of that foray. > > > > First, a disclosure: While I have appreciated the emergence of a new build > > tool for Haskell, I have never much liked stack. One of my chief goals in > > taking another look is to understand better why I do not like it. > > > > My task: Set up a Haskell environment on a new machine (a Mac). This > > machine has no Haskell infrastructure on it. > > > > My approach: > > > > 1. `brew install haskell-stack`. Success. > > > > At this point, I do not have a Haskell project I wish to build. Instead, I > > really just want the ability to run Haskell expressions in GHCi. So I skip > > `stack new` and go straight to > > > > 2. `stack setup`. This succeeds, but prints out some interesting messages > > along the way, including > > > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > > Right Nothing > > > > At the end, I am helpfully told > > > > > To use this GHC and packages outside of a project, consider using: > > > stack ghc, stack ghci, stack runghc, or stack exec > > > > > > > So I then > > > > 3. `stack ghci`. My computer’s first reaction is to say > > > > > Run from outside a project, using implicit global project config > > > Using resolver: lts-6.17 from implicit global project's config file: > > /home/rae/.stack/global-project/stack.yaml > > > Error parsing targets: The specified targets matched no packages. > > > Perhaps you need to run 'stack init'? > > > Warning: build failed, but optimistically launching GHCi anyway > > > > > > > which doesn’t make me feel all that comfortable, but then I am indeed > > delivered to the GHCi prompt, which works as expected. > > > > Done with GHCi, I quit. I then want to double-check which version of GHC I > > got, so I > > > > 4. `stack ghc --version`. This command reports > > > > > Invalid option `--version’ > > > > Grumble. It seems I can’t interact with GHC directly. > > > > ———— > > > > At this point, I am reminded why I dislike stack: > > > > **It’s optimized for a different workflow than I use.** > > > > And I think this fact (repeated by others’ experiences) is why a segment > > of our community has not celebrated stack as much as other segments have. > > We all have different workflows. > > > > From what I understand about it, stack is great for a project-based > > workflow. In this workflow, you are working on a Haskell project. You are > > happy to specify settings in .cabal and stack.yaml files. And you really > > want your build to work in the future and on other machines. > > > > In my experience, stack is not great with a compiler-based workflow. In > > this workflow, you aren’t quite as organized perhaps and do not have all > > your settings written. You also want the ability just to compile a file > > without changing any configurations. You want to be able to start GHCi with > > a nice set of libraries with which to experiment. > > > > I definitely like a compiler-based workflow. I’m sure that many of you > > prefer a project-based workflow. > > > > The great news here is that we have a choice: use stack for a > > project-based workflow, and don’t use it when you want a compiler-based > > workflow. No one needs to convince others about personal preferences. > > > > But there is one nagging issue: what do we suggest to newcomers? The > > downloads page right now is not serving us well. (I was legitimately > > scratching my head at first trying to figure out how to provision a new > > computer.) Sadly, I don’t see a good option presenting itself. Both > > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > > serious shortcomings. > > > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > > Platform Minimal) does appear to lack a “here’s what you do first” > > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > > discover — you have to choose the oft-maligned Haskell Platform link before > > you are told that there is a minimal variant. > > > > B. stack sets up GHC in a way that either 1) requires a project-based > > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > > warnings every time GHC is invoked outside of a project. Furthermore, stack > > prohibits direct interaction with GHC (as in `ghc --version`). > > > > There’s more good news here! Both of these problems are really easy to fix. > > > > To fix (A), someone just has to write the tutorial. > > > > To fix (B), stack just needs a new option so that `stack setup` installs a > > system GHC. Perhaps it would even be sufficient for `stack setup` to > > clearly tell the user where ghc is installed and what to add to their PATH. > > > > I also think, if readers agree with my conclusions about workflows, we > > should consider writing up criteria that potential users should consider > > when choosing what workflow to start with. We’ll need to have a tighter > > recommendation for those with no experience programming, but most > > developers should be able to recognize what workflow they prefer and choose > > accordingly. > > > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > > we’ll really be in a quandary about which installation procedure to put > > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > > one happens first gets to be featured first on the page? :) > > > > So: Does my characterization of workflows resonate? Have I perhaps > > identified part of the burning black heart of the reason behind the vitriol > > of late? Should we fix (A) and (B)? > > > > I’m looking forward to hearing your thoughts. > > > > Richard > > > > > > -=-=-=-=-=-=-=-=-=-=- > > Richard A. Eisenberg > > Asst. Prof. of Computer Science > > Bryn Mawr College > > Bryn Mawr, PA, USA > > cs.brynmawr.edu/~rae > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From johnw at newartisans.com Tue Sep 13 19:14:39 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 13 Sep 2016 12:14:39 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> (Richard Eisenberg's message of "Tue, 13 Sep 2016 14:58:45 -0400") References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: >>>>> "RE" == Richard Eisenberg writes: RE> To fix (B), stack just needs a new option so that `stack setup` installs a RE> system GHC. Perhaps it would even be sufficient for `stack setup` to RE> clearly tell the user where ghc is installed and what to add to their RE> PATH. Some other tools provide an "env" sub-command, so that a person can run: eval $(stack env) And now ghc, ghci, etc., would be on the PATH, and the user doesn't really need to care about where it lives. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From allbery.b at gmail.com Tue Sep 13 19:18:51 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:18:51 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20160913191315.hsyeldgtjxavcul4@localhost.localdomain> Message-ID: On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy wrote: > On 16-09-13 12:07, Theodore Lief Gannon wrote: > > Stack *does* allow direct interaction with GHC: > > > > stack exec -- ghc version > > > I find `stack ghc -- --version` to be a bit easier. Anything after the > `--` is > passed as an argument to ghc. > I actually find this part a little unfair; stack parses its parameters the same way cabal does. > stack exec -- ghc --version > cabal exec -- ghc --version Both need the -- to prevent --version from being eaten by stack/cabal respectively. (GNU "permute" argument parsing. urgh.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 13 19:20:11 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:20:11 -0400 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley wrote: > Some other tools provide an "env" sub-command, so that a person can run: > > eval $(stack env) > > And now ghc, ghci, etc., would be on the PATH, and the user doesn't really > need to care about where it lives. > There's more to it than $PATH --- and I am not sure that making it easy to accidentally modify the sandboxed package database is in any way a good idea. -- 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 cdsmith at gmail.com Tue Sep 13 19:26:38 2016 From: cdsmith at gmail.com (Chris Smith) Date: Tue, 13 Sep 2016 12:26:38 -0700 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: At this point (and quite sadly) the question is not mainly a technical one. We have difficult decisions to make collectively, by our actions, about whether it's okay to just overlook a years-long campaign of bitter character assassination aimed at core members of the community. For this reason, I think holding some kind of race, and implying that we all ought to just get behind whoever releases a minor UI tweak first, is more likely to hurt than help. On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This > machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I > really just want the ability to run Haskell expressions in GHCi. So I skip > `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages > along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: > /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed > delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I > got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you > prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a > project-based workflow, and don’t use it when you want a compiler-based > workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The > downloads page right now is not serving us well. (I was legitimately > scratching my head at first trying to figure out how to provision a new > computer.) Sadly, I don’t see a good option presenting itself. Both > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > Platform Minimal) does appear to lack a “here’s what you do first” > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > discover — you have to choose the oft-maligned Haskell Platform link before > you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > warnings every time GHC is invoked outside of a project. Furthermore, stack > prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a > system GHC. Perhaps it would even be sufficient for `stack setup` to > clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we > should consider writing up criteria that potential users should consider > when choosing what workflow to start with. We’ll need to have a tighter > recommendation for those with no experience programming, but most > developers should be able to recognize what workflow they prefer and choose > accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > we’ll really be in a quandary about which installation procedure to put > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps > identified part of the burning black heart of the reason behind the vitriol > of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Tue Sep 13 19:33:56 2016 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue, 13 Sep 2016 21:33:56 +0200 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 2016-09-13 21:14 GMT+02:00 John Wiegley : > >>>>> "RE" == Richard Eisenberg writes: > > RE> To fix (B), stack just needs a new option so that `stack setup` > installs a > RE> system GHC. Perhaps it would even be sufficient for `stack setup` to > RE> clearly tell the user where ghc is installed and what to add to their > RE> PATH. > > Some other tools provide an "env" sub-command, so that a person can run: > > eval $(stack env) > > And now ghc, ghci, etc., would be on the PATH, and the user doesn't really > need to care about where it lives. > +1 > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Tue Sep 13 19:47:14 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 13 Sep 2016 15:47:14 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Thanks, many, for explaining better ways to interact directly with GHC after using a `stack setup`. Perhaps, then, all that’s stopping someone like me from liking the ease of `stack setup` is a little missing PR (as in, public relations). I understand that many people want to keep GHC cloistered away to ease version swapping, but others (like me) want GHC available front and center. Other minor points: `stack env` does not work for me: my version of stack does not know how to `env`. I have version 1.1.2, as installed by `brew install haskell-stack`. Regardless, there are a variety of ways of establishing the right PATH. There was not, to my knowledge, any prior stack gubbins around. This is a new computer I’m working on, and I’m pretty sure this was my first attempt. -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 13, 2016, at 3:26 PM, Chris Smith wrote: > > At this point (and quite sadly) the question is not mainly a technical one. We have difficult decisions to make collectively, by our actions, about whether it's okay to just overlook a years-long campaign of bitter character assassination aimed at core members of the community. For this reason, I think holding some kind of race, and implying that we all ought to just get behind whoever releases a minor UI tweak first, is more likely to hurt than help. > > On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg > wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. > > From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 13 19:55:53 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 13 Sep 2016 15:55:53 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg wrote: > Other minor points: > `stack env` does not work for me: my version of stack does not know how to > `env` > I think they said that was an add-in. IIRC stack is extensible with external commands, in roughly the same way git is. (I am also not fond of stack, and even less fond of the politics that go with it, but will stick to the technical here.) -- 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 johnw at newartisans.com Tue Sep 13 20:00:57 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 13 Sep 2016 13:00:57 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> (Richard Eisenberg's message of "Tue, 13 Sep 2016 15:47:14 -0400") References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: >>>>> "RE" == Richard Eisenberg writes: RE> Other minor points: RE> `stack env` does not work for me: my version of stack does not know how to RE> `env`. I have version 1.1.2, as installed by `brew install haskell-stack`. RE> Regardless, there are a variety of ways of establishing the right PATH. Sorry Richard, that was just a feature idea for the stack people, not anything I knew about already. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From p.giarrusso at gmail.com Tue Sep 13 20:01:28 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:01:28 -0700 (PDT) Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote: > > Thanks, many, for explaining better ways to interact directly with GHC > after using a `stack setup`. Perhaps, then, all that’s stopping someone > like me from liking the ease of `stack setup` is a little missing PR (as > in, public relations). I understand that many people want to keep GHC > cloistered away to ease version swapping, but others (like me) want GHC > available front and center. > > Other minor points: > `stack env` does not work for me: my version of stack does not know how to > `env`. > That's correct—stack env was a feature request. The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug (probably because it's a new install)? I use stack (and have contributed a bit recently), but I agree there's a few things stack could do better for this workflow. And the transition has a rather annoying learning curve—stack ghci and stack ghc are not the same as ghci/ghc. I think that's on purpose to support a project-based workflow, and it has upsides, but it's a transition pitfall. Lots of things *are* explained in https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few things from scratch. You want stack exec ghc and stack exec ghci, and arbitrary options require a double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc --version`. And I'm afraid the command syntax is mostly frozen by now. To support a compiler-based workflow, there are a few things planned—I opened an issue to collect them, starting from Simon Marlow's recent email: https://github.com/commercialhaskell/stack/issues/2546 BTW, a system-installed GHC already works if you stick to one (and only build projects that need that). But I'd love to support multiple system-installed GHCs and being able to pick the one you need. As others already explained, giving access to stack-installed GHCs can be problematic—they're going to work, in part, exactly because you can't install in their package database. Having stack install system-wide GHCs would IMHO risk opening a can of worms—having working binaries for all Linux distros requires some work, system installers would be harder and most users would dislike them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:02:43 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:02:43 -0500 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: I almost never (maybe twice in the last year) do this, but when I need an environment that has Stack provided GHC-stuff in the path, I use `stack exec my-shell`. On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery wrote: > > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg > wrote: >> >> Other minor points: >> `stack env` does not work for me: my version of stack does not know how to >> `env` > > > I think they said that was an add-in. IIRC stack is extensible with external > commands, in roughly the same way git is. > > (I am also not fond of stack, and even less fond of the politics that go > with it, but will stick to the technical here.) > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Tue Sep 13 20:05:39 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:05:39 -0500 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: Stack users are moving away from enabling system installed GHCs by default because it breaks the ease of enabling profiling for libraries when you're using a Stack-installed GHC. I'm not sure why multiple system-installed GHCs needs to be supported in addition to the GHC support Stack already provides. That's extra work for...what? Stack isn't trying to compete with Nix. It's more like a blend of rustup and cargo -- or Clojure's Leiningen. On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso wrote: > > > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote: >> >> Thanks, many, for explaining better ways to interact directly with GHC >> after using a `stack setup`. Perhaps, then, all that’s stopping someone like >> me from liking the ease of `stack setup` is a little missing PR (as in, >> public relations). I understand that many people want to keep GHC cloistered >> away to ease version swapping, but others (like me) want GHC available front >> and center. >> >> Other minor points: >> `stack env` does not work for me: my version of stack does not know how to >> `env`. > > > That's correct—stack env was a feature request. > > The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug > (probably because it's a new install)? > > I use stack (and have contributed a bit recently), but I agree there's a few > things stack could do better for this workflow. > > And the transition has a rather annoying learning curve—stack ghci and stack > ghc are not the same as ghci/ghc. I think that's on purpose to support a > project-based workflow, and it has upsides, but it's a transition pitfall. > Lots of things *are* explained in > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few > things from scratch. > > You want stack exec ghc and stack exec ghci, and arbitrary options require a > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc > --version`. And I'm afraid the command syntax is mostly frozen by now. > > To support a compiler-based workflow, there are a few things planned—I > opened an issue to collect them, starting from Simon Marlow's recent email: > https://github.com/commercialhaskell/stack/issues/2546 > > BTW, a system-installed GHC already works if you stick to one (and only > build projects that need that). But I'd love to support multiple > system-installed GHCs and being able to pick the one you need. > > As others already explained, giving access to stack-installed GHCs can be > problematic—they're going to work, in part, exactly because you can't > install in their package database. > > Having stack install system-wide GHCs would IMHO risk opening a can of > worms—having working binaries for all Linux distros requires some work, > system installers would be harder and most users would dislike them. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From p.giarrusso at gmail.com Tue Sep 13 20:08:58 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:08:58 -0700 (PDT) Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: On Tuesday, September 13, 2016 at 8:58:53 PM UTC+2, Richard Eisenberg wrote: > > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > I think this is insightful, but this is also (in part) about different kind of projects: applications versus libraries. Not accidentally, if you maintain a Hackage library, stack docs recommend you setup CI with both stack and cabal. (Though I'll still use stack for local development for a library). https://docs.haskellstack.org/en/latest/travis_ci/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:10:55 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:10:55 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: Stack isn't exclusively for applications or libraries, the recommendation to add Cabal to your CI if it's a library is about checking buildability for Cabal users (making sure your bounds don't make the solver bonkers), not for workflow. On Tue, Sep 13, 2016 at 3:08 PM, Paolo Giarrusso wrote: > On Tuesday, September 13, 2016 at 8:58:53 PM UTC+2, Richard Eisenberg wrote: >> >> I’ve watched the recent back-and-forth about stack with quite a bit of >> interest (as many of us have). The discussion inspired me to take another >> look at stack. Here are the results of that foray. >> >> First, a disclosure: While I have appreciated the emergence of a new build >> tool for Haskell, I have never much liked stack. One of my chief goals in >> taking another look is to understand better why I do not like it. > > >> >> At this point, I am reminded why I dislike stack: >> >> **It’s optimized for a different workflow than I use.** >> >> And I think this fact (repeated by others’ experiences) is why a segment >> of our community has not celebrated stack as much as other segments have. We >> all have different workflows. >> >> From what I understand about it, stack is great for a project-based >> workflow. In this workflow, you are working on a Haskell project. You are >> happy to specify settings in .cabal and stack.yaml files. And you really >> want your build to work in the future and on other machines. >> >> In my experience, stack is not great with a compiler-based workflow. In >> this workflow, you aren’t quite as organized perhaps and do not have all >> your settings written. You also want the ability just to compile a file >> without changing any configurations. You want to be able to start GHCi with >> a nice set of libraries with which to experiment. > > > I think this is insightful, but this is also (in part) about different kind > of projects: applications versus libraries. Not accidentally, if you > maintain a Hackage library, stack docs recommend you setup CI with both > stack and cabal. (Though I'll still use stack for local development for a > library). > > https://docs.haskellstack.org/en/latest/travis_ci/ > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Chris Allen Currently working on http://haskellbook.com From p.giarrusso at gmail.com Tue Sep 13 20:16:59 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Tue, 13 Sep 2016 13:16:59 -0700 (PDT) Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen wrote: > > Stack users are moving away from enabling system installed GHCs by > default because it breaks the ease of enabling profiling for libraries > when you're using a Stack-installed GHC. > I'm not sure why multiple system-installed GHCs needs to be supported > in addition to the GHC support Stack already provides. That's extra > work for...what? Stack isn't trying to compete with Nix. It's more > like a blend of rustup and cargo -- or Clojure's Leiningen. > To clarify: I'm not proposing stack to install those GHCs, just to use them. I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) and has other technical advantages (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm willing to contribute the work and not asking anybody—I've just been busy. Right now I have to modify the PATH every time I use GHC 7.8.4 because I needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by default. > On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso > wrote: > > > > > > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg > wrote: > >> > >> Thanks, many, for explaining better ways to interact directly with GHC > >> after using a `stack setup`. Perhaps, then, all that’s stopping someone > like > >> me from liking the ease of `stack setup` is a little missing PR (as in, > >> public relations). I understand that many people want to keep GHC > cloistered > >> away to ease version swapping, but others (like me) want GHC available > front > >> and center. > >> > >> Other minor points: > >> `stack env` does not work for me: my version of stack does not know how > to > >> `env`. > > > > > > That's correct—stack env was a feature request. > > > > The warning on `stack ghci` doesn't happen usually, but I'd say that's a > bug > > (probably because it's a new install)? > > > > I use stack (and have contributed a bit recently), but I agree there's a > few > > things stack could do better for this workflow. > > > > And the transition has a rather annoying learning curve—stack ghci and > stack > > ghc are not the same as ghci/ghc. I think that's on purpose to support a > > project-based workflow, and it has upsides, but it's a transition > pitfall. > > Lots of things *are* explained in > > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a > few > > things from scratch. > > > > You want stack exec ghc and stack exec ghci, and arbitrary options > require a > > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc > > --version`. And I'm afraid the command syntax is mostly frozen by now. > > > > To support a compiler-based workflow, there are a few things planned—I > > opened an issue to collect them, starting from Simon Marlow's recent > email: > > https://github.com/commercialhaskell/stack/issues/2546 > > > > BTW, a system-installed GHC already works if you stick to one (and only > > build projects that need that). But I'd love to support multiple > > system-installed GHCs and being able to pick the one you need. > > > > As others already explained, giving access to stack-installed GHCs can be > > problematic—they're going to work, in part, exactly because you can't > > install in their package database. > > > > Having stack install system-wide GHCs would IMHO risk opening a can of > > worms—having working binaries for all Linux distros requires some work, > > system installers would be harder and most users would dislike them. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Sep 13 20:24:43 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 13 Sep 2016 22:24:43 +0200 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: 2016-09-13 21:07 GMT+02:00 Theodore Lief Gannon : > Stack *does* allow direct interaction with GHC: > > stack exec -- ghc version > > Granted this lacks a bit in brevity, but if you want to issue multiple > commands from "inside" stack's private environment, you can also just do > this: > > stack exec sh > Another option is setting up simple 2-liners like #!/bin/sh stack --resolver=lts-6.17 exec ghc -- "$@" and put them under some sensible name (e.g. ghc-7.10.3) into one's ~/bin, same for ghci. This way you can still keep things nicely separated and in a known state, but still have access to several versions without typing overhead. There are still a few tiny annoying things, though: * There's the "Run from outside a project blah blah" line, and I don't see a way to disable that. This is only a cosmetic issue, but still... * On Windows under a MinGW bash you get a a warning for ghci: $ stack --resolver=nightly-2016-07-01 exec ghci -- --version Run from outside a project, using implicit global project config WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular) doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead The Glorious Glasgow Haskell Compilation System, version 8.0.1 But using ghcii.sh through stack doesn't work: $ stack --resolver=nightly-2016-07-01 exec ghcii.sh -- --version Run from outside a project, using implicit global project config D:\Benutzer\Sven\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\bin\ghcii.sh: createProcess: invalid argument (Exec format error) * I've seen variations of "Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d...", too, and I don't have a clue what stack is trying to tell me, either. The message should either be suppressed or improved. As it is, it's useless for the end-user. * From time to time I'd like to remove old stuff which has been installed by stack, e.g. "everything not belonging to the latest LTS" or "everything from nightly-2016-07-01". I can easily blow away the whole ~/.stack directory and re-download/compile only the new stuff I need, but there must be a better way, I hope. This kind of housekeeping is really necessary when you play around a bit with various versions (resulting in tons of GB in ~/.stack) and your relatively small laptop HDD is getting a bit full In a nutshell: I'm quite happy with stack, but it still needs some polishing. When this is done, it can probably make both the "ad hoc" camp and the "multi-GHC-version project/library writer" camp happy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Tue Sep 13 20:27:49 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 13 Sep 2016 15:27:49 -0500 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: Stack is not your shell, a build script, or a Makefile. It already has path management for the GHC installations it provisions and supports. It is not Stack's job to mutilate your path to support external GHC installations. Make a Makefile or add shortcuts to your bashrc to switch compilers. On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso wrote: > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen > wrote: >> >> Stack users are moving away from enabling system installed GHCs by >> default because it breaks the ease of enabling profiling for libraries >> when you're using a Stack-installed GHC. > > >> >> I'm not sure why multiple system-installed GHCs needs to be supported >> in addition to the GHC support Stack already provides. That's extra >> work for...what? Stack isn't trying to compete with Nix. It's more >> like a blend of rustup and cargo -- or Clojure's Leiningen. > > > To clarify: I'm not proposing stack to install those GHCs, just to use them. > > I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC) > and has other technical advantages > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm > willing to contribute the work and not asking anybody—I've just been busy. > > Right now I have to modify the PATH every time I use GHC 7.8.4 because I > needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by > default. > >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso >> wrote: >> > >> > >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg >> > wrote: >> >> >> >> Thanks, many, for explaining better ways to interact directly with GHC >> >> after using a `stack setup`. Perhaps, then, all that’s stopping someone >> >> like >> >> me from liking the ease of `stack setup` is a little missing PR (as in, >> >> public relations). I understand that many people want to keep GHC >> >> cloistered >> >> away to ease version swapping, but others (like me) want GHC available >> >> front >> >> and center. >> >> >> >> Other minor points: >> >> `stack env` does not work for me: my version of stack does not know how >> >> to >> >> `env`. >> > >> > >> > That's correct—stack env was a feature request. >> > >> > The warning on `stack ghci` doesn't happen usually, but I'd say that's a >> > bug >> > (probably because it's a new install)? >> > >> > I use stack (and have contributed a bit recently), but I agree there's a >> > few >> > things stack could do better for this workflow. >> > >> > And the transition has a rather annoying learning curve—stack ghci and >> > stack >> > ghc are not the same as ghci/ghc. I think that's on purpose to support a >> > project-based workflow, and it has upsides, but it's a transition >> > pitfall. >> > Lots of things *are* explained in >> > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a >> > few >> > things from scratch. >> > >> > You want stack exec ghc and stack exec ghci, and arbitrary options >> > require a >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc >> > --version`. And I'm afraid the command syntax is mostly frozen by now. >> > >> > To support a compiler-based workflow, there are a few things planned—I >> > opened an issue to collect them, starting from Simon Marlow's recent >> > email: >> > https://github.com/commercialhaskell/stack/issues/2546 >> > >> > BTW, a system-installed GHC already works if you stick to one (and only >> > build projects that need that). But I'd love to support multiple >> > system-installed GHCs and being able to pick the one you need. >> > >> > As others already explained, giving access to stack-installed GHCs can >> > be >> > problematic—they're going to work, in part, exactly because you can't >> > install in their package database. >> > >> > Having stack install system-wide GHCs would IMHO risk opening a can of >> > worms—having working binaries for all Linux distros requires some work, >> > system installers would be harder and most users would dislike them. >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From harendra.kumar at gmail.com Tue Sep 13 22:49:39 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 14 Sep 2016 04:19:39 +0530 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: There are multiple ways to achieve this: 1) The env command being discussed is actually "stack exec env". Though it includes the full environment rather than stack exclusive. You can use "stack path" to print the stack exclusive environment. You can also use "stack path --" to pick specific items from that env. 2) Using "stack exec bash" is a very convenient way as suggested by Christopher Allen. 3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead which only sets the PATH. The full environment (when using env or bash) also includes GHC_PACKAGE_PATH which cabal does not like. So if you want to use cabal on stack installed ghc just setting PATH works fine. I think stack has a lot of flexibility and features, in fact too many. Usually there is already a way to achieve something that you want. Though there are areas where the user experience can be made better including cosmetic stuff like not throwing confusing or unnecessary warnings. -harendra On 14 September 2016 at 01:32, Christopher Allen wrote: > I almost never (maybe twice in the last year) do this, but when I need > an environment that has Stack provided GHC-stuff in the path, I use > `stack exec my-shell`. > > > > On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery > wrote: > > > > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg > > wrote: > >> > >> Other minor points: > >> `stack env` does not work for me: my version of stack does not know how > to > >> `env` > > > > > > I think they said that was an add-in. IIRC stack is extensible with > external > > commands, in roughly the same way git is. > > > > (I am also not fond of stack, and even less fond of the politics that go > > with it, but will stick to the technical here.) > > > > -- > > brandon s allbery kf8nh sine nomine > associates > > allbery.b at gmail.com > ballbery at sinenomine.net > > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Wed Sep 14 00:06:47 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Tue, 13 Sep 2016 17:06:47 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: <3b24b61c-a41e-83fa-41fb-5b7e314c9101@funwithsoftware.org> On 9/13/16 1:16 PM, Paolo Giarrusso wrote: > To clarify: I'm not proposing stack to install those GHCs, just to use > them. > > I think the extra work would be limited (calling GHC-X.Y.Z instead of > GHC) and has other technical advantages > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, > I'm willing to contribute the work and not asking anybody—I've just > been busy. > > Right now I have to modify the PATH every time I use GHC 7.8.4 because > I needed to customize the build (I'm on OS X 10.11), but I still want > GHC 8 by default. That reminds me: another thing I'd like to see (from either cabal or stack) is better support for cross-compilation. Cabal supports cross-compilation very poorly; you end up having to do ugly stuff like: alias mcabal="cabal --with-ghc=x86_64-unknown-linux-musl-ghc --with-ld=x86_64-unknown-linux-musl-ld --with-gcc=x86_64-unknown-linux-musl-gcc --with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg" and even then, it doesn't work with non-trivial packages. As far as I know, stack doesn't support cross-compilation at all. (But perhaps it's just not documented, or I've missed the documentation.) --Patrick From ok at cs.otago.ac.nz Wed Sep 14 01:35:48 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 14 Sep 2016 13:35:48 +1200 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: On 14/09/16 7:07 AM, Theodore Lief Gannon wrote: > Stack *does* allow direct interaction with GHC: > > stack exec -- ghc version > > Granted this lacks a bit in brevity, but if you want to issue multiple > commands from "inside" stack's private environment, you can also just do > this: > > stack exec sh Why is this starting to sound like the story of the Genius Tailor? http://www.wealthculture.cn/infoShow.asp?nid=880&sort=Article%20List I'm reminded of a Palo Alto research lab I visited once, where they were running a Lisp system, in order to run another Lisp system, in order to run Prolog. I have enough trouble getting useful work done in programming languages; I want tools like stack to be really simple and obvious to use. I'd much rather write a Haskell data structure than YAML; why do I need to learn Yet Another serialisation format just to use some fershlugginer project tool? From michael at snoyman.com Wed Sep 14 01:39:15 2016 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Sep 2016 01:39:15 +0000 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: There's a pull request in flight now documenting common workflows for doing non project work with Stack, whether it be the REPL or scripts/single file programs. It's not complete, but you can view the content at: https://github.com/haskell-lang/haskell-lang/pull/94 On Tue, Sep 13, 2016, 9:58 PM Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This > machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I > really just want the ability to run Haskell expressions in GHCi. So I skip > `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages > along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: > /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed > delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I > got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you > prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a > project-based workflow, and don’t use it when you want a compiler-based > workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The > downloads page right now is not serving us well. (I was legitimately > scratching my head at first trying to figure out how to provision a new > computer.) Sadly, I don’t see a good option presenting itself. Both > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > Platform Minimal) does appear to lack a “here’s what you do first” > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > discover — you have to choose the oft-maligned Haskell Platform link before > you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > warnings every time GHC is invoked outside of a project. Furthermore, stack > prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a > system GHC. Perhaps it would even be sufficient for `stack setup` to > clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we > should consider writing up criteria that potential users should consider > when choosing what workflow to start with. We’ll need to have a tighter > recommendation for those with no experience programming, but most > developers should be able to recognize what workflow they prefer and choose > accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > we’ll really be in a quandary about which installation procedure to put > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps > identified part of the burning black heart of the reason behind the vitriol > of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eraker at gmail.com Wed Sep 14 03:31:57 2016 From: eraker at gmail.com (erik) Date: Tue, 13 Sep 2016 20:31:57 -0700 Subject: [Haskell-cafe] GHCI segfault for program that works fine when compiled Message-ID: Hello, I posted a question on Stackoverflow and reddit's /r/haskell today (see below), the gist of which was that GHCI segfaults when I attempt to create a connection to a Postgresql instance using a function from the postgresql-simple library; however, when I compile and run my code it works fine. I thought it was perhaps odd that GHCI would segfault when the compiled code worked fine (this is on GHC 8.0.1 and GHC 7.10.3), and then I discovered that if I start GHCI in the following way, I can create a connection to my database without any issues: $ stack ghci --library-profiling --ghci-options="-fexternal-interpreter" It seems likely that I have a weird install of Postgresql + postgresql-libpq (albeit probably not too weird for anyone on OSX who uses the EnterpriseDB installer, like I did). As a result, I was unsure if exploring this issue further would be of interest to anyone. Anyway, I am posting here because I was encouraged to do so by a commenter on my Stackoverflow question. In addition, in both places, I received the suggestion to open a GHC ticket, but owing to my limited experience in Haskell, I am hesitant to do so. I do not know how to get a real stack trace for my segfault. Moreover, I would likely require a fair bit of hand-holding to produce any useful data, and I wasn't sure if pursuing this any further would be of value to anyone. More information can be seen here: Stackoverflow question: http://stackoverflow.com/questions/39440416/ghci-segfault-when-creating-a-database-connection-with-postgresql-simple Reddit Thread: https://www.reddit.com/r/haskell/comments/52ht7h/i_have_a_ghci_segfault_for_an_application_that Should I open a GHC ticket? If so, what are some good strategies for producing useful information for that ticket? Thanks, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Sep 14 07:26:43 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 14 Sep 2016 08:26:43 +0100 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <20160914072643.GE32581@weber> On Wed, Sep 14, 2016 at 01:35:48PM +1200, Richard A. O'Keefe wrote: > I have enough trouble getting useful work done in programming > languages; I want tools like stack to be really simple and obvious > to use. I'd much rather write a Haskell data structure than YAML; Absolutely! From matthewtpickering at gmail.com Wed Sep 14 08:29:23 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Wed, 14 Sep 2016 09:29:23 +0100 Subject: [Haskell-cafe] GHCI segfault for program that works fine when compiled In-Reply-To: References: Message-ID: Hi Erik, Yes, you should definitely open a ticket for a segfault! Someone will close it if it is a duplicate or not a bug in GHC and you are far more likely to get good help than reporting the bug on reddit. The absolute best thing you can do is reduce the case sufficiently so that ideally the bug can be reproduced with one invocation of ghc. (Something like "ghc --interactive -fexternal-interpreter") or at least a cabalised project with as few dependencies as possible. Stack reproduction instructions are not very useful as it is hard to use stack with a custom build of GHC. Matt On Wed, Sep 14, 2016 at 4:31 AM, erik wrote: > Hello, > > I posted a question on Stackoverflow and reddit's /r/haskell today (see > below), the gist of which was that GHCI segfaults when I attempt to create a > connection to a Postgresql instance using a function from the > postgresql-simple library; however, when I compile and run my code it works > fine. > > I thought it was perhaps odd that GHCI would segfault when the compiled code > worked fine (this is on GHC 8.0.1 and GHC 7.10.3), and then I discovered > that if I start GHCI in the following way, I can create a connection to my > database without any issues: > > $ stack ghci --library-profiling --ghci-options="-fexternal-interpreter" > > It seems likely that I have a weird install of Postgresql + postgresql-libpq > (albeit probably not too weird for anyone on OSX who uses the EnterpriseDB > installer, like I did). As a result, I was unsure if exploring this issue > further would be of interest to anyone. > > Anyway, I am posting here because I was encouraged to do so by a commenter > on my Stackoverflow question. In addition, in both places, I received the > suggestion to open a GHC ticket, but owing to my limited experience in > Haskell, I am hesitant to do so. I do not know how to get a real stack trace > for my segfault. Moreover, I would likely require a fair bit of hand-holding > to produce any useful data, and I wasn't sure if pursuing this any further > would be of value to anyone. > > More information can be seen here: > > Stackoverflow question: > http://stackoverflow.com/questions/39440416/ghci-segfault-when-creating-a-database-connection-with-postgresql-simple > > Reddit Thread: > https://www.reddit.com/r/haskell/comments/52ht7h/i_have_a_ghci_segfault_for_an_application_that > > Should I open a GHC ticket? If so, what are some good strategies for > producing useful information for that ticket? > > Thanks, > > Erik > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From mail at stefanwehr.de Wed Sep 14 08:40:24 2016 From: mail at stefanwehr.de (Stefan Wehr) Date: Wed, 14 Sep 2016 10:40:24 +0200 Subject: [Haskell-cafe] [ANN] Call for Contributions: BOB 2017 - Berlin, Feb 24, 2017 Message-ID: BOB Conference 2017 "What happens when we use what's best for a change?" http://bobkonf.de/2017/en/cfp.html Berlin, February 24 Call for Contributions Deadline: October 30, 2016 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. This time, we’re especially interested in experience reports. But this could also take other forms, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - an abstract of max. 1500 characters. - a short bio/cv - contact information (including at least email address) - a list of 3-5 concrete ideas of how your work can be applied in a developer’s daily life -additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://docs.google.com/forms/d/e/1FAIpQLSfFuyBhBTCOTS0zTXBzY1KVuKpumyIBTucLcJ1ArC1XpWsG-Q/viewform Organisation - direct questions to bobkonf at active minus group dot de - proposal deadline: October 30, 2016 - notification: November 15, 2016 - program: December 1, 2016 NOTE: The conference fee will be waived for presenters, but travel expenses will not be covered. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Details are here: http://bobkonf.de/2017/en/speaker-grants.html Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Program Committee ----------------- (more information here: http://bobkonf.de/2017/programmkomitee.html) - Matthias Fischmann, zerobuzz UG - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg From marlowsd at gmail.com Wed Sep 14 14:42:50 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 14 Sep 2016 15:42:50 +0100 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: How would I use stack with a GHC 8.0.2 release candidate? On 13 September 2016 at 21:27, Christopher Allen wrote: > Stack is not your shell, a build script, or a Makefile. It already has > path management for the GHC installations it provisions and supports. > It is not Stack's job to mutilate your path to support external GHC > installations. > > Make a Makefile or add shortcuts to your bashrc to switch compilers. > > On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso > wrote: > > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen > > wrote: > >> > >> Stack users are moving away from enabling system installed GHCs by > >> default because it breaks the ease of enabling profiling for libraries > >> when you're using a Stack-installed GHC. > > > > > >> > >> I'm not sure why multiple system-installed GHCs needs to be supported > >> in addition to the GHC support Stack already provides. That's extra > >> work for...what? Stack isn't trying to compete with Nix. It's more > >> like a blend of rustup and cargo -- or Clojure's Leiningen. > > > > > > To clarify: I'm not proposing stack to install those GHCs, just to use > them. > > > > I think the extra work would be limited (calling GHC-X.Y.Z instead of > GHC) > > and has other technical advantages > > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm > > willing to contribute the work and not asking anybody—I've just been > busy. > > > > Right now I have to modify the PATH every time I use GHC 7.8.4 because I > > needed to customize the build (I'm on OS X 10.11), but I still want GHC > 8 by > > default. > > > >> > >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso > >> wrote: > >> > > >> > > >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg > >> > wrote: > >> >> > >> >> Thanks, many, for explaining better ways to interact directly with > GHC > >> >> after using a `stack setup`. Perhaps, then, all that’s stopping > someone > >> >> like > >> >> me from liking the ease of `stack setup` is a little missing PR (as > in, > >> >> public relations). I understand that many people want to keep GHC > >> >> cloistered > >> >> away to ease version swapping, but others (like me) want GHC > available > >> >> front > >> >> and center. > >> >> > >> >> Other minor points: > >> >> `stack env` does not work for me: my version of stack does not know > how > >> >> to > >> >> `env`. > >> > > >> > > >> > That's correct—stack env was a feature request. > >> > > >> > The warning on `stack ghci` doesn't happen usually, but I'd say > that's a > >> > bug > >> > (probably because it's a new install)? > >> > > >> > I use stack (and have contributed a bit recently), but I agree > there's a > >> > few > >> > things stack could do better for this workflow. > >> > > >> > And the transition has a rather annoying learning curve—stack ghci and > >> > stack > >> > ghc are not the same as ghci/ghc. I think that's on purpose to > support a > >> > project-based workflow, and it has upsides, but it's a transition > >> > pitfall. > >> > Lots of things *are* explained in > >> > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a > >> > few > >> > things from scratch. > >> > > >> > You want stack exec ghc and stack exec ghci, and arbitrary options > >> > require a > >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc > >> > --version`. And I'm afraid the command syntax is mostly frozen by now. > >> > > >> > To support a compiler-based workflow, there are a few things planned—I > >> > opened an issue to collect them, starting from Simon Marlow's recent > >> > email: > >> > https://github.com/commercialhaskell/stack/issues/2546 > >> > > >> > BTW, a system-installed GHC already works if you stick to one (and > only > >> > build projects that need that). But I'd love to support multiple > >> > system-installed GHCs and being able to pick the one you need. > >> > > >> > As others already explained, giving access to stack-installed GHCs can > >> > be > >> > problematic—they're going to work, in part, exactly because you can't > >> > install in their package database. > >> > > >> > Having stack install system-wide GHCs would IMHO risk opening a can of > >> > worms—having working binaries for all Linux distros requires some > work, > >> > system installers would be harder and most users would dislike them. > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > To (un)subscribe, modify options or view archives go to: > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > Only members subscribed via the mailman list are allowed to post. > >> > >> -- > >> Chris Allen > >> Currently working on http://haskellbook.com > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Chris Allen > Currently working on http://haskellbook.com > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Wed Sep 14 14:51:13 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 14 Sep 2016 23:51:13 +0900 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: <1473864646-sup-8826@sabre> Excerpts from Harendra Kumar's message of 2016-09-14 04:19:39 +0530: > 3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead > which only sets the PATH. The full environment (when using env or bash) > also includes GHC_PACKAGE_PATH which cabal does not like. See https://github.com/haskell/cabal/issues/3728 Edward From cma at bitemyapp.com Wed Sep 14 15:23:05 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 10:23:05 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: Probably pretty similarly to how we use patched GHCJS at work with Stack. -- from the stack.yaml system-ghc: true compiler: ghcjs-0.2.0_ghc-7.10.2 resolver: ghcjs-0.2.0_ghc-7.10.2 -- in the Makefile ghcjs: git clone https://github.com/myorg/ghcjs cd ghcjs && stack setup && stack install cd ghcjs && stack install cabal-install alex happy cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock It's just picking GHCJS up from the path, with system-ghc: true, we're telling it that is kosher. We disable system-ghc usage for regular GHC projects, it makes profiling less convenient than if you use a Stack managed GHC but if you're doing GHC dev the difference means nothing. On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: > How would I use stack with a GHC 8.0.2 release candidate? > > On 13 September 2016 at 21:27, Christopher Allen wrote: >> >> Stack is not your shell, a build script, or a Makefile. It already has >> path management for the GHC installations it provisions and supports. >> It is not Stack's job to mutilate your path to support external GHC >> installations. >> >> Make a Makefile or add shortcuts to your bashrc to switch compilers. >> >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso >> wrote: >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen >> > wrote: >> >> >> >> Stack users are moving away from enabling system installed GHCs by >> >> default because it breaks the ease of enabling profiling for libraries >> >> when you're using a Stack-installed GHC. >> > >> > >> >> >> >> I'm not sure why multiple system-installed GHCs needs to be supported >> >> in addition to the GHC support Stack already provides. That's extra >> >> work for...what? Stack isn't trying to compete with Nix. It's more >> >> like a blend of rustup and cargo -- or Clojure's Leiningen. >> > >> > >> > To clarify: I'm not proposing stack to install those GHCs, just to use >> > them. >> > >> > I think the extra work would be limited (calling GHC-X.Y.Z instead of >> > GHC) >> > and has other technical advantages >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm >> > willing to contribute the work and not asking anybody—I've just been >> > busy. >> > >> > Right now I have to modify the PATH every time I use GHC 7.8.4 because I >> > needed to customize the build (I'm on OS X 10.11), but I still want GHC >> > 8 by >> > default. >> > >> >> >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso >> >> wrote: >> >> > >> >> > >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg >> >> > wrote: >> >> >> >> >> >> Thanks, many, for explaining better ways to interact directly with >> >> >> GHC >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping >> >> >> someone >> >> >> like >> >> >> me from liking the ease of `stack setup` is a little missing PR (as >> >> >> in, >> >> >> public relations). I understand that many people want to keep GHC >> >> >> cloistered >> >> >> away to ease version swapping, but others (like me) want GHC >> >> >> available >> >> >> front >> >> >> and center. >> >> >> >> >> >> Other minor points: >> >> >> `stack env` does not work for me: my version of stack does not know >> >> >> how >> >> >> to >> >> >> `env`. >> >> > >> >> > >> >> > That's correct—stack env was a feature request. >> >> > >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say >> >> > that's a >> >> > bug >> >> > (probably because it's a new install)? >> >> > >> >> > I use stack (and have contributed a bit recently), but I agree >> >> > there's a >> >> > few >> >> > things stack could do better for this workflow. >> >> > >> >> > And the transition has a rather annoying learning curve—stack ghci >> >> > and >> >> > stack >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to >> >> > support a >> >> > project-based workflow, and it has upsides, but it's a transition >> >> > pitfall. >> >> > Lots of things *are* explained in >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a >> >> > few >> >> > things from scratch. >> >> > >> >> > You want stack exec ghc and stack exec ghci, and arbitrary options >> >> > require a >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc >> >> > --version`. And I'm afraid the command syntax is mostly frozen by >> >> > now. >> >> > >> >> > To support a compiler-based workflow, there are a few things >> >> > planned—I >> >> > opened an issue to collect them, starting from Simon Marlow's recent >> >> > email: >> >> > https://github.com/commercialhaskell/stack/issues/2546 >> >> > >> >> > BTW, a system-installed GHC already works if you stick to one (and >> >> > only >> >> > build projects that need that). But I'd love to support multiple >> >> > system-installed GHCs and being able to pick the one you need. >> >> > >> >> > As others already explained, giving access to stack-installed GHCs >> >> > can >> >> > be >> >> > problematic—they're going to work, in part, exactly because you can't >> >> > install in their package database. >> >> > >> >> > Having stack install system-wide GHCs would IMHO risk opening a can >> >> > of >> >> > worms—having working binaries for all Linux distros requires some >> >> > work, >> >> > system installers would be harder and most users would dislike them. >> >> > >> >> > _______________________________________________ >> >> > Haskell-Cafe mailing list >> >> > To (un)subscribe, modify options or view archives go to: >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> >> Chris Allen >> >> Currently working on http://haskellbook.com >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -- Chris Allen Currently working on http://haskellbook.com From marlowsd at gmail.com Wed Sep 14 15:54:46 2016 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 14 Sep 2016 16:54:46 +0100 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: But what if I don't want to fiddle with my PATH? Why is it so bad for stack to have a --with-ghc option to tell it what GHC to use? On 14 September 2016 at 16:23, Christopher Allen wrote: > Probably pretty similarly to how we use patched GHCJS at work with Stack. > > -- from the stack.yaml > system-ghc: true > compiler: ghcjs-0.2.0_ghc-7.10.2 > resolver: ghcjs-0.2.0_ghc-7.10.2 > > -- in the Makefile > ghcjs: > git clone https://github.com/myorg/ghcjs > cd ghcjs && stack setup && stack install > cd ghcjs && stack install cabal-install alex happy > cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock > > It's just picking GHCJS up from the path, with system-ghc: true, we're > telling it that is kosher. > > We disable system-ghc usage for regular GHC projects, it makes > profiling less convenient than if you use a Stack managed GHC but if > you're doing GHC dev the difference means nothing. > > On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: > > How would I use stack with a GHC 8.0.2 release candidate? > > > > On 13 September 2016 at 21:27, Christopher Allen > wrote: > >> > >> Stack is not your shell, a build script, or a Makefile. It already has > >> path management for the GHC installations it provisions and supports. > >> It is not Stack's job to mutilate your path to support external GHC > >> installations. > >> > >> Make a Makefile or add shortcuts to your bashrc to switch compilers. > >> > >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso > > >> wrote: > >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen > >> > wrote: > >> >> > >> >> Stack users are moving away from enabling system installed GHCs by > >> >> default because it breaks the ease of enabling profiling for > libraries > >> >> when you're using a Stack-installed GHC. > >> > > >> > > >> >> > >> >> I'm not sure why multiple system-installed GHCs needs to be supported > >> >> in addition to the GHC support Stack already provides. That's extra > >> >> work for...what? Stack isn't trying to compete with Nix. It's more > >> >> like a blend of rustup and cargo -- or Clojure's Leiningen. > >> > > >> > > >> > To clarify: I'm not proposing stack to install those GHCs, just to use > >> > them. > >> > > >> > I think the extra work would be limited (calling GHC-X.Y.Z instead of > >> > GHC) > >> > and has other technical advantages > >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, > I'm > >> > willing to contribute the work and not asking anybody—I've just been > >> > busy. > >> > > >> > Right now I have to modify the PATH every time I use GHC 7.8.4 > because I > >> > needed to customize the build (I'm on OS X 10.11), but I still want > GHC > >> > 8 by > >> > default. > >> > > >> >> > >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso > > >> >> wrote: > >> >> > > >> >> > > >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard > Eisenberg > >> >> > wrote: > >> >> >> > >> >> >> Thanks, many, for explaining better ways to interact directly with > >> >> >> GHC > >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping > >> >> >> someone > >> >> >> like > >> >> >> me from liking the ease of `stack setup` is a little missing PR > (as > >> >> >> in, > >> >> >> public relations). I understand that many people want to keep GHC > >> >> >> cloistered > >> >> >> away to ease version swapping, but others (like me) want GHC > >> >> >> available > >> >> >> front > >> >> >> and center. > >> >> >> > >> >> >> Other minor points: > >> >> >> `stack env` does not work for me: my version of stack does not > know > >> >> >> how > >> >> >> to > >> >> >> `env`. > >> >> > > >> >> > > >> >> > That's correct—stack env was a feature request. > >> >> > > >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say > >> >> > that's a > >> >> > bug > >> >> > (probably because it's a new install)? > >> >> > > >> >> > I use stack (and have contributed a bit recently), but I agree > >> >> > there's a > >> >> > few > >> >> > things stack could do better for this workflow. > >> >> > > >> >> > And the transition has a rather annoying learning curve—stack ghci > >> >> > and > >> >> > stack > >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to > >> >> > support a > >> >> > project-based workflow, and it has upsides, but it's a transition > >> >> > pitfall. > >> >> > Lots of things *are* explained in > >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need > learn a > >> >> > few > >> >> > things from scratch. > >> >> > > >> >> > You want stack exec ghc and stack exec ghci, and arbitrary options > >> >> > require a > >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- > ghc > >> >> > --version`. And I'm afraid the command syntax is mostly frozen by > >> >> > now. > >> >> > > >> >> > To support a compiler-based workflow, there are a few things > >> >> > planned—I > >> >> > opened an issue to collect them, starting from Simon Marlow's > recent > >> >> > email: > >> >> > https://github.com/commercialhaskell/stack/issues/2546 > >> >> > > >> >> > BTW, a system-installed GHC already works if you stick to one (and > >> >> > only > >> >> > build projects that need that). But I'd love to support multiple > >> >> > system-installed GHCs and being able to pick the one you need. > >> >> > > >> >> > As others already explained, giving access to stack-installed GHCs > >> >> > can > >> >> > be > >> >> > problematic—they're going to work, in part, exactly because you > can't > >> >> > install in their package database. > >> >> > > >> >> > Having stack install system-wide GHCs would IMHO risk opening a can > >> >> > of > >> >> > worms—having working binaries for all Linux distros requires some > >> >> > work, > >> >> > system installers would be harder and most users would dislike > them. > >> >> > > >> >> > _______________________________________________ > >> >> > Haskell-Cafe mailing list > >> >> > To (un)subscribe, modify options or view archives go to: > >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> >> > Only members subscribed via the mailman list are allowed to post. > >> >> > >> >> -- > >> >> Chris Allen > >> >> Currently working on http://haskellbook.com > >> >> _______________________________________________ > >> >> Haskell-Cafe mailing list > >> >> To (un)subscribe, modify options or view archives go to: > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> >> Only members subscribed via the mailman list are allowed to post. > >> > >> > >> > >> -- > >> Chris Allen > >> Currently working on http://haskellbook.com > >> _______________________________________________ > >> Haskell-community mailing list > >> Haskell-community at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > > > > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Sep 14 15:59:14 2016 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 14 Sep 2016 18:59:14 +0300 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: I don't think anyone thinks it's bad to have a --with-ghc option, AFAIK the only reason it hasn't been done is lack of desire/time, since it's an uncommon workflow. Unlike with cabal, the normal way to specify a different GHC is with the `--resolver` setting. AFAIK, this flag could be added. On Wed, Sep 14, 2016 at 6:54 PM, Simon Marlow wrote: > But what if I don't want to fiddle with my PATH? Why is it so bad for > stack to have a --with-ghc option to tell it what GHC to use? > > On 14 September 2016 at 16:23, Christopher Allen > wrote: > >> Probably pretty similarly to how we use patched GHCJS at work with Stack. >> >> -- from the stack.yaml >> system-ghc: true >> compiler: ghcjs-0.2.0_ghc-7.10.2 >> resolver: ghcjs-0.2.0_ghc-7.10.2 >> >> -- in the Makefile >> ghcjs: >> git clone https://github.com/myorg/ghcjs >> cd ghcjs && stack setup && stack install >> cd ghcjs && stack install cabal-install alex happy >> cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock >> >> It's just picking GHCJS up from the path, with system-ghc: true, we're >> telling it that is kosher. >> >> We disable system-ghc usage for regular GHC projects, it makes >> profiling less convenient than if you use a Stack managed GHC but if >> you're doing GHC dev the difference means nothing. >> >> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow wrote: >> > How would I use stack with a GHC 8.0.2 release candidate? >> > >> > On 13 September 2016 at 21:27, Christopher Allen >> wrote: >> >> >> >> Stack is not your shell, a build script, or a Makefile. It already has >> >> path management for the GHC installations it provisions and supports. >> >> It is not Stack's job to mutilate your path to support external GHC >> >> installations. >> >> >> >> Make a Makefile or add shortcuts to your bashrc to switch compilers. >> >> >> >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso < >> p.giarrusso at gmail.com> >> >> wrote: >> >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher >> Allen >> >> > wrote: >> >> >> >> >> >> Stack users are moving away from enabling system installed GHCs by >> >> >> default because it breaks the ease of enabling profiling for >> libraries >> >> >> when you're using a Stack-installed GHC. >> >> > >> >> > >> >> >> >> >> >> I'm not sure why multiple system-installed GHCs needs to be >> supported >> >> >> in addition to the GHC support Stack already provides. That's extra >> >> >> work for...what? Stack isn't trying to compete with Nix. It's more >> >> >> like a blend of rustup and cargo -- or Clojure's Leiningen. >> >> > >> >> > >> >> > To clarify: I'm not proposing stack to install those GHCs, just to >> use >> >> > them. >> >> > >> >> > I think the extra work would be limited (calling GHC-X.Y.Z instead of >> >> > GHC) >> >> > and has other technical advantages >> >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind you, >> I'm >> >> > willing to contribute the work and not asking anybody—I've just been >> >> > busy. >> >> > >> >> > Right now I have to modify the PATH every time I use GHC 7.8.4 >> because I >> >> > needed to customize the build (I'm on OS X 10.11), but I still want >> GHC >> >> > 8 by >> >> > default. >> >> > >> >> >> >> >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso < >> p.gia... at gmail.com> >> >> >> wrote: >> >> >> > >> >> >> > >> >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard >> Eisenberg >> >> >> > wrote: >> >> >> >> >> >> >> >> Thanks, many, for explaining better ways to interact directly >> with >> >> >> >> GHC >> >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping >> >> >> >> someone >> >> >> >> like >> >> >> >> me from liking the ease of `stack setup` is a little missing PR >> (as >> >> >> >> in, >> >> >> >> public relations). I understand that many people want to keep GHC >> >> >> >> cloistered >> >> >> >> away to ease version swapping, but others (like me) want GHC >> >> >> >> available >> >> >> >> front >> >> >> >> and center. >> >> >> >> >> >> >> >> Other minor points: >> >> >> >> `stack env` does not work for me: my version of stack does not >> know >> >> >> >> how >> >> >> >> to >> >> >> >> `env`. >> >> >> > >> >> >> > >> >> >> > That's correct—stack env was a feature request. >> >> >> > >> >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say >> >> >> > that's a >> >> >> > bug >> >> >> > (probably because it's a new install)? >> >> >> > >> >> >> > I use stack (and have contributed a bit recently), but I agree >> >> >> > there's a >> >> >> > few >> >> >> > things stack could do better for this workflow. >> >> >> > >> >> >> > And the transition has a rather annoying learning curve—stack ghci >> >> >> > and >> >> >> > stack >> >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to >> >> >> > support a >> >> >> > project-based workflow, and it has upsides, but it's a transition >> >> >> > pitfall. >> >> >> > Lots of things *are* explained in >> >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need >> learn a >> >> >> > few >> >> >> > things from scratch. >> >> >> > >> >> >> > You want stack exec ghc and stack exec ghci, and arbitrary options >> >> >> > require a >> >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec -- >> ghc >> >> >> > --version`. And I'm afraid the command syntax is mostly frozen by >> >> >> > now. >> >> >> > >> >> >> > To support a compiler-based workflow, there are a few things >> >> >> > planned—I >> >> >> > opened an issue to collect them, starting from Simon Marlow's >> recent >> >> >> > email: >> >> >> > https://github.com/commercialhaskell/stack/issues/2546 >> >> >> > >> >> >> > BTW, a system-installed GHC already works if you stick to one (and >> >> >> > only >> >> >> > build projects that need that). But I'd love to support multiple >> >> >> > system-installed GHCs and being able to pick the one you need. >> >> >> > >> >> >> > As others already explained, giving access to stack-installed GHCs >> >> >> > can >> >> >> > be >> >> >> > problematic—they're going to work, in part, exactly because you >> can't >> >> >> > install in their package database. >> >> >> > >> >> >> > Having stack install system-wide GHCs would IMHO risk opening a >> can >> >> >> > of >> >> >> > worms—having working binaries for all Linux distros requires some >> >> >> > work, >> >> >> > system installers would be harder and most users would dislike >> them. >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Haskell-Cafe mailing list >> >> >> > To (un)subscribe, modify options or view archives go to: >> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> >> -- >> >> >> Chris Allen >> >> >> Currently working on http://haskellbook.com >> >> >> _______________________________________________ >> >> >> Haskell-Cafe mailing list >> >> >> To (un)subscribe, modify options or view archives go to: >> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> >> >> >> -- >> >> Chris Allen >> >> Currently working on http://haskellbook.com >> >> _______________________________________________ >> >> Haskell-community mailing list >> >> Haskell-community at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> > >> > >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Sep 14 17:47:54 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 14 Sep 2016 13:47:54 -0400 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> Message-ID: While we're griping about stack: it seems to place compiler output from -ddump-... in mysterious places that are hard to find without Google, and (worse) it seems to do something with stack test output that even Google can't discover. On Sep 14, 2016 11:59 AM, "Michael Snoyman" wrote: > I don't think anyone thinks it's bad to have a --with-ghc option, AFAIK > the only reason it hasn't been done is lack of desire/time, since it's an > uncommon workflow. Unlike with cabal, the normal way to specify a different > GHC is with the `--resolver` setting. AFAIK, this flag could be added. > > On Wed, Sep 14, 2016 at 6:54 PM, Simon Marlow wrote: > >> But what if I don't want to fiddle with my PATH? Why is it so bad for >> stack to have a --with-ghc option to tell it what GHC to use? >> >> On 14 September 2016 at 16:23, Christopher Allen >> wrote: >> >>> Probably pretty similarly to how we use patched GHCJS at work with Stack. >>> >>> -- from the stack.yaml >>> system-ghc: true >>> compiler: ghcjs-0.2.0_ghc-7.10.2 >>> resolver: ghcjs-0.2.0_ghc-7.10.2 >>> >>> -- in the Makefile >>> ghcjs: >>> git clone https://github.com/myorg/ghcjs >>> cd ghcjs && stack setup && stack install >>> cd ghcjs && stack install cabal-install alex happy >>> cd ghcjs && stack exec -- ghcjs-boot --dev --no-haddock >>> >>> It's just picking GHCJS up from the path, with system-ghc: true, we're >>> telling it that is kosher. >>> >>> We disable system-ghc usage for regular GHC projects, it makes >>> profiling less convenient than if you use a Stack managed GHC but if >>> you're doing GHC dev the difference means nothing. >>> >>> On Wed, Sep 14, 2016 at 9:42 AM, Simon Marlow >>> wrote: >>> > How would I use stack with a GHC 8.0.2 release candidate? >>> > >>> > On 13 September 2016 at 21:27, Christopher Allen >>> wrote: >>> >> >>> >> Stack is not your shell, a build script, or a Makefile. It already has >>> >> path management for the GHC installations it provisions and supports. >>> >> It is not Stack's job to mutilate your path to support external GHC >>> >> installations. >>> >> >>> >> Make a Makefile or add shortcuts to your bashrc to switch compilers. >>> >> >>> >> On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso < >>> p.giarrusso at gmail.com> >>> >> wrote: >>> >> > On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher >>> Allen >>> >> > wrote: >>> >> >> >>> >> >> Stack users are moving away from enabling system installed GHCs by >>> >> >> default because it breaks the ease of enabling profiling for >>> libraries >>> >> >> when you're using a Stack-installed GHC. >>> >> > >>> >> > >>> >> >> >>> >> >> I'm not sure why multiple system-installed GHCs needs to be >>> supported >>> >> >> in addition to the GHC support Stack already provides. That's extra >>> >> >> work for...what? Stack isn't trying to compete with Nix. It's more >>> >> >> like a blend of rustup and cargo -- or Clojure's Leiningen. >>> >> > >>> >> > >>> >> > To clarify: I'm not proposing stack to install those GHCs, just to >>> use >>> >> > them. >>> >> > >>> >> > I think the extra work would be limited (calling GHC-X.Y.Z instead >>> of >>> >> > GHC) >>> >> > and has other technical advantages >>> >> > (https://github.com/commercialhaskell/stack/issues/2433). Mind >>> you, I'm >>> >> > willing to contribute the work and not asking anybody—I've just been >>> >> > busy. >>> >> > >>> >> > Right now I have to modify the PATH every time I use GHC 7.8.4 >>> because I >>> >> > needed to customize the build (I'm on OS X 10.11), but I still want >>> GHC >>> >> > 8 by >>> >> > default. >>> >> > >>> >> >> >>> >> >> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso < >>> p.gia... at gmail.com> >>> >> >> wrote: >>> >> >> > >>> >> >> > >>> >> >> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard >>> Eisenberg >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> Thanks, many, for explaining better ways to interact directly >>> with >>> >> >> >> GHC >>> >> >> >> after using a `stack setup`. Perhaps, then, all that’s stopping >>> >> >> >> someone >>> >> >> >> like >>> >> >> >> me from liking the ease of `stack setup` is a little missing PR >>> (as >>> >> >> >> in, >>> >> >> >> public relations). I understand that many people want to keep >>> GHC >>> >> >> >> cloistered >>> >> >> >> away to ease version swapping, but others (like me) want GHC >>> >> >> >> available >>> >> >> >> front >>> >> >> >> and center. >>> >> >> >> >>> >> >> >> Other minor points: >>> >> >> >> `stack env` does not work for me: my version of stack does not >>> know >>> >> >> >> how >>> >> >> >> to >>> >> >> >> `env`. >>> >> >> > >>> >> >> > >>> >> >> > That's correct—stack env was a feature request. >>> >> >> > >>> >> >> > The warning on `stack ghci` doesn't happen usually, but I'd say >>> >> >> > that's a >>> >> >> > bug >>> >> >> > (probably because it's a new install)? >>> >> >> > >>> >> >> > I use stack (and have contributed a bit recently), but I agree >>> >> >> > there's a >>> >> >> > few >>> >> >> > things stack could do better for this workflow. >>> >> >> > >>> >> >> > And the transition has a rather annoying learning curve—stack >>> ghci >>> >> >> > and >>> >> >> > stack >>> >> >> > ghc are not the same as ghci/ghc. I think that's on purpose to >>> >> >> > support a >>> >> >> > project-based workflow, and it has upsides, but it's a transition >>> >> >> > pitfall. >>> >> >> > Lots of things *are* explained in >>> >> >> > https://docs.haskellstack.org/en/latest/faq/, but you do need >>> learn a >>> >> >> > few >>> >> >> > things from scratch. >>> >> >> > >>> >> >> > You want stack exec ghc and stack exec ghci, and arbitrary >>> options >>> >> >> > require a >>> >> >> > double dash `--` — use `stack ghc -- --version` or `stack exec >>> -- ghc >>> >> >> > --version`. And I'm afraid the command syntax is mostly frozen by >>> >> >> > now. >>> >> >> > >>> >> >> > To support a compiler-based workflow, there are a few things >>> >> >> > planned—I >>> >> >> > opened an issue to collect them, starting from Simon Marlow's >>> recent >>> >> >> > email: >>> >> >> > https://github.com/commercialhaskell/stack/issues/2546 >>> >> >> > >>> >> >> > BTW, a system-installed GHC already works if you stick to one >>> (and >>> >> >> > only >>> >> >> > build projects that need that). But I'd love to support multiple >>> >> >> > system-installed GHCs and being able to pick the one you need. >>> >> >> > >>> >> >> > As others already explained, giving access to stack-installed >>> GHCs >>> >> >> > can >>> >> >> > be >>> >> >> > problematic—they're going to work, in part, exactly because you >>> can't >>> >> >> > install in their package database. >>> >> >> > >>> >> >> > Having stack install system-wide GHCs would IMHO risk opening a >>> can >>> >> >> > of >>> >> >> > worms—having working binaries for all Linux distros requires some >>> >> >> > work, >>> >> >> > system installers would be harder and most users would dislike >>> them. >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > Haskell-Cafe mailing list >>> >> >> > To (un)subscribe, modify options or view archives go to: >>> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> > Only members subscribed via the mailman list are allowed to post. >>> >> >> >>> >> >> -- >>> >> >> Chris Allen >>> >> >> Currently working on http://haskellbook.com >>> >> >> _______________________________________________ >>> >> >> Haskell-Cafe mailing list >>> >> >> To (un)subscribe, modify options or view archives go to: >>> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> Only members subscribed via the mailman list are allowed to post. >>> >> >>> >> >>> >> >>> >> -- >>> >> Chris Allen >>> >> Currently working on http://haskellbook.com >>> >> _______________________________________________ >>> >> Haskell-community mailing list >>> >> Haskell-community at haskell.org >>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> > >>> > >>> >>> >>> >>> -- >>> Chris Allen >>> Currently working on http://haskellbook.com >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Sep 14 19:21:58 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 14:21:58 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: What are you talking about? $ stack build simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "woot"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier wrote: > On 9/14/16 10:47 AM, David Feuer wrote: >> >> >> While we're griping about stack: it seems to place compiler output from >> -ddump-... in mysterious places that are hard to find without Google, and >> (worse) it seems to do something with stack test output that even Google >> can't discover. >> > > Also, compiler warnings get squirreled away in a file that I have to go > hunting for. It would be nice to have an option to print warnings (for > local packages, not dependencies) to stderr. > > --Patrick > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Chris Allen Currently working on http://haskellbook.com From cma at bitemyapp.com Wed Sep 14 19:26:24 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 14:26:24 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: Near as I can tell, it _is_ going to stderr just like you'd expect too $ stack build > log_output simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) simple-library-0.1.0.0: build Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hi"’ Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... simple-library-0.1.0.0: copy/register Installing library in /home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/lib/x86_64-linux-ghc-8.0.1/simple-library-0.1.0.0-IZ2irAKiR4w8tX3NVir98W Installing executable(s) in /home/callen/work/simple-library/.stack-work/install/x86_64-linux/lts-7.0/8.0.1/bin Registering simple-library-0.1.0.0... [ callen at pardalis ~/work/simple-library master ✗ ] $ stack build 2>&1 > log_output On Wed, Sep 14, 2016 at 2:21 PM, Christopher Allen wrote: > What are you talking about? > > $ stack build > simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) > simple-library-0.1.0.0: build > Preprocessing library simple-library-0.1.0.0... > [1 of 1] Compiling Lib ( src/Lib.hs, > .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) > > /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] > A do-notation statement discarded a result of type ‘[Char]’ > Suppress this warning by saying ‘_ <- return "woot"’ > Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... > > On Wed, Sep 14, 2016 at 2:10 PM, Patrick Pelletier > wrote: >> On 9/14/16 10:47 AM, David Feuer wrote: >>> >>> >>> While we're griping about stack: it seems to place compiler output from >>> -ddump-... in mysterious places that are hard to find without Google, and >>> (worse) it seems to do something with stack test output that even Google >>> can't discover. >>> >> >> Also, compiler warnings get squirreled away in a file that I have to go >> hunting for. It would be nice to have an option to print warnings (for >> local packages, not dependencies) to stderr. >> >> --Patrick >> >> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > > > -- > Chris Allen > Currently working on http://haskellbook.com -- Chris Allen Currently working on http://haskellbook.com From code at funwithsoftware.org Wed Sep 14 19:42:27 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 12:42:27 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> Message-ID: <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> On 9/14/16 12:21 PM, Christopher Allen wrote: > What are you talking about? > > $ stack build > simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) > simple-library-0.1.0.0: build > Preprocessing library simple-library-0.1.0.0... > [1 of 1] Compiling Lib ( src/Lib.hs, > .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) > > /home/callen/work/simple-library/src/Lib.hs:7:3: warning: [-Wunused-do-bind] > A do-notation statement discarded a result of type ‘[Char]’ > Suppress this warning by saying ‘_ <- return "woot"’ > Preprocessing executable 'simple-library-exe' for simple-library-0.1.0.0... Weird. That's not how it works for me: whiteandnerdy:normalize ppelleti$ stack build normalization-insensitive-2.0: unregistering (local file changes: Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInsensitive/Internal.hs) normalization-insensitive-2.0: configure normalization-insensitive-2.0: build normalization-insensitive-2.0: copy/register photos-0.1.0.0: configure photos-0.1.0.0: build photos-0.1.0.0: copy/register Completed 2 action(s). whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization-insensitive-2.0.log Configuring normalization-insensitive-2.0... Preprocessing library normalization-insensitive-2.0... [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( Data/Unicode/NormalizationInsensitive/Internal.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o ) Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: The import of ‘Data.Bool’ is redundant except perhaps to import instances from ‘Data.Bool’ To import instances alone, use: import Data.Bool() Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: The import of ‘otherwise, &&, <=, +’ from module ‘Prelude’ is redundant Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: Convert ByteString to Text and then normalize Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: Top-level binding with no type signature: mode :: NormalizationMode Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: In the use of ‘B.normalize’ (imported from Data.ByteString.UTF8.Normalize): Deprecated: "Convert ByteString to Text and then normalize" [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( Data/Unicode/NormalizationInsensitive/Unsafe.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o ) [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o ) Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ In-place registering normalization-insensitive-2.0... Installing library in /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM Registering normalization-insensitive-2.0... whiteandnerdy:normalize ppelleti$ I hadn't even been aware of these warnings in the package I was developing, until Harendra Kumar pointed them out to me, after I had uploaded a candidate to Hackage. --Patrick From toad3k at gmail.com Wed Sep 14 19:56:11 2016 From: toad3k at gmail.com (David McBride) Date: Wed, 14 Sep 2016 15:56:11 -0400 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: The rule of thumb seems to be, if you do a stack build and it decides to build multiple packages, it hides this log info. I understand why it does that, I should be able to build lens without worrying about tons of spurious output, but at the same time it is common for me to have an entire tree of packages I'm developing and it often obscures errors that are happening in my own packages. At the very least, if it is only building local packages, I'd very much like to see that output. On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier wrote: > On 9/14/16 12:21 PM, Christopher Allen wrote: > >> What are you talking about? >> >> $ stack build >> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) >> simple-library-0.1.0.0: build >> Preprocessing library simple-library-0.1.0.0... >> [1 of 1] Compiling Lib ( src/Lib.hs, >> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) >> >> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: >> [-Wunused-do-bind] >> A do-notation statement discarded a result of type ‘[Char]’ >> Suppress this warning by saying ‘_ <- return "woot"’ >> Preprocessing executable 'simple-library-exe' for >> simple-library-0.1.0.0... >> > > Weird. That's not how it works for me: > > whiteandnerdy:normalize ppelleti$ stack build > normalization-insensitive-2.0: unregistering (local file changes: > Data/Unicode/NormalizationInsensitive.hs Data/Unicode/NormalizationInse > nsitive/Internal.hs) > normalization-insensitive-2.0: configure > normalization-insensitive-2.0: build > normalization-insensitive-2.0: copy/register > photos-0.1.0.0: configure > photos-0.1.0.0: build > photos-0.1.0.0: copy/register > Completed 2 action(s). > whiteandnerdy:normalize ppelleti$ cat .stack-work/logs/normalization > -insensitive-2.0.log > Configuring normalization-insensitive-2.0... > Preprocessing library normalization-insensitive-2.0... > [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( > Data/Unicode/NormalizationInsensitive/Internal.hs, > .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod > e/NormalizationInsensitive/Internal.o ) > > Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: > The import of ‘Data.Bool’ is redundant > except perhaps to import instances from ‘Data.Bool’ > To import instances alone, use: import Data.Bool() > > Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: > The import of ‘otherwise, &&, <=, +’ > from module ‘Prelude’ is redundant > > Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: > Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: > Convert ByteString to Text and then normalize > > Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: > Top-level binding with no type signature: mode :: NormalizationMode > > Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: > In the use of ‘B.normalize’ > (imported from Data.ByteString.UTF8.Normalize): > Deprecated: "Convert ByteString to Text and then normalize" > > Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: > In the use of ‘B.normalize’ > (imported from Data.ByteString.UTF8.Normalize): > Deprecated: "Convert ByteString to Text and then normalize" > [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( > Data/Unicode/NormalizationInsensitive/Unsafe.hs, > .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod > e/NormalizationInsensitive/Unsafe.o ) > [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( > Data/Unicode/NormalizationInsensitive.hs, .stack-work/dist/x86_64-osx/Ca > bal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o ) > > Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: > ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ > In-place registering normalization-insensitive-2.0... > Installing library in > /Users/ppelleti/programming/haskell/normalize/.stack-work/in > stall/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/ > normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM > Registering normalization-insensitive-2.0... > whiteandnerdy:normalize ppelleti$ > > I hadn't even been aware of these warnings in the package I was > developing, until Harendra Kumar pointed them out to me, after I had > uploaded a candidate to Hackage. > > --Patrick > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Sep 14 20:10:22 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 15:10:22 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: I see what is meant now, but it's not really applicable. If I am co-developing a package and its dependencies, I add them as packages (not deps) to my stack.yaml and still get the warnings. Example: >From the stack.yaml for the package that uses my previous example's library: packages: - '.' - ../simple-library Then stack build'ing the project (uses-sl) that depends on simple-library which as a module with a warning: $ stack build simple-library-0.1.0.0: build Progress: 1/2 -- While building package simple-library-0.1.0.0 using: /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log Preprocessing library simple-library-0.1.0.0... [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: [-Wunused-do-bind] A do-notation statement discarded a result of type ‘[Char]’ Suppress this warning by saying ‘_ <- return "hello"’ One of the first things I did when figuring out Stack was to look at how Yesod used it: https://github.com/yesodweb/yesod/blob/master/stack.yaml On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote: > The rule of thumb seems to be, if you do a stack build and it decides to > build multiple packages, it hides this log info. > > I understand why it does that, I should be able to build lens without > worrying about tons of spurious output, but at the same time it is common > for me to have an entire tree of packages I'm developing and it often > obscures errors that are happening in my own packages. At the very least, > if it is only building local packages, I'd very much like to see that > output. > > On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier > wrote: >> >> On 9/14/16 12:21 PM, Christopher Allen wrote: >>> >>> What are you talking about? >>> >>> $ stack build >>> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) >>> simple-library-0.1.0.0: build >>> Preprocessing library simple-library-0.1.0.0... >>> [1 of 1] Compiling Lib ( src/Lib.hs, >>> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) >>> >>> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: >>> [-Wunused-do-bind] >>> A do-notation statement discarded a result of type ‘[Char]’ >>> Suppress this warning by saying ‘_ <- return "woot"’ >>> Preprocessing executable 'simple-library-exe' for >>> simple-library-0.1.0.0... >> >> >> Weird. That's not how it works for me: >> >> whiteandnerdy:normalize ppelleti$ stack build >> normalization-insensitive-2.0: unregistering (local file changes: >> Data/Unicode/NormalizationInsensitive.hs >> Data/Unicode/NormalizationInsensitive/Internal.hs) >> normalization-insensitive-2.0: configure >> normalization-insensitive-2.0: build >> normalization-insensitive-2.0: copy/register >> photos-0.1.0.0: configure >> photos-0.1.0.0: build >> photos-0.1.0.0: copy/register >> Completed 2 action(s). >> whiteandnerdy:normalize ppelleti$ cat >> .stack-work/logs/normalization-insensitive-2.0.log >> Configuring normalization-insensitive-2.0... >> Preprocessing library normalization-insensitive-2.0... >> [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( >> Data/Unicode/NormalizationInsensitive/Internal.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o >> ) >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: >> The import of ‘Data.Bool’ is redundant >> except perhaps to import instances from ‘Data.Bool’ >> To import instances alone, use: import Data.Bool() >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: >> The import of ‘otherwise, &&, <=, +’ >> from module ‘Prelude’ is redundant >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: >> Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: >> Convert ByteString to Text and then normalize >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: >> Top-level binding with no type signature: mode :: NormalizationMode >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: >> In the use of ‘B.normalize’ >> (imported from Data.ByteString.UTF8.Normalize): >> Deprecated: "Convert ByteString to Text and then normalize" >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: >> In the use of ‘B.normalize’ >> (imported from Data.ByteString.UTF8.Normalize): >> Deprecated: "Convert ByteString to Text and then normalize" >> [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( >> Data/Unicode/NormalizationInsensitive/Unsafe.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o >> ) >> [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( >> Data/Unicode/NormalizationInsensitive.hs, >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o >> ) >> >> Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: >> ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ >> In-place registering normalization-insensitive-2.0... >> Installing library in >> >> /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM >> Registering normalization-insensitive-2.0... >> whiteandnerdy:normalize ppelleti$ >> >> I hadn't even been aware of these warnings in the package I was >> developing, until Harendra Kumar pointed them out to me, after I had >> uploaded a candidate to Hackage. >> >> --Patrick >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -- Chris Allen Currently working on http://haskellbook.com From code at funwithsoftware.org Wed Sep 14 20:20:59 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 13:20:59 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> On 9/14/16 1:10 PM, Christopher Allen wrote: > I see what is meant now, but it's not really applicable. If I am > co-developing a package and its dependencies, I add them as packages > (not deps) to my stack.yaml and still get the warnings. > > Example: > > From the stack.yaml for the package that uses my previous example's library: > > > packages: > - '.' > - ../simple-library > > > Then stack build'ing the project (uses-sl) that depends on > simple-library which as a module with a warning: Hmmm... that is what I'm doing. My stack.yaml contains: packages: - normalization-insensitive/ - photos/ - unicode-transforms/ The package I'm developing is normalization-insensitive, but I need unicode-transforms as a dependency. (And at the time, unicode-transforms was not available on hackage, so I had to check it out locally.) And then photos is a simple application that uses normalization-insensitive. But when I do "stack build", it does not print the warnings for normalization-insensitive. --Patrick From cma at bitemyapp.com Wed Sep 14 20:26:12 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 15:26:12 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> <0ad5ef8e-7362-3258-5209-75d69e7d77a7@funwithsoftware.org> Message-ID: Weird. I'd say it's worth raising a bug over whether it's intentional behavior or not. A package not marked as an extra dep IME reports warnings and IMO _should_. If you don't have time, tell me and I'll report it for you. On Wed, Sep 14, 2016 at 3:20 PM, Patrick Pelletier wrote: > On 9/14/16 1:10 PM, Christopher Allen wrote: >> >> I see what is meant now, but it's not really applicable. If I am >> co-developing a package and its dependencies, I add them as packages >> (not deps) to my stack.yaml and still get the warnings. >> >> Example: >> >> From the stack.yaml for the package that uses my previous example's >> library: >> >> >> packages: >> - '.' >> - ../simple-library >> >> >> Then stack build'ing the project (uses-sl) that depends on >> simple-library which as a module with a warning: > > > Hmmm... that is what I'm doing. My stack.yaml contains: > > packages: > - normalization-insensitive/ > - photos/ > - unicode-transforms/ > > The package I'm developing is normalization-insensitive, but I need > unicode-transforms as a dependency. (And at the time, unicode-transforms > was not available on hackage, so I had to check it out locally.) And then > photos is a simple application that uses normalization-insensitive. > > But when I do "stack build", it does not print the warnings for > normalization-insensitive. > > --Patrick > -- Chris Allen Currently working on http://haskellbook.com From toad3k at gmail.com Wed Sep 14 20:26:26 2016 From: toad3k at gmail.com (David McBride) Date: Wed, 14 Sep 2016 16:26:26 -0400 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: That's not what I'm observering. I intentially put -Wall and some odd code in a local copy of pipes-csv, stack clean, stack build. /home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: A do-notation statement discarded a result of type ‘String’ Suppress this warning by saying ‘_ <- getLine’ or by using the flag -fno-warn-unused-do-bind In another project, stack clean, stack build pipes-csv-1.4.0: configure pipes-csv-1.4.0: build pipes-csv-1.4.0: copy/register Nothing at all. stack.yaml is basically this, but with a few extra packages. flags: {} packages: - '.' - '../pipes-csv-1.4.0' extra-deps: [] resolver: lts-3.1 stack --version Version 1.1.2 x86_64 hpack-0.14.0 On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen wrote: > I see what is meant now, but it's not really applicable. If I am > co-developing a package and its dependencies, I add them as packages > (not deps) to my stack.yaml and still get the warnings. > > Example: > > From the stack.yaml for the package that uses my previous example's > library: > > > packages: > - '.' > - ../simple-library > > > Then stack build'ing the project (uses-sl) that depends on > simple-library which as a module with a warning: > > > $ stack build > simple-library-0.1.0.0: build > Progress: 1/2 > -- While building package simple-library-0.1.0.0 using: > /home/callen/.stack/setup-exe-cache/x86_64-linux/setup- > Simple-Cabal-1.24.0.0-ghc-8.0.1 > --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build > lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi > -ddump-to-file" > Process exited with code: ExitFailure 1 > Logs have been written to: > /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log > > Preprocessing library simple-library-0.1.0.0... > [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, > .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) > > /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: > [-Wunused-do-bind] > A do-notation statement discarded a result of type ‘[Char]’ > Suppress this warning by saying ‘_ <- return "hello"’ > > > > One of the first things I did when figuring out Stack was to look at > how Yesod used it: > https://github.com/yesodweb/yesod/blob/master/stack.yaml > > On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote: > > The rule of thumb seems to be, if you do a stack build and it decides to > > build multiple packages, it hides this log info. > > > > I understand why it does that, I should be able to build lens without > > worrying about tons of spurious output, but at the same time it is common > > for me to have an entire tree of packages I'm developing and it often > > obscures errors that are happening in my own packages. At the very > least, > > if it is only building local packages, I'd very much like to see that > > output. > > > > On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier > > wrote: > >> > >> On 9/14/16 12:21 PM, Christopher Allen wrote: > >>> > >>> What are you talking about? > >>> > >>> $ stack build > >>> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) > >>> simple-library-0.1.0.0: build > >>> Preprocessing library simple-library-0.1.0.0... > >>> [1 of 1] Compiling Lib ( src/Lib.hs, > >>> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) > >>> > >>> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: > >>> [-Wunused-do-bind] > >>> A do-notation statement discarded a result of type ‘[Char]’ > >>> Suppress this warning by saying ‘_ <- return "woot"’ > >>> Preprocessing executable 'simple-library-exe' for > >>> simple-library-0.1.0.0... > >> > >> > >> Weird. That's not how it works for me: > >> > >> whiteandnerdy:normalize ppelleti$ stack build > >> normalization-insensitive-2.0: unregistering (local file changes: > >> Data/Unicode/NormalizationInsensitive.hs > >> Data/Unicode/NormalizationInsensitive/Internal.hs) > >> normalization-insensitive-2.0: configure > >> normalization-insensitive-2.0: build > >> normalization-insensitive-2.0: copy/register > >> photos-0.1.0.0: configure > >> photos-0.1.0.0: build > >> photos-0.1.0.0: copy/register > >> Completed 2 action(s). > >> whiteandnerdy:normalize ppelleti$ cat > >> .stack-work/logs/normalization-insensitive-2.0.log > >> Configuring normalization-insensitive-2.0... > >> Preprocessing library normalization-insensitive-2.0... > >> [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( > >> Data/Unicode/NormalizationInsensitive/Internal.hs, > >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/ > NormalizationInsensitive/Internal.o > >> ) > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: > >> The import of ‘Data.Bool’ is redundant > >> except perhaps to import instances from ‘Data.Bool’ > >> To import instances alone, use: import Data.Bool() > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: > >> The import of ‘otherwise, &&, <=, +’ > >> from module ‘Prelude’ is redundant > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: > >> Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: > >> Convert ByteString to Text and then normalize > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: > >> Top-level binding with no type signature: mode :: NormalizationMode > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: > >> In the use of ‘B.normalize’ > >> (imported from Data.ByteString.UTF8.Normalize): > >> Deprecated: "Convert ByteString to Text and then normalize" > >> > >> Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: > >> In the use of ‘B.normalize’ > >> (imported from Data.ByteString.UTF8.Normalize): > >> Deprecated: "Convert ByteString to Text and then normalize" > >> [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( > >> Data/Unicode/NormalizationInsensitive/Unsafe.hs, > >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/ > NormalizationInsensitive/Unsafe.o > >> ) > >> [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( > >> Data/Unicode/NormalizationInsensitive.hs, > >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/ > NormalizationInsensitive.o > >> ) > >> > >> Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: > >> ‘normalize’ is exported by ‘Normalizable(normalize)’ and ‘normalize’ > >> In-place registering normalization-insensitive-2.0... > >> Installing library in > >> > >> /Users/ppelleti/programming/haskell/normalize/.stack-work/ > install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10. > 3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM > >> Registering normalization-insensitive-2.0... > >> whiteandnerdy:normalize ppelleti$ > >> > >> I hadn't even been aware of these warnings in the package I was > >> developing, until Harendra Kumar pointed them out to me, after I had > >> uploaded a candidate to Hackage. > >> > >> --Patrick > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > > > > > > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Sep 14 20:30:44 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 14 Sep 2016 15:30:44 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: I think mine showed because of an error, they should be visible regardless for packages not marked extra-dep IMO anyway, so I'm going to file the issue. On Wed, Sep 14, 2016 at 3:26 PM, David McBride wrote: > That's not what I'm observering. I intentially put -Wall and some odd code > in a local copy of pipes-csv, stack clean, stack build. > > /home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: > A do-notation statement discarded a result of type ‘String’ > Suppress this warning by saying ‘_ <- getLine’ > or by using the flag -fno-warn-unused-do-bind > > In another project, stack clean, stack build > > pipes-csv-1.4.0: configure > pipes-csv-1.4.0: build > pipes-csv-1.4.0: copy/register > > Nothing at all. > > stack.yaml is basically this, but with a few extra packages. > > flags: {} > packages: > - '.' > - '../pipes-csv-1.4.0' > extra-deps: [] > resolver: lts-3.1 > > stack --version > Version 1.1.2 x86_64 hpack-0.14.0 > > > On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen > wrote: >> >> I see what is meant now, but it's not really applicable. If I am >> co-developing a package and its dependencies, I add them as packages >> (not deps) to my stack.yaml and still get the warnings. >> >> Example: >> >> From the stack.yaml for the package that uses my previous example's >> library: >> >> >> packages: >> - '.' >> - ../simple-library >> >> >> Then stack build'ing the project (uses-sl) that depends on >> simple-library which as a module with a warning: >> >> >> $ stack build >> simple-library-0.1.0.0: build >> Progress: 1/2 >> -- While building package simple-library-0.1.0.0 using: >> >> /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 >> --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build >> lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi >> -ddump-to-file" >> Process exited with code: ExitFailure 1 >> Logs have been written to: >> /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log >> >> Preprocessing library simple-library-0.1.0.0... >> [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, >> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) >> >> /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: >> [-Wunused-do-bind] >> A do-notation statement discarded a result of type ‘[Char]’ >> Suppress this warning by saying ‘_ <- return "hello"’ >> >> >> >> One of the first things I did when figuring out Stack was to look at >> how Yesod used it: >> https://github.com/yesodweb/yesod/blob/master/stack.yaml >> >> On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote: >> > The rule of thumb seems to be, if you do a stack build and it decides to >> > build multiple packages, it hides this log info. >> > >> > I understand why it does that, I should be able to build lens without >> > worrying about tons of spurious output, but at the same time it is >> > common >> > for me to have an entire tree of packages I'm developing and it often >> > obscures errors that are happening in my own packages. At the very >> > least, >> > if it is only building local packages, I'd very much like to see that >> > output. >> > >> > On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier >> > wrote: >> >> >> >> On 9/14/16 12:21 PM, Christopher Allen wrote: >> >>> >> >>> What are you talking about? >> >>> >> >>> $ stack build >> >>> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) >> >>> simple-library-0.1.0.0: build >> >>> Preprocessing library simple-library-0.1.0.0... >> >>> [1 of 1] Compiling Lib ( src/Lib.hs, >> >>> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) >> >>> >> >>> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: >> >>> [-Wunused-do-bind] >> >>> A do-notation statement discarded a result of type ‘[Char]’ >> >>> Suppress this warning by saying ‘_ <- return "woot"’ >> >>> Preprocessing executable 'simple-library-exe' for >> >>> simple-library-0.1.0.0... >> >> >> >> >> >> Weird. That's not how it works for me: >> >> >> >> whiteandnerdy:normalize ppelleti$ stack build >> >> normalization-insensitive-2.0: unregistering (local file changes: >> >> Data/Unicode/NormalizationInsensitive.hs >> >> Data/Unicode/NormalizationInsensitive/Internal.hs) >> >> normalization-insensitive-2.0: configure >> >> normalization-insensitive-2.0: build >> >> normalization-insensitive-2.0: copy/register >> >> photos-0.1.0.0: configure >> >> photos-0.1.0.0: build >> >> photos-0.1.0.0: copy/register >> >> Completed 2 action(s). >> >> whiteandnerdy:normalize ppelleti$ cat >> >> .stack-work/logs/normalization-insensitive-2.0.log >> >> Configuring normalization-insensitive-2.0... >> >> Preprocessing library normalization-insensitive-2.0... >> >> [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( >> >> Data/Unicode/NormalizationInsensitive/Internal.hs, >> >> >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Internal.o >> >> ) >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: >> >> The import of ‘Data.Bool’ is redundant >> >> except perhaps to import instances from ‘Data.Bool’ >> >> To import instances alone, use: import Data.Bool() >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: >> >> The import of ‘otherwise, &&, <=, +’ >> >> from module ‘Prelude’ is redundant >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: >> >> Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: >> >> Convert ByteString to Text and then normalize >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: >> >> Top-level binding with no type signature: mode :: NormalizationMode >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: >> >> In the use of ‘B.normalize’ >> >> (imported from Data.ByteString.UTF8.Normalize): >> >> Deprecated: "Convert ByteString to Text and then normalize" >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: >> >> In the use of ‘B.normalize’ >> >> (imported from Data.ByteString.UTF8.Normalize): >> >> Deprecated: "Convert ByteString to Text and then normalize" >> >> [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( >> >> Data/Unicode/NormalizationInsensitive/Unsafe.hs, >> >> >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive/Unsafe.o >> >> ) >> >> [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( >> >> Data/Unicode/NormalizationInsensitive.hs, >> >> >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicode/NormalizationInsensitive.o >> >> ) >> >> >> >> Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: >> >> ‘normalize’ is exported by ‘Normalizable(normalize)’ and >> >> ‘normalize’ >> >> In-place registering normalization-insensitive-2.0... >> >> Installing library in >> >> >> >> >> >> /Users/ppelleti/programming/haskell/normalize/.stack-work/install/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM >> >> Registering normalization-insensitive-2.0... >> >> whiteandnerdy:normalize ppelleti$ >> >> >> >> I hadn't even been aware of these warnings in the package I was >> >> developing, until Harendra Kumar pointed them out to me, after I had >> >> uploaded a candidate to Hackage. >> >> >> >> --Patrick >> >> >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> > >> > >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com > > -- Chris Allen Currently working on http://haskellbook.com From olf at aatal-apotheke.de Wed Sep 14 21:00:03 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 14 Sep 2016 23:00:03 +0200 Subject: [Haskell-cafe] technical thoughts on stack Message-ID: I second Richard's observations about project-centered vs. compiler-centered workflows. I used to test all my code in ghci until cabal ended up installing two versions of the same package. Stack helped me to obtain a working Haskell environment again. But: While it is nicer to have the `real' code organized as a proper project, I still haven't figured out how to test individual modules in stack ghci without either loading the entire project or making an executable foo that imports the module and loading the executable with stack ghci project:exe:foo And I can't easily have a traditional GHC install alongside for testing since the haskell platform for the operating system uses a different base package. -- Olaf From manny at fpcomplete.com Wed Sep 14 23:45:29 2016 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Wed, 14 Sep 2016 23:45:29 +0000 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: What you describe sounds a lot like this issue: https://github.com/commercialhaskell/stack/issues/2545 On Wed, Sep 14, 2016 at 1:26 PM David McBride wrote: > That's not what I'm observering. I intentially put -Wall and some odd > code in a local copy of pipes-csv, stack clean, stack build. > > /home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: > A do-notation statement discarded a result of type ‘String’ > Suppress this warning by saying ‘_ <- getLine’ > or by using the flag -fno-warn-unused-do-bind > > In another project, stack clean, stack build > > pipes-csv-1.4.0: configure > pipes-csv-1.4.0: build > pipes-csv-1.4.0: copy/register > > Nothing at all. > > stack.yaml is basically this, but with a few extra packages. > > flags: {} > packages: > - '.' > - '../pipes-csv-1.4.0' > extra-deps: [] > resolver: lts-3.1 > > stack --version > Version 1.1.2 x86_64 hpack-0.14.0 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Thu Sep 15 00:42:17 2016 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu, 15 Sep 2016 01:42:17 +0100 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <1473900137.2517.141.camel@googlemail.com> On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit > of interest (as many of us have). The discussion inspired me to take > another look at stack. Here are the results of that foray. Since this is all being discussed now, it is perhaps worth explaining what the cabal developers are working on and the direction they're going. The cabal tool is getting a major overhaul. At this point there's a relatively large group of people who have been "dogfooding" it in their normal daily work for months (and for a few brave users since the beginning of the year). There is a tech preview of this in the 1.24 release. The latest git version has a user guide which explains things in more detail, and what you can expect to work already and what is known to be incomplete (including several temporary workarounds for missing features). https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html What is broadly the same is that it still supports the "library solver- based, work with my current ghc / environment" style that people have mentioned in this thread. For example by default it picks up the ghc on your path (and will automagically do the right thing if you change your path). That said, the intention is also to better support a "application frozen / package collection" style, which is the style that stack supports well currently. What is new is that it does what it does a whole lot better, more conveniently, more predictably. There's a lot fewer cases where you have to use multiple commands to do various steps. Much of the time you can simply ask to build/repl something, and everything else is automatic (and quick to not do much if not much changed). It's more predictable in that it's much more deterministic. The choices about what versions etc are picked depend only on your environment (e.g. ghc version), hackage snapshot and local explicit project state. In particular it does not matter what you installed previously. (To support the application/frozen workflows these aspects of the environment can all be captured and frozen in a project file.) It also avoids the "cabal hell" issues of clashing installed versions. Or to put it another way, it's a bit like sandboxing but without the mental overhead or the waiting around for everything to build (because there's automatic maximal sharing of built packages, a la nix). It *is* project based, but a minimal project can actually be implicit, and most projects don't need to specify anything more than a list (or glob) of the directories of the packages in the project. One of the things you were mentioning was how nice it is to just be able to run ghc or ghci on a source file, or even without any file, just to play around. A feature that will be landing soon in cabal- install head is the ability to simply run ghc/ghci within a cabal project directory and ghc will start up in the environment of the project. No extra wrapper scripts, shell sessions or env vars necessary. So the short term goal is to get all this to the stage where it can replace the default UI in the cabal tool, and thereafter one goal is to better support the workflow style that stack currently supports well, ie applications with frozen / carefully change-controlled environment, and package collections/snapshots chosen by 3rd parties. I should also say that any help is most welcome. Development takes place on github. We now have several active reviewers so review & feedback on contributions is very quick. It's not all just hard problems, there's plenty to do for newcommers too (e.g. write that tutorial!). There's an active #hackage IRC channel. Newcommers are always welcome. Duncan From harendra.kumar at gmail.com Thu Sep 15 02:46:26 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 15 Sep 2016 08:16:26 +0530 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <1473900137.2517.141.camel@googlemail.com> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: That's good news. I think the community will benefit from a healthy competition among the tools. It is good to have choices in terms of the front end but I would rather prefer a unified specification of configuration. Currently with a stack workflow one has to deal with two config files i.e. stack.yaml and project.cabal. There is no reason why the stack and cabal configs cannot be unified. The concept of frozen snapshots is generic and useful enough to be incorporated as a common specification used by all tools. If there is a unified config then the same package can be used with stack or cabal, with hackage or stackage without any problems, choose what you prefer. Another point that I want to make is that I have found the cabal config files hard to deal with. There are a number of annoying problems with it and it lacks in reuse. That is the reason for tools like hpack ( https://github.com/sol/hpack) to be built to overcome those problems. I think the problems that hpack solves should be natively solved by cabal. I guess these problems are long pending and cabal did not evolve fast enough. That could be one of the reasons for wrappers on top of cabal or competing tools like stack getting created. Are there any thoughts going towards a better config specification? While we are at it it maybe good to have an extensible config which can provide optional tool specific extensions. -harendra On 15 September 2016 at 06:12, Duncan Coutts via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > On Tue, 2016-09-13 at 14:58 -0400, Richard Eisenberg wrote: > > I’ve watched the recent back-and-forth about stack with quite a bit > > of interest (as many of us have). The discussion inspired me to take > > another look at stack. Here are the results of that foray. > > Since this is all being discussed now, it is perhaps worth explaining > what the cabal developers are working on and the direction they're > going. > > The cabal tool is getting a major overhaul. At this point there's a > relatively large group of people who have been "dogfooding" it in their > normal daily work for months (and for a few brave users since the > beginning of the year). > > There is a tech preview of this in the 1.24 release. The latest git > version has a user guide which explains things in more detail, and what > you can expect to work already and what is known to be incomplete > (including several temporary workarounds for missing features). > > https://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > > What is broadly the same is that it still supports the "library solver- > based, work with my current ghc / environment" style that people have > mentioned in this thread. For example by default it picks up the ghc on > your path (and will automagically do the right thing if you change your > path). > > That said, the intention is also to better support a "application > frozen / package collection" style, which is the style that stack > supports well currently. > > What is new is that it does what it does a whole lot better, more > conveniently, more predictably. There's a lot fewer cases where you > have to use multiple commands to do various steps. Much of the time you > can simply ask to build/repl something, and everything else is > automatic (and quick to not do much if not much changed). It's more > predictable in that it's much more deterministic. The choices about > what versions etc are picked depend only on your environment (e.g. ghc > version), hackage snapshot and local explicit project state. In > particular it does not matter what you installed previously. (To > support the application/frozen workflows these aspects of the > environment can all be captured and frozen in a project file.) > > It also avoids the "cabal hell" issues of clashing installed versions. > Or to put it another way, it's a bit like sandboxing but without the > mental overhead or the waiting around for everything to build (because > there's automatic maximal sharing of built packages, a la nix). > > It *is* project based, but a minimal project can actually be implicit, > and most projects don't need to specify anything more than a list (or > glob) of the directories of the packages in the project. > > One of the things you were mentioning was how nice it is to just be > able to run ghc or ghci on a source file, or even without any file, > just to play around. A feature that will be landing soon in cabal- > install head is the ability to simply run ghc/ghci within a cabal > project directory and ghc will start up in the environment of the > project. No extra wrapper scripts, shell sessions or env vars > necessary. > > So the short term goal is to get all this to the stage where it can > replace the default UI in the cabal tool, and thereafter one goal is to > better support the workflow style that stack currently supports well, > ie applications with frozen / carefully change-controlled environment, > and package collections/snapshots chosen by 3rd parties. > > I should also say that any help is most welcome. Development takes > place on github. We now have several active reviewers so review & > feedback on contributions is very quick. It's not all just hard > problems, there's plenty to do for newcommers too (e.g. write that > tutorial!). There's an active #hackage IRC channel. Newcommers are > always welcome. > > Duncan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Sep 15 04:26:36 2016 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 15 Sep 2016 07:26:36 +0300 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <792CA860-2CEC-43C0-9DBA-B7ABB8742839@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: I can give more technical details on warning output: it's purely an issue of compromise between many different (and annoying) ways of displaying things. Firstly, the behavior Chris Allen is commenting: if there is a single local target package that you're building, then all of its GHC output is displayed to the console, including warnings. The dependency output is still sent to log files instead, keeping the console relatively free of output most people will not care about (general feeling I've seen is if a dependency has warnings, you don't want to see them, much less a list of all modules being compiled). The issue is: what happens if you're building multiple local packages? There are a number of options, all of which seem to get in _someone's_ way: 1. What we do today: send all output to the logs 2. Spit output to the console as it occurs, which will interleave content from multiple builds 3. Save the output to a log file, and then display all of the log files to the user at the end, which would result in looking for a needle in a haystack in many cases When I put together the initial code for running builds, I chose (1), which we still have today. It may be interesting to note that I did this mostly based off of my experience with cabal-install doing the same thing (whenever possible, I defaulted with cabal-install behavior, since it got many things right, and regardless is what people were used to). I tested this in the http-client repo by introducing a warning and running: cabal install ./http-client ./http-client-tls/ --ghc-option -Wall You can see the results at: https://gist.github.com/snoyberg/a50f4fc9505aa32aec835630dd749b77 By contrast, `stack build http-client-tls` spits out all of the warnings to the console as they happen. So my recommendation for people who are warning-sensitive and using Stack: 1. Use the `--pedantic` flag to turn on both `-Wall -Werror`. This is doubly-good: not only will you definitely see the warnings, but you won't accidentally miss them by an interim compile. (This can easily happen if you're using the `--file-watch` flag.) 2. Build one package in your project at a time. If people have ideas for other ways of handling this that I haven't listed, let's start a separate thread to discuss them. On Wed, Sep 14, 2016 at 11:26 PM, David McBride wrote: > That's not what I'm observering. I intentially put -Wall and some odd > code in a local copy of pipes-csv, stack clean, stack build. > > /home/toad/working/pipes-csv-1.4.0/src/Pipes/Csv.hs:216:3: Warning: > A do-notation statement discarded a result of type ‘String’ > Suppress this warning by saying ‘_ <- getLine’ > or by using the flag -fno-warn-unused-do-bind > > In another project, stack clean, stack build > > pipes-csv-1.4.0: configure > pipes-csv-1.4.0: build > pipes-csv-1.4.0: copy/register > > Nothing at all. > > stack.yaml is basically this, but with a few extra packages. > > flags: {} > packages: > - '.' > - '../pipes-csv-1.4.0' > extra-deps: [] > resolver: lts-3.1 > > stack --version > Version 1.1.2 x86_64 hpack-0.14.0 > > > On Wed, Sep 14, 2016 at 4:10 PM, Christopher Allen > wrote: > >> I see what is meant now, but it's not really applicable. If I am >> co-developing a package and its dependencies, I add them as packages >> (not deps) to my stack.yaml and still get the warnings. >> >> Example: >> >> From the stack.yaml for the package that uses my previous example's >> library: >> >> >> packages: >> - '.' >> - ../simple-library >> >> >> Then stack build'ing the project (uses-sl) that depends on >> simple-library which as a module with a warning: >> >> >> $ stack build >> simple-library-0.1.0.0: build >> Progress: 1/2 >> -- While building package simple-library-0.1.0.0 using: >> /home/callen/.stack/setup-exe-cache/x86_64-linux/setup-Simpl >> e-Cabal-1.24.0.0-ghc-8.0.1 >> --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build >> lib:simple-library exe:simple-library-exe --ghc-options " -ddump-hi >> -ddump-to-file" >> Process exited with code: ExitFailure 1 >> Logs have been written to: >> /home/callen/work/uses-sl/.stack-work/logs/simple-library-0.1.0.0.log >> >> Preprocessing library simple-library-0.1.0.0... >> [1 of 1] Compiling SimpleLib ( src/SimpleLib.hs, >> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/SimpleLib.o ) >> >> /home/callen/work/simple-library/src/SimpleLib.hs:7:3: warning: >> [-Wunused-do-bind] >> A do-notation statement discarded a result of type ‘[Char]’ >> Suppress this warning by saying ‘_ <- return "hello"’ >> >> >> >> One of the first things I did when figuring out Stack was to look at >> how Yesod used it: >> https://github.com/yesodweb/yesod/blob/master/stack.yaml >> >> On Wed, Sep 14, 2016 at 2:56 PM, David McBride wrote: >> > The rule of thumb seems to be, if you do a stack build and it decides to >> > build multiple packages, it hides this log info. >> > >> > I understand why it does that, I should be able to build lens without >> > worrying about tons of spurious output, but at the same time it is >> common >> > for me to have an entire tree of packages I'm developing and it often >> > obscures errors that are happening in my own packages. At the very >> least, >> > if it is only building local packages, I'd very much like to see that >> > output. >> > >> > On Wed, Sep 14, 2016 at 3:42 PM, Patrick Pelletier >> > wrote: >> >> >> >> On 9/14/16 12:21 PM, Christopher Allen wrote: >> >>> >> >>> What are you talking about? >> >>> >> >>> $ stack build >> >>> simple-library-0.1.0.0: unregistering (local file changes: src/Lib.hs) >> >>> simple-library-0.1.0.0: build >> >>> Preprocessing library simple-library-0.1.0.0... >> >>> [1 of 1] Compiling Lib ( src/Lib.hs, >> >>> .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Lib.o ) >> >>> >> >>> /home/callen/work/simple-library/src/Lib.hs:7:3: warning: >> >>> [-Wunused-do-bind] >> >>> A do-notation statement discarded a result of type ‘[Char]’ >> >>> Suppress this warning by saying ‘_ <- return "woot"’ >> >>> Preprocessing executable 'simple-library-exe' for >> >>> simple-library-0.1.0.0... >> >> >> >> >> >> Weird. That's not how it works for me: >> >> >> >> whiteandnerdy:normalize ppelleti$ stack build >> >> normalization-insensitive-2.0: unregistering (local file changes: >> >> Data/Unicode/NormalizationInsensitive.hs >> >> Data/Unicode/NormalizationInsensitive/Internal.hs) >> >> normalization-insensitive-2.0: configure >> >> normalization-insensitive-2.0: build >> >> normalization-insensitive-2.0: copy/register >> >> photos-0.1.0.0: configure >> >> photos-0.1.0.0: build >> >> photos-0.1.0.0: copy/register >> >> Completed 2 action(s). >> >> whiteandnerdy:normalize ppelleti$ cat >> >> .stack-work/logs/normalization-insensitive-2.0.log >> >> Configuring normalization-insensitive-2.0... >> >> Preprocessing library normalization-insensitive-2.0... >> >> [1 of 3] Compiling Data.Unicode.NormalizationInsensitive.Internal ( >> >> Data/Unicode/NormalizationInsensitive/Internal.hs, >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod >> e/NormalizationInsensitive/Internal.o >> >> ) >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:30:1: Warning: >> >> The import of ‘Data.Bool’ is redundant >> >> except perhaps to import instances from ‘Data.Bool’ >> >> To import instances alone, use: import Data.Bool() >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:38:1: Warning: >> >> The import of ‘otherwise, &&, <=, +’ >> >> from module ‘Prelude’ is redundant >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:57:1: Warning: >> >> Module ‘Data.ByteString.UTF8.Normalize’ is deprecated: >> >> Convert ByteString to Text and then normalize >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:135:1: Warning: >> >> Top-level binding with no type signature: mode :: NormalizationMode >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:143:17: Warning: >> >> In the use of ‘B.normalize’ >> >> (imported from Data.ByteString.UTF8.Normalize): >> >> Deprecated: "Convert ByteString to Text and then normalize" >> >> >> >> Data/Unicode/NormalizationInsensitive/Internal.hs:147:33: Warning: >> >> In the use of ‘B.normalize’ >> >> (imported from Data.ByteString.UTF8.Normalize): >> >> Deprecated: "Convert ByteString to Text and then normalize" >> >> [2 of 3] Compiling Data.Unicode.NormalizationInsensitive.Unsafe ( >> >> Data/Unicode/NormalizationInsensitive/Unsafe.hs, >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod >> e/NormalizationInsensitive/Unsafe.o >> >> ) >> >> [3 of 3] Compiling Data.Unicode.NormalizationInsensitive ( >> >> Data/Unicode/NormalizationInsensitive.hs, >> >> .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Data/Unicod >> e/NormalizationInsensitive.o >> >> ) >> >> >> >> Data/Unicode/NormalizationInsensitive.hs:25:31: Warning: >> >> ‘normalize’ is exported by ‘Normalizable(normalize)’ and >> ‘normalize’ >> >> In-place registering normalization-insensitive-2.0... >> >> Installing library in >> >> >> >> /Users/ppelleti/programming/haskell/normalize/.stack-work/in >> stall/x86_64-osx/lts-6.1/7.10.3/lib/x86_64-osx-ghc-7.10.3/ >> normalization-insensitive-2.0-KLVtcrPtbow6nG8kRB6WPM >> >> Registering normalization-insensitive-2.0... >> >> whiteandnerdy:normalize ppelleti$ >> >> >> >> I hadn't even been aware of these warnings in the package I was >> >> developing, until Harendra Kumar pointed them out to me, after I had >> >> uploaded a candidate to Hackage. >> >> >> >> --Patrick >> >> >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> > >> > >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Thu Sep 15 05:25:05 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 22:25:05 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: On 9/14/16 9:26 PM, Michael Snoyman wrote: > I can give more technical details on warning output: it's purely an > issue of compromise between many different (and annoying) ways of > displaying things. Firstly, the behavior Chris Allen is commenting: if > there is a single local target package that you're building, then all > of its GHC output is displayed to the console, including warnings. AFAIK, this behavior is not clearly documented. > 3. Save the output to a log file, and then display all of the log > files to the user at the end, which would result in looking for a > needle in a haystack in many cases Is there any harm in having an option for this? If the number of local packages is small (3 in my case) and there are not a huge number of warnings, this still seems quite manageable. > When I put together the initial code for running builds, I chose (1), > which we still have today. It may be interesting to note that I did > this mostly based off of my experience with cabal-install doing the > same thing (whenever possible, I defaulted with cabal-install > behavior, since it got many things right, and regardless is what > people were used to). I'm used to using "cabal sandbox add-source" to add dependencies that I have locally checked out (e. g. because I've modified them, or because they aren't released on Hackage yet). cabal doesn't printing warnings for those dependencies, but it does always print warnings for the one package that I'm working on. (The one in the current directory.) As far as I know, stack doesn't make a distinction between "the package I'm working on now" and other dependencies which are checked out locally. They all go in "packages" in the stack.yaml. So, although it's not an apples-to-apples comparison, it is different behavior than I was getting with my cabal workflow. Thanks, --Patrick From michael at snoyman.com Thu Sep 15 05:39:05 2016 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 15 Sep 2016 08:39:05 +0300 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier wrote: > On 9/14/16 9:26 PM, Michael Snoyman wrote: > >> I can give more technical details on warning output: it's purely an issue >> of compromise between many different (and annoying) ways of displaying >> things. Firstly, the behavior Chris Allen is commenting: if there is a >> single local target package that you're building, then all of its GHC >> output is displayed to the console, including warnings. >> > > AFAIK, this behavior is not clearly documented. > > I'd be happy to add a comment. Do you have a recommendation of somewhere to put such an explanation that would make sense? > 3. Save the output to a log file, and then display all of the log files to >> the user at the end, which would result in looking for a needle in a >> haystack in many cases >> > > Is there any harm in having an option for this? If the number of local > packages is small (3 in my case) and there are not a huge number of > warnings, this still seems quite manageable. > > Perhaps a simple option to --dump-log-output, which at the end of a build prints all logs from all local packages? That's certainly possible, though I haven't touched that part of the code in quite a while. > When I put together the initial code for running builds, I chose (1), >> which we still have today. It may be interesting to note that I did this >> mostly based off of my experience with cabal-install doing the same thing >> (whenever possible, I defaulted with cabal-install behavior, since it got >> many things right, and regardless is what people were used to). >> > > I'm used to using "cabal sandbox add-source" to add dependencies that I > have locally checked out (e. g. because I've modified them, or because they > aren't released on Hackage yet). cabal doesn't printing warnings for those > dependencies, but it does always print warnings for the one package that > I'm working on. (The one in the current directory.) > > As far as I know, stack doesn't make a distinction between "the package > I'm working on now" and other dependencies which are checked out locally. > They all go in "packages" in the stack.yaml. > > So, although it's not an apples-to-apples comparison, it is different > behavior than I was getting with my cabal workflow. > > There is the extra-dep field in packages, but it wouldn't affect this specific case. But really, the way you tell Stack "the package I'm working on now" is by specifying it as a target on the command line, which _does_ work: `stack build http-client-tls` in my example above does in fact display the output on the console. Thanks for the feedback. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Thu Sep 15 06:06:29 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 23:06:29 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: On 9/14/16 7:46 PM, Harendra Kumar wrote: > That's good news. I think the community will benefit from a healthy > competition among the tools. It is good to have choices in terms of > the front end but I would rather prefer a unified specification of > configuration. Currently with a stack workflow one has to deal with > two config files i.e. stack.yaml and project.cabal. There is no reason > why the stack and cabal configs cannot be unified. To me, the stack.yaml and project.cabal file serve different purposes. The project.cabal specifies how to build a single package. Even if you want to (try to) build that library in a very different build environment, everything in the project.cabal is still meaningful: source files, dependencies, license, how to run tests and benchmarks, etc. The stack.yaml is about an entire build environment. It is about things that have to (of necessity) be the same for all the packages that go into an executable: compiler version, snapshot, etc. In other words, a single build environment can build many packages, and a single package can be built in many different environments. For example, in my directory structure for developing normalization-insensitive, I have three stack.yaml files: stack-7.8.yaml stack-7.10.yaml stack-8.0.yaml and I have three cabal files: unicode-transforms/unicode-transforms.cabal normalization-insensitive/normalization-insensitive.cabal photos/photos.cabal Each stack.yaml builds all three cabal projects. And each cabal project can be built by any of the three stack.yaml files. So, I see them as expressing very different concepts. > Another point that I want to make is that I have found the cabal > config files hard to deal with. There are a number of annoying > problems with it and it lacks in reuse. That is the reason for tools > like hpack (https://github.com/sol/hpack) to be built to overcome > those problems. I think the problems that hpack solves should be > natively solved by cabal. Yes, it would be nice if cabal-the-library could learn from hpack and solve some of the problems like redundancy. I just wouldn't want to see fragmentation of the Haskell ecosystem. (In other words, I want to be able to easily use any Haskell library as a dependency, even if the tools I am using are different than the tools the package author used.) > I guess these problems are long pending and cabal did not evolve fast > enough. That could be one of the reasons for wrappers on top of cabal > or competing tools like stack getting created. Well, hpack is addressing issues with the file format used by cabal-the-library, while stack is addressing issues with cabal-install-the-program. > Are there any thoughts going towards a better config specification? > While we are at it it maybe good to have an extensible config which > can provide optional tool specific extensions. Yes, that would be very nice. --Patrick From code at funwithsoftware.org Thu Sep 15 06:22:42 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Wed, 14 Sep 2016 23:22:42 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> Message-ID: <15cc6a13-66fc-86b9-694a-a086946b1c1e@funwithsoftware.org> On 9/14/16 10:39 PM, Michael Snoyman wrote: > On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier > > wrote: > > On 9/14/16 9:26 PM, Michael Snoyman wrote: > > I can give more technical details on warning output: it's > purely an issue of compromise between many different (and > annoying) ways of displaying things. Firstly, the behavior > Chris Allen is commenting: if there is a single local target > package that you're building, then all of its GHC output is > displayed to the console, including warnings. > > > AFAIK, this behavior is not clearly documented. > > > I'd be happy to add a comment. Do you have a recommendation of > somewhere to put such an explanation that would make sense? Probably either in: https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command or: https://docs.haskellstack.org/en/stable/build_command/ or both. > 3. Save the output to a log file, and then display all of the > log files to the user at the end, which would result in > looking for a needle in a haystack in many cases > > > Is there any harm in having an option for this? If the number of > local packages is small (3 in my case) and there are not a huge > number of warnings, this still seems quite manageable. > > > Perhaps a simple option to --dump-log-output, which at the end of a > build prints all logs from all local packages? That's certainly > possible, though I haven't touched that part of the code in quite a while. Yes, that would at least meet my needs. > When I put together the initial code for running builds, I > chose (1), which we still have today. It may be interesting to > note that I did this mostly based off of my experience with > cabal-install doing the same thing (whenever possible, I > defaulted with cabal-install behavior, since it got many > things right, and regardless is what people were used to). > > > I'm used to using "cabal sandbox add-source" to add dependencies > that I have locally checked out (e. g. because I've modified them, > or because they aren't released on Hackage yet). cabal doesn't > printing warnings for those dependencies, but it does always print > warnings for the one package that I'm working on. (The one in the > current directory.) > > As far as I know, stack doesn't make a distinction between "the > package I'm working on now" and other dependencies which are > checked out locally. They all go in "packages" in the stack.yaml. > > So, although it's not an apples-to-apples comparison, it is > different behavior than I was getting with my cabal workflow. > > > There is the extra-dep field in packages, but it wouldn't affect this > specific case. Right. My understanding is that extra-dep is for packages to fetch from Hackage that are outside the current resolver. (Cabal doesn't really have an equivalent option, since its implicit resolver is "everything in hackage.") On the other hand, "cabal sandbox add-source" is for packages on the local filesystem. > But really, the way you tell Stack "the package I'm working on now" is > by specifying it as a target on the command line, which _does_ work: > `stack build http-client-tls` in my example above does in fact display > the output on the console. Thanks! That (along with the tip about --pedantic) is good to know. --Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Sep 15 06:37:38 2016 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 15 Sep 2016 09:37:38 +0300 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <15cc6a13-66fc-86b9-694a-a086946b1c1e@funwithsoftware.org> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <20b11d5f-b5b5-41dc-4797-eb488b7e01a2@funwithsoftware.org> <1d260307-c443-e809-5c44-9edea99ab1ba@funwithsoftware.org> <15cc6a13-66fc-86b9-694a-a086946b1c1e@funwithsoftware.org> Message-ID: On Thu, Sep 15, 2016 at 9:22 AM, Patrick Pelletier wrote: > On 9/14/16 10:39 PM, Michael Snoyman wrote: > > On Thu, Sep 15, 2016 at 8:25 AM, Patrick Pelletier < > code at funwithsoftware.org> wrote: > >> On 9/14/16 9:26 PM, Michael Snoyman wrote: >> >>> I can give more technical details on warning output: it's purely an >>> issue of compromise between many different (and annoying) ways of >>> displaying things. Firstly, the behavior Chris Allen is commenting: if >>> there is a single local target package that you're building, then all of >>> its GHC output is displayed to the console, including warnings. >>> >> >> AFAIK, this behavior is not clearly documented. >> >> > I'd be happy to add a comment. Do you have a recommendation of somewhere > to put such an explanation that would make sense? > > > Probably either in: > > https://docs.haskellstack.org/en/stable/GUIDE/#the-build-command > > or: > > https://docs.haskellstack.org/en/stable/build_command/ > > or both. > > 3. Save the output to a log file, and then display all of the log files to >>> the user at the end, which would result in looking for a needle in a >>> haystack in many cases >>> >> >> Is there any harm in having an option for this? If the number of local >> packages is small (3 in my case) and there are not a huge number of >> warnings, this still seems quite manageable. >> >> > Perhaps a simple option to --dump-log-output, which at the end of a build > prints all logs from all local packages? That's certainly possible, though > I haven't touched that part of the code in quite a while. > > > Yes, that would at least meet my needs. > > Cool, both the docs and this new feature are covered in: https://github.com/commercialhaskell/stack/pull/2594 > When I put together the initial code for running builds, I chose (1), >>> which we still have today. It may be interesting to note that I did this >>> mostly based off of my experience with cabal-install doing the same thing >>> (whenever possible, I defaulted with cabal-install behavior, since it got >>> many things right, and regardless is what people were used to). >>> >> >> I'm used to using "cabal sandbox add-source" to add dependencies that I >> have locally checked out (e. g. because I've modified them, or because they >> aren't released on Hackage yet). cabal doesn't printing warnings for those >> dependencies, but it does always print warnings for the one package that >> I'm working on. (The one in the current directory.) >> >> As far as I know, stack doesn't make a distinction between "the package >> I'm working on now" and other dependencies which are checked out locally. >> They all go in "packages" in the stack.yaml. >> >> So, although it's not an apples-to-apples comparison, it is different >> behavior than I was getting with my cabal workflow. >> >> > There is the extra-dep field in packages, but it wouldn't affect this > specific case. > > > Right. My understanding is that extra-dep is for packages to fetch from > Hackage that are outside the current resolver. (Cabal doesn't really have > an equivalent option, since its implicit resolver is "everything in > hackage.") On the other hand, "cabal sandbox add-source" is for packages > on the local filesystem. > > extra-dep is the term for any package which isn't in the snapshot and is not one of the packages you're working on. There are two ways to get an extra-dep: * The common case: list one from Hackage using package/version in the extra-deps field * The less common way: specify one from a Git repo or a local directory in the packages field The second option is what I'm referring to here, and you can add a `extra-dep` setting there too to make it clear that, for example, `stack test` should not run the test suites for those packages. > But really, the way you tell Stack "the package I'm working on now" is by > specifying it as a target on the command line, which _does_ work: `stack > build http-client-tls` in my example above does in fact display the output > on the console. > > > Thanks! That (along with the tip about --pedantic) is good to know. > > FWIW, my common workflow with Stack is the following command: stack test --file-watch --fast --pedantic Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Thu Sep 15 07:32:50 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 15 Sep 2016 13:02:50 +0530 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: While I agree that stack.yaml is a frozen config, we do not necessarily need a separate config file or a separate format for that. My main point was a that a new user will have to understand two more languages (YAML/cabal) in addition to Haskell. We can have the config spread in multiple files, but they should look like an extension of the same thing rather than disparate things. The stack snapshot config can be seen as a higher level concept of the pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the snapshot is a point in that space. It can also be seen as a more general version of the "tested-with" field in the cabal file. We can instead say - tested-with these snapshots (or set of versions). Instead of using stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list which snapshot configs that are available and you can choose which one you want to build. The config could be tool agnostic. -harendra On 15 September 2016 at 11:36, Patrick Pelletier wrote: > On 9/14/16 7:46 PM, Harendra Kumar wrote: > >> That's good news. I think the community will benefit from a healthy >> competition among the tools. It is good to have choices in terms of the >> front end but I would rather prefer a unified specification of >> configuration. Currently with a stack workflow one has to deal with two >> config files i.e. stack.yaml and project.cabal. There is no reason why the >> stack and cabal configs cannot be unified. >> > > To me, the stack.yaml and project.cabal file serve different purposes. > The project.cabal specifies how to build a single package. Even if you > want to (try to) build that library in a very different build environment, > everything in the project.cabal is still meaningful: source files, > dependencies, license, how to run tests and benchmarks, etc. > > The stack.yaml is about an entire build environment. It is about things > that have to (of necessity) be the same for all the packages that go into > an executable: compiler version, snapshot, etc. > > In other words, a single build environment can build many packages, and a > single package can be built in many different environments. For example, in > my directory structure for developing normalization-insensitive, I have > three stack.yaml files: > > stack-7.8.yaml > stack-7.10.yaml > stack-8.0.yaml > > and I have three cabal files: > > unicode-transforms/unicode-transforms.cabal > normalization-insensitive/normalization-insensitive.cabal > photos/photos.cabal > > Each stack.yaml builds all three cabal projects. And each cabal project > can be built by any of the three stack.yaml files. So, I see them as > expressing very different concepts. > > Another point that I want to make is that I have found the cabal config >> files hard to deal with. There are a number of annoying problems with it >> and it lacks in reuse. That is the reason for tools like hpack ( >> https://github.com/sol/hpack) to be built to overcome those problems. I >> think the problems that hpack solves should be natively solved by cabal. >> > > Yes, it would be nice if cabal-the-library could learn from hpack and > solve some of the problems like redundancy. I just wouldn't want to see > fragmentation of the Haskell ecosystem. (In other words, I want to be able > to easily use any Haskell library as a dependency, even if the tools I am > using are different than the tools the package author used.) > > I guess these problems are long pending and cabal did not evolve fast >> enough. That could be one of the reasons for wrappers on top of cabal or >> competing tools like stack getting created. >> > > Well, hpack is addressing issues with the file format used by > cabal-the-library, while stack is addressing issues with > cabal-install-the-program. > > Are there any thoughts going towards a better config specification? While >> we are at it it maybe good to have an extensible config which can provide >> optional tool specific extensions. >> > > Yes, that would be very nice. > > --Patrick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duncan.coutts at googlemail.com Thu Sep 15 10:28:27 2016 From: duncan.coutts at googlemail.com (Duncan Coutts) Date: Thu, 15 Sep 2016 11:28:27 +0100 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: <1473935307.2517.161.camel@googlemail.com> On Thu, 2016-09-15 at 08:16 +0530, Harendra Kumar wrote: > That's good news. I think the community will benefit from a healthy > competition among the tools. It is good to have choices in terms of > the front end but I would rather prefer a unified specification of > configuration. Currently with a stack workflow one has to deal with > two config files i.e. stack.yaml and project.cabal. There is no > reason why the stack and cabal configs cannot be unified. As Patrick pointed out, your mypackage.cabal file covers a different concept to either a stack.yml (or cabal-install's equivalents a cabal.config or new cabal.project files). This comes back to the separation of roles between the package author and the package builder. Sometimes you are both the author and the builder, but often enough you are building someone else's package, or someone else is building your package. The person building the package gets to decide things about the environment that the author does not either know or choose (though they can describe the constraints on what range of environments work). So there has always been this separation between what you can write in a .cabal file (author role), and what you can say on the command line when you call cabal, or equivalently what you can write down in a cabal.config (or new cabal.project) files, or stack's equivalent the stack.yml file. > The concept of frozen snapshots is generic and useful enough to be > incorporated as a common specification used by all tools. The concept of package collections like stackage is certainly something that can have a common spec. More generally freezing involves keeping track of aspects of the environment, and this is a bit more fuzzy because it depends how far you want to go. One can just track versions of Haskell packages or go as far as nix style package management where all aspects of the input environment are captured. > If there is a unified config then the same package can be used with > stack or cabal, with hackage or stackage without any problems, choose > what you prefer. I don't foresee any particular problems here. They're using the same .cabal files, and hopefully at some point both will be able to use the same package collections. I don't think we'll unify the cabal.config (or new cabal.project) and stack.yml files any time soon since these deal with the project level builder role (as opposed to package level author role) and the way the two tools deal with these things is a bit different (and needs to be different so both tools can innovate). > Another point that I want to make is that I have found the cabal > config files hard to deal with. There are a number of annoying > problems with it and it lacks in reuse. That is the reason for tools > like hpack (https://github.com/sol/hpack) to be built to overcome > those problems. I think the problems that hpack solves should be > natively solved by cabal. I guess these problems are long pending and > cabal did not evolve fast enough. That could be one of the reasons > for wrappers on top of cabal or competing tools like stack getting > created. > > Are there any thoughts going towards a better config specification? > While we are at it it maybe good to have an extensible config which > can provide optional tool specific extensions. Yes. The plan is to allow "common" sections to be defined and then included/merged into other sections. At the simplest this would be one common section that is implicitly merged into all the components (ie libs, exes etc) but in general would be multiple named sections that are explicitly included. This change is dependent on a big rewrite of the .cabal file parser that is underway. Duncan From runesvend at gmail.com Thu Sep 15 11:51:31 2016 From: runesvend at gmail.com (Rune K. Svendsen) Date: Thu, 15 Sep 2016 04:51:31 -0700 (PDT) Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= In-Reply-To: <8BAD8EA7-733F-4C19-91B0-3F9A72826FDE@cis.upenn.edu> References: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> <8BAD8EA7-733F-4C19-91B0-3F9A72826FDE@cis.upenn.edu> Message-ID: <7a50599c-1a99-40a6-a96c-614cbbc9a553@googlegroups.com> On Monday, May 18, 2015 at 3:23:52 PM UTC+2, Richard Eisenberg wrote: > > > On May 18, 2015, at 9:06 AM, "Nicholls, Mark" > wrote: > > Hmmmm… > > OK, > > Any idea of a timescale > > > In ways that would be hard to predict, promoting all types is a fairly > massive change to GHC. If I merge in August, I'll be quite pleased. But it > really should be there by 7.12, which should occur by Feb/Mar '16. > On Monday, May 18, 2015 at 3:23:52 PM UTC+2, Richard Eisenberg wrote: > On May 18, 2015, at 9:06 AM, "Nicholls, Mark" wrote: > > Hmmmm… > > OK, > > Any idea of a timescale > > > In ways that would be hard to predict, promoting all types is a fairly > massive change to GHC. If I merge in August, I'll be quite pleased. But it > really should be there by 7.12, which should occur by Feb/Mar '16. > > I'd love to hear the status on this. I found this email thread, through a Google search, because I'm experiencing the same error. I have these tagged types that I want to make part of a Servant.Server.Internal.Context map, which is a type-level map, that automagically pulls out the right type to supply whatever is needed. As a mere programmer, this is fairly awesome to me, but I can't get it to work because of the aforementioned error. Here's the code: {-# LANGUAGE DataKinds, TypeOperators #-} import qualified Data.Tagged as Tag import Servant.Server.Internal.Context (Context(EmptyContext, (:.))) type BtcConf = Tag.Tagged "BTCConf" Word type SettlePeriod = Tag.Tagged "Hours" Word type DustLimit = Tag.Tagged "Dust" BitcoinAmount type ChanConf2 = BtcConf :. BitcoinAmount :. DustLimit :. Hours :. EmptyContext -- ERROR: -- Data constructor ':.' comes from an un-promotable type 'Context' /Rune -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Thu Sep 15 12:29:10 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 15 Sep 2016 17:59:10 +0530 Subject: [Haskell-cafe] Porting Haskell/C on Windows Message-ID: Hi, When porting a package with C source in it which C compilers should it be portable to? Can we just assume gcc (MinGW) or are there any other compilers as well that work with ghc? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Sep 15 14:23:41 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Thu, 15 Sep 2016 23:23:41 +0900 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> Message-ID: <1473949231-sup-150@sabre> Excerpts from Harendra Kumar's message of 2016-09-15 13:02:50 +0530: > While I agree that stack.yaml is a frozen config, we do not necessarily > need a separate config file or a separate format for that. My main point > was a that a new user will have to understand two more languages > (YAML/cabal) in addition to Haskell. We can have the config spread in > multiple files, but they should look like an extension of the same thing > rather than disparate things. For what it's worth, cabal.project files use the same parser/lexical structure as Cabal files; the fields/stanzas are just different. I'm not familiar with the reasons why Stack decided to use YAML for their configuration format. > The stack snapshot config can be seen as a higher level concept of the > pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the > snapshot is a point in that space. It can also be seen as a more general > version of the "tested-with" field in the cabal file. We can instead say - > tested-with these snapshots (or set of versions). Instead of using > stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list > which snapshot configs that are available and you can choose which one you > want to build. The config could be tool agnostic. Well, if the "snapshot" config is put in specific file, there's no reason why Cabal couldn't be taught to also read configuration from that file. But if cabal-install wants it to be in "pkg description format" and Stack wants it to be in YAML I'm not sure how you are going to get the projects to agree on a shared format. Snapshot config is put in cabal.project.freeze, which has the virtue of having the *same* format of cabal.project. Edward From harendra.kumar at gmail.com Thu Sep 15 23:19:05 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 04:49:05 +0530 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <1473949231-sup-150@sabre> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: On 15 September 2016 at 19:53, Edward Z. Yang wrote: > > Well, if the "snapshot" config is put in specific file, there's no > reason why Cabal couldn't be taught to also read configuration from that > file. But if cabal-install wants it to be in "pkg description format" > and Stack wants it to be in YAML I'm not sure how you are going to get > the projects to agree on a shared format. Snapshot config is put > in cabal.project.freeze, which has the virtue of having the *same* > format of cabal.project. How about cabal-install using the YAML format as hpack has proven that it works very well for expressing the existing .cabal files? YAML is simple, flexible and open, used across many tools so the knowledge of format is more widely sharable which has its advantages. Are there reasons to keep using the cabal format other than the legacy reasons and the pain of asking everyone to move to another format? In the short run it is tempting to keep using .cabal since we do not have to manage a painful disruptive change. But that may not be so in the long run. Open technologies usually win in the long run as against the closed ones. Keeping aside the legacy knowledge advantage, we can objectively evaluate if .cabal is better than YAML or vice versa. Inputs from original stack authors might also be useful on why they chose YAML over .cabal. I guess it might be similar to the reasons why someone wrote hpack to generate .cabal from YAML. Also they were starting fresh and so did not have to manage a disruptive change. But I fear if they will be willing to go for a closed format against an open format now even if some of the problems of the format are addressed. Maintaining a closed format perennially is also an issue unless it is very well thought out and does not require any changes. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Sep 15 23:24:52 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 15 Sep 2016 19:24:52 -0400 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: On Thu, Sep 15, 2016 at 7:19 PM, Harendra Kumar wrote: > How about cabal-install using the YAML format as hpack has proven that it > works very well for expressing the existing .cabal files? YAML is simple, > flexible and open, used across many tools so the knowledge of format is > more widely sharable which has its advantages. Are there reasons to keep > using the cabal format other than the legacy reasons and the pain of asking > everyone to move to another format? Could you explain what aspect of a format for which all code and documentation is open source defines it as "closed" to you? -- 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 harendra.kumar at gmail.com Thu Sep 15 23:31:37 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 05:01:37 +0530 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: On 16 September 2016 at 04:54, Brandon Allbery wrote: > On Thu, Sep 15, 2016 at 7:19 PM, Harendra Kumar > wrote: > >> How about cabal-install using the YAML format as hpack has proven that it >> works very well for expressing the existing .cabal files? YAML is simple, >> flexible and open, used across many tools so the knowledge of format is >> more widely sharable which has its advantages. Are there reasons to keep >> using the cabal format other than the legacy reasons and the pain of asking >> everyone to move to another format? > > > Could you explain what aspect of a format for which all code and > documentation is open source defines it as "closed" to you? > Well, I did not mean closed in that sense. What I meant was it is custom built for a very specific purpose, maybe I chose the wrong word, sorry about that. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Thu Sep 15 23:42:16 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Thu, 15 Sep 2016 16:42:16 -0700 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: On 9/15/16 4:19 PM, Harendra Kumar wrote: > How about cabal-install using the YAML format as hpack has proven that > it works very well for expressing the existing .cabal files? YAML is > simple, flexible and open, used across many tools so the knowledge of > format is more widely sharable which has its advantages. Are there > reasons to keep using the cabal format other than the legacy reasons > and the pain of asking everyone to move to another format? The legacy reasons are important. Haskell has a wonderfully rich software ecosystem, and I wouldn't want to see that ruined by fragmentation. At the very least, if hpack is going to be supported as an alternative to .cabal files, the support should be implemented in cabal-the-library, not in the front-ends like cabal-install or stack. As long as all the front-ends use cabal-the-library to parse project files, then cabal-the-library can add support for new types of project files (while still keeping support for .cabal files) without risk of fragmentation. --Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Thu Sep 15 23:55:17 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 16 Sep 2016 08:55:17 +0900 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> Message-ID: <1473982629-sup-5966@sabre> > How about cabal-install using the YAML format as hpack has proven that it > works very well for expressing the existing .cabal files? YAML is simple, > flexible and open, used across many tools so the knowledge of format is > more widely sharable which has its advantages. Are there reasons to keep > using the cabal format other than the legacy reasons and the pain of asking > everyone to move to another format? I understand YAML is a very popular format, but it is not all roses. It's an extremely complicated format (http://yaml.org/spec/1.2/spec.html). Cabal's lexical format is very simple, because it doesn't really need to support much (the rest is deferred to sub-parsers on fields.) In some since, YAML is overkill for Stack, which actually doesn't use very many of its features (https://docs.haskellstack.org/en/stable/yaml_configuration/) If I were designing a package ecosystem from scratch, I'm not sure what format I would pick. Take Rust Cargo; they didn't use YAML, they used TOML (https://github.com/toml-lang/toml) in no small part due to the fact that YAML is complicated. I'd want the output to be associated with locations so I could give error messages that refer to the input file; no one does that today... > Inputs from original stack authors might also be useful on why they chose > YAML over .cabal. I guess it might be similar to the reasons why someone > wrote hpack to generate .cabal from YAML. Also they were starting fresh and > so did not have to manage a disruptive change. But I fear if they will be > willing to go for a closed format against an open format now even if some > of the problems of the format are addressed. Maintaining a closed format > perennially is also an issue unless it is very well thought out and does > not require any changes. I suspect the reason is much more banal: Cabal's parser implementation is pretty byzantine and difficult to use. So rather than fight something like that, just use something will a nicer API. Edward From cma at bitemyapp.com Fri Sep 16 00:19:16 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 15 Sep 2016 19:19:16 -0500 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: <1473982629-sup-5966@sabre> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: The YAML parser backing hpack and Stack supports a subset of yaml, so the complexity isn't there. TOML isn't supported because a well-supported/known-good library wasn't to hand, whereas the yaml one did. I don't think people would mind changing over, but somebody has to do the work validating that the one-still-maintained-of-two-libraries TOML library is suitable. Keep in mind while discussing all this that Cabal's own solver doesn't actually live outside of cabal-install. Contributing to the Cabal project itself is a gauntlet run, which is partly why many of these projects spawned outside of it. Further, Cabal itself can't really grow any dependencies because of the bootstrap problem. Nobody wants to shim / inline all the dependencies that enable the devs to work efficiently into Cabal and such a PR would never get merged anyway. On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang wrote: >> How about cabal-install using the YAML format as hpack has proven that it >> works very well for expressing the existing .cabal files? YAML is simple, >> flexible and open, used across many tools so the knowledge of format is >> more widely sharable which has its advantages. Are there reasons to keep >> using the cabal format other than the legacy reasons and the pain of asking >> everyone to move to another format? > > I understand YAML is a very popular format, but it is not all roses. > It's an extremely complicated format (http://yaml.org/spec/1.2/spec.html). > Cabal's lexical format is very simple, because it doesn't really need to > support much (the rest is deferred to sub-parsers on fields.) In some > since, YAML is overkill for Stack, which actually doesn't use very many of > its features (https://docs.haskellstack.org/en/stable/yaml_configuration/) > > If I were designing a package ecosystem from scratch, I'm not sure what > format I would pick. Take Rust Cargo; they didn't use YAML, they used > TOML (https://github.com/toml-lang/toml) in no small part due to the > fact that YAML is complicated. I'd want the output to be associated > with locations so I could give error messages that refer to the input > file; no one does that today... > >> Inputs from original stack authors might also be useful on why they chose >> YAML over .cabal. I guess it might be similar to the reasons why someone >> wrote hpack to generate .cabal from YAML. Also they were starting fresh and >> so did not have to manage a disruptive change. But I fear if they will be >> willing to go for a closed format against an open format now even if some >> of the problems of the format are addressed. Maintaining a closed format >> perennially is also an issue unless it is very well thought out and does >> not require any changes. > > I suspect the reason is much more banal: Cabal's parser implementation > is pretty byzantine and difficult to use. So rather than fight something > like that, just use something will a nicer API. > > Edward > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Chris Allen Currently working on http://haskellbook.com From ezyang at mit.edu Fri Sep 16 02:23:56 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 16 Sep 2016 11:23:56 +0900 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: On September 16, 2016 9:19:16 AM GMT+09:00, Christopher Allen wrote: >The YAML parser backing hpack and Stack supports a subset of yaml, so >the complexity isn't there. Is the subset of yaml that Stack supports deacribed anywhere? The yaml package (which Stack depends on) seems to suggest it supports a pretty beefy chunk of YAML, e.g. including includes. >TOML isn't supported because a well-supported/known-good library >wasn't to hand, whereas the yaml one did. I don't think people would >mind changing over, but somebody has to do the work validating that >the one-still-maintained-of-two-libraries TOML library is suitable. I'm not suggesting you change over. My feeling is that once a choice like this is made, it is very hard to change post facto. Need to build infrastructure for migrating to new format if you do. >Keep in mind while discussing all this that Cabal's own solver doesn't >actually live outside of cabal-install. Here is the ticket tracking the issue: https://github.com/haskell/cabal/issues/3781 Basically, everyone agrees it should happen, but there is a bit of work that has to be done, esp. API design, and most of us have other issues we are frying. > Contributing to the Cabal >project itself is a gauntlet run, which is partly why many of these >projects spawned outside of it. I know that this was true in the past, and it is hard to regain trust and reputation. But I think things are better now. Our turnaround time for new PRs is now much quicker, and if you submit a PR we will give you commit bits. Obviously that doesn't make up for any past failings, but please give us another look! > Further, Cabal itself can't really >grow any dependencies because of the bootstrap problem. I don't think this is inherently unsolvable. Just work. It would be reasonable to remove Cabal from boot packages GHC distributes and require cabal-install/Stack to bootstrap a sufficiently new version of Cabal library. But you would have to do work to make sure that you dont end up building half the universe on a fresh GHC build. GHC devs would not like that. >Nobody wants to shim / inline all the dependencies that enable the >devs to work efficiently into Cabal and such a PR would never get >merged anyway. Out of curiosity, what are the libraries that are most painful to not have available from the boot libraries? Edward >On Thu, Sep 15, 2016 at 6:55 PM, Edward Z. Yang wrote: >>> How about cabal-install using the YAML format as hpack has proven >that it >>> works very well for expressing the existing .cabal files? YAML is >simple, >>> flexible and open, used across many tools so the knowledge of format >is >>> more widely sharable which has its advantages. Are there reasons to >keep >>> using the cabal format other than the legacy reasons and the pain of >asking >>> everyone to move to another format? >> >> I understand YAML is a very popular format, but it is not all roses. >> It's an extremely complicated format >(http://yaml.org/spec/1.2/spec.html). >> Cabal's lexical format is very simple, because it doesn't really need >to >> support much (the rest is deferred to sub-parsers on fields.) In >some >> since, YAML is overkill for Stack, which actually doesn't use very >many of >> its features >(https://docs.haskellstack.org/en/stable/yaml_configuration/) >> >> If I were designing a package ecosystem from scratch, I'm not sure >what >> format I would pick. Take Rust Cargo; they didn't use YAML, they >used >> TOML (https://github.com/toml-lang/toml) in no small part due to the >> fact that YAML is complicated. I'd want the output to be associated >> with locations so I could give error messages that refer to the input >> file; no one does that today... >> >>> Inputs from original stack authors might also be useful on why they >chose >>> YAML over .cabal. I guess it might be similar to the reasons why >someone >>> wrote hpack to generate .cabal from YAML. Also they were starting >fresh and >>> so did not have to manage a disruptive change. But I fear if they >will be >>> willing to go for a closed format against an open format now even if >some >>> of the problems of the format are addressed. Maintaining a closed >format >>> perennially is also an issue unless it is very well thought out and >does >>> not require any changes. >> >> I suspect the reason is much more banal: Cabal's parser >implementation >> is pretty byzantine and difficult to use. So rather than fight >something >> like that, just use something will a nicer API. >> >> Edward >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From spam at scientician.net Fri Sep 16 02:49:01 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 16 Sep 2016 04:49:01 +0200 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: On 2016-09-16 02:19, Christopher Allen wrote: > The YAML parser backing hpack and Stack supports a subset of yaml, so > the complexity isn't there. As I understand it, the point of using YAML in this case isn't that "there's a library for that". It's that it's *standard* such that other tools can read/write it and know for certain that what gets read/written is at the very least 'syntactically' correct. As such, using some nebulous "subset of yaml" defined by an implementation[1] doesn't really make sense for interop purposes. (I'm honestly not sure how many *actually* fully conforming YAML parsers there are out there, but I'd place my bets of "not many" given the complexity of the spec. See http://yaml.org/spec/1.2/spec.html ) > TOML isn't supported because a well-supported/known-good library > wasn't to hand, whereas the yaml one did. I don't think people would > mind changing over, but somebody has to do the work validating that > the one-still-maintained-of-two-libraries TOML library is suitable. Even though there are probably fewer implementations, TOML is aiming[2] to become a standard format, so it's (hopefully going to be) a standard and a much simpler one than YAML. That'll hopefully lead to more implementations over time, but who knows? It's *also* simple enough that implementing a fully conforming parser/writer is probably a few days' work, if that. That means that any tools that cannot use an existing library (for whatever reason) actually have a shot in hell of implementing TOML support themselves. That is not the case for YAML -- witnessed by the number of yaml libaries that are actually just bindings for C-based yaml libraries. (I have other issues with TOML, but that's a different matter. The major sticking point for me would be the lack of *clean* support for nesting without the order-dependence, but that may not matter much for Cabal.) > > Keep in mind while discussing all this that Cabal's own solver doesn't > actually live outside of cabal-install. FWIW, this seems mostly like a historical accident more than anything else and at this point it's a *very* non-trivial undertaking to fully separate it out, though there have been steps in this direction. I don't see it happening unless the parties who are actually interested in *using* it outside of cabal-install do the majority of the work. > Contributing to the Cabal project itself is a gauntlet run, which > is partly why many of these > projects spawned outside of it. Further, Cabal itself can't really > grow any dependencies because of the bootstrap problem. > > Nobody wants to shim / inline all the dependencies that enable the > devs to work efficiently into Cabal and such a PR would never get > merged anyway. You're right that Cabal-the-library is generally a very difficult thing to change (due to sheer inertia and stability guarantees), but -- as Patrick Pelletier points out -- implementing a new file format shouldn't matter for consumers of Cabal as long as Cabal emits the old standard Cabal configuration data structures. Meanwhile, it would open up the possibility of non-Cabal-based programs understanding and writing .cabal files (up to semantics defined by documentation). I'm not sure how much that benefit that would confer, but given that Cabal's parser is already a mess[3] with loads of corner cases I'd say it's probably worth it *just* from a software engineering perspective to get the basic syntax parsing disconnected from Cabal and to get rid of the old code. Btw, Cabal/cabal-install development has opened up and picked up pace considerably in the last year or two, you might want to reconsider automatically concluding that such-and-such PR "[...] would never get merged anyway". Anyway, this sub-thread is probably veering too off-topic, so I'll stop there. Regards, /b Notes: [1] At least, from a quick skim of the available documentation at https://hackage.haskell.org/package/yaml I wasn't able deduce what subset of YAML was supposed to be supported. Maybe I just missed it. [2] As of now the README for the current v0.4.0 spec says: "Be warned, this spec is still changing a lot. Until it's marked as 1.0, you should assume that it is unstable and act accordingly.". I guess one can pin to 0.4.0. [3] Work to at least replace it with a parsec-based implementation has been happening here, but the amount of work in https://github.com/haskell/cabal/pull/3602 seems indicative of a *lot* of complexity. (Granted it's hard to tell exactly how much of that complexity is due to mapping to Cabal's data structure vs. just the "parse into a KV-map" bits.) From harendra.kumar at gmail.com Fri Sep 16 06:20:15 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 11:50:15 +0530 Subject: [Haskell-cafe] Standard package file format Message-ID: I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From tdammers at gmail.com Fri Sep 16 06:37:34 2016 From: tdammers at gmail.com (Tobias Dammers) Date: Fri, 16 Sep 2016 08:37:34 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Another factor in favor of YAML is that it is a superset of JSON, which eases the learning curve even more (with JSON being a de facto lingua franca for cross-platform untyped data structures), and offers some extra possibilities, although I admit that I can't think of any practical uses. The fact that both Yaml and JSON can be represented as Aeson Values would also make things (arguably) easier for tool writers. On Sep 16, 2016 8:20 AM, "Harendra Kumar" wrote: > I am starting a new thread for the package file format related discussion. > > From a developer's perspective, the major benefit of a standard and widely > adopted format and is that people can utilize their knowledge acquired from > elsewhere, they do not have to go through and learn differently looking and > incomplete documentation of different tools. The benefit of a common config > specification is that developers can choose tools freely without worrying > about learning the same concepts presented in different ways. > > Multiple formats flying around also create a psychological impression of > complexity in the ecosystem for newcomers. If we have consistency there are > better chances of attracting more people to the language ecosystem. > > I gather the following from the discussion till now: > > * We have cabal, YAML and TOML as potential candidates for a common > package format which can additionally incorporate the concept of > snapshots/package collections and potentially more extensions useful across > build tools. > > * cabal has the benefit of incumbency and backward compatibility, it has > shortcomings which are being addressed but it is still a format which is > very specific to Haskell ecosystem. It is not a standard and not going to > become one. We have to always deal with it ourselves and everyone coming to > Haskell will have to learn it. > > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. > > * TOML (https://github.com/toml-lang/toml) is promising, simpler than > YAML and is being used by a few important projects but is still evolving > and is not completely stable. On a first glance it looks pretty simple and > a lot of other tools use a similar config format. It is aiming to become a > standard and aiming for a wider adoption. > > As a next step we can perhaps do an hpack like experiment using the TOML > format. That way we will have some experience with that as well and get to > know if there are any potential problems expressing the existing cabal > files. > > More thoughts, opinions on the topic will help create a better > understanding about it. > > -harendra > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 07:05:37 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 09:05:37 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Why not adopt (a subset of) .hs AST file format to structure both project and package files? This would simplify parsing config files as well as syncing code and config files in IDEs. To draw an analogy, JSON derives from JavaScript. Isn't this a precedent? ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Sep 16 07:13:31 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 09:13:31 +0200 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <1473900137.2517.141.camel@googlemail.com> <1473949231-sup-150@sabre> <1473982629-sup-5966@sabre> Message-ID: <73bf9ea1-e599-425a-8a4a-fa7663248f4c@durchholz.org> Am 16.09.2016 um 04:49 schrieb Bardur Arantsson: > On 2016-09-16 02:19, Christopher Allen wrote: >> The YAML parser backing hpack and Stack supports a subset of yaml, so >> the complexity isn't there. > > As I understand it, the point of using YAML in this case isn't that > "there's a library for that". It's that it's *standard* such that other > tools can read/write it and know for certain that what gets read/written > is at the very least 'syntactically' correct. That. The promise to the users of the language is: If you have YAML knowledge, you can reuse it anywhere, whether you're doing Haskell, Java, Cobol, or CMS. > As such, using some > nebulous "subset of yaml" defined by an implementation[1] doesn't really > make sense for interop purposes. Interop isn't that important, because those files are going to be consumed by a single program mostly. > (I'm honestly not sure how many *actually* fully conforming YAML parsers > there are out there, but I'd place my bets of "not many" given the > complexity of the spec. See http://yaml.org/spec/1.2/spec.html ) In the Java world, most parsers are at some 99.5% mark. I.e. there are certain (usually well-documented) corner cases that don't work, and these corner cases are so rare that nobody cares enough about them to submit a PR. Most corner cases have to do with multi-part YAMLs, and/or with start and end of the YAML part in a data stream. YAML offers possibilities to specify arbitrary data types for subobjects, and while that's flexible, it's also a security nightmare and inherently dependent on the backend language, so different libraries tend to handle this differently. Also, it's a bit clunky, so people prefer to stick with lists of predefined data types (the list can be reconfigured so that is something you have to relearn for each application, but it's essentially just a list that you can consult, so people should be happy with that). >> TOML isn't supported because a well-supported/known-good library >> wasn't to hand, whereas the yaml one did. I don't think people would >> mind changing over, but somebody has to do the work validating that >> the one-still-maintained-of-two-libraries TOML library is suitable. > > Even though there are probably fewer implementations, TOML is aiming[2] > to become a standard format, so it's (hopefully going to be) a standard > and a much simpler one than YAML. That'll hopefully lead to more > implementations over time, but who knows? I'm sceptical. TOML does not have much activity, some issues have been lying around since 2014 without a resolution, last activity was May 2016. TOML is too simplicistic to be a standard format. No references, so no shared or cyclic data structures, no standard for binary data (essentially "choose whatever app-specific encoding you want"), no mechanism for application-specific data types (not a real restriction but requires the app to apply conversion, plus no way to restrict the key names). It could be enough for Cabal, but it's not good enough to be universal, which condemns TOML to just a part of the ecosystem. From jo at durchholz.org Fri Sep 16 07:15:57 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 09:15:57 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Am 16.09.2016 um 08:20 schrieb Harendra Kumar: > * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML > and is being used by a few important projects but is still evolving and is > not completely stable. On a first glance it looks pretty simple and a lot > of other tools use a similar config format. It is aiming to become a > standard and aiming for a wider adoption. TOML is limited in its data types: numbers, dates, strings for primitives, arrays and string-to-object maps. I'd consider that too limited to ever become a universal configuration format. From harendra.kumar at gmail.com Fri Sep 16 07:18:29 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 12:48:29 +0530 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: On 16 September 2016 at 12:35, Imants Cekusins wrote: > Why not adopt (a subset of) .hs AST file format to structure both project > and package files? > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Fri Sep 16 07:22:44 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Fri, 16 Sep 2016 09:22:44 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it. So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file. Alan On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar wrote: > On 16 September 2016 at 12:35, Imants Cekusins wrote: > >> Why not adopt (a subset of) .hs AST file format to structure both project >> and package files? >> > > Aha, that's my preferred choice. If there is a way to restrict features > and we can allow just a subset we can have a nice configuration language > which is a real language. In fact, I have been toying around this. If we > have to express not just a package specification but a sophisticated build > configuration, we need a real language. Expressing conditionals, reuse etc > becomes a compromise in a purely declarative language. > > For example make has so many built-in functions in it that it has become a > full fledged language by itself. The google bazel build uses python as the > build config language. Haskell will make a much better choice for such use > cases. Pure declarative is a pain for such use cases. > > -harendra > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Fri Sep 16 07:30:44 2016 From: miguelimo38 at yandex.ru (MigMit) Date: Fri, 16 Sep 2016 09:30:44 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> Sbt seems to be doing rather well, using full Scala in configurations. I think package descriptions should be limited, but not syntactically. Using some specific monad might work OK. > On 16 Sep 2016, at 09:22, Alan & Kim Zimmerman wrote: > > The more power you put into the package file description, the harder it is for the surrounding ecosystem to reason about it. > > So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, it becomes difficult to be sure what is actually being specified, if you do not reproduce the original environment when evaluating the file. > > Alan > > On Fri, Sep 16, 2016 at 9:18 AM, Harendra Kumar wrote: > On 16 September 2016 at 12:35, Imants Cekusins wrote: > Why not adopt (a subset of) .hs AST file format to structure both project and package files? > > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. > > For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. > > -harendra > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From imantc at gmail.com Fri Sep 16 08:23:06 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 10:23:06 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> References: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> Message-ID: > So if you can execute arbitrary code in a new-gen cabal file, apart from the security aspects, ... ​ well config files could use different (not .hs) extensions. They could use their own Prelude and not allow importing other modules. The main benefit is to reuse existing parsers and simplify code-config sync. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Fri Sep 16 08:24:41 2016 From: cdsmith at gmail.com (Chris Smith) Date: Fri, 16 Sep 2016 01:24:41 -0700 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: I guess the overriding question I have here is: what is the PROBLEM being solved? I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format. It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc. But the syntax? It's just not an issue. I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment. With this in mind, a lot of the statements about these various languages are not entirely convincing. That it's a superset of JSON? It's not clear why this matters. A psychological impression of complexity? Just not anything I've seen evidence of. Indeed, aside from the rather painful many-years-long migration, the *cost* (though certainly not a prohibitive one) of moving to something like YAML or TOML is that they have a bit louder syntax, that demands more attention and feels more complex. There is one substantial disadvantage I'd point out to the Cabal file format as it stands, and that's that it's pretty non-obvious how to parse it, so we will always struggle to interact with it from automated tools, unless those tools are also written in Haskell and can use the Cabal library. That's a real concern; pragmatic large-scale build environments are not tied to specific languages, and include a variety of ad-hoc third-party tooling that needs to be integrated, and Cabal remains opaque to them. But that doesn't seem to be what's motivating this conversation. On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar wrote: > I am starting a new thread for the package file format related discussion. > > From a developer's perspective, the major benefit of a standard and widely > adopted format and is that people can utilize their knowledge acquired from > elsewhere, they do not have to go through and learn differently looking and > incomplete documentation of different tools. The benefit of a common config > specification is that developers can choose tools freely without worrying > about learning the same concepts presented in different ways. > > Multiple formats flying around also create a psychological impression of > complexity in the ecosystem for newcomers. If we have consistency there are > better chances of attracting more people to the language ecosystem. > > I gather the following from the discussion till now: > > * We have cabal, YAML and TOML as potential candidates for a common > package format which can additionally incorporate the concept of > snapshots/package collections and potentially more extensions useful across > build tools. > > * cabal has the benefit of incumbency and backward compatibility, it has > shortcomings which are being addressed but it is still a format which is > very specific to Haskell ecosystem. It is not a standard and not going to > become one. We have to always deal with it ourselves and everyone coming to > Haskell will have to learn it. > > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. > > * TOML (https://github.com/toml-lang/toml) is promising, simpler than > YAML and is being used by a few important projects but is still evolving > and is not completely stable. On a first glance it looks pretty simple and > a lot of other tools use a similar config format. It is aiming to become a > standard and aiming for a wider adoption. > > As a next step we can perhaps do an hpack like experiment using the TOML > format. That way we will have some experience with that as well and get to > know if there are any potential problems expressing the existing cabal > files. > > More thoughts, opinions on the topic will help create a better > understanding about it. > > -harendra > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Sep 16 08:36:48 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 10:36:48 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <3e865437-53e6-b1e8-d488-f44dcc79c2c8@durchholz.org> Am 16.09.2016 um 09:22 schrieb Alan & Kim Zimmerman: > The more power you put into the package file description, the harder it is > for the surrounding ecosystem to reason about it. > > So if you can execute arbitrary code in a new-gen cabal file, apart from > the security aspects, it becomes difficult to be sure what is actually > being specified, if you do not reproduce the original environment when > evaluating the file. A little-hyped aspect of Gradle is that it has two strictly divided phases: Phase 1 builds the dependency model, phase 2 executes it. Once phase 1 finishes, the dependency model becomes read-only, phase 2 is not allowed to modify it. On the plus side, this makes it easy for tools to reason about the model: it's static and easy to reproduce (just run phase 1 on the config file, or even better, ask the Gradle daemon that's caching the model). On the minus side, it's hard to make out which code in the config is phase-1 and which is phase-2: Same syntax, no static types to guide the intuition; essentially, you have to know which parameters of what phase-1 library functions are closures to be executed in phase 2. Haskell might be able to do better in this area, though I'm in no position to make any proposals for that. From imantc at gmail.com Fri Sep 16 08:37:23 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 10:37:23 +0200 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: Message-ID: > what is the PROBLEM being solved? by making config files follow .hs syntax, cabal file structure may be defined as a data record. This would make it clear, which fields are compulsory, which are optional. Enums may be used. -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Sep 16 08:45:47 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 14:15:47 +0530 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: Message-ID: The discussion originated in an earlier thread from a question about the possibility of using the same format across different tools, cabal and stack which currently use different file formats. If they have to use the same format what that format should be. On 16 September 2016 at 13:54, Chris Smith wrote: > I guess the overriding question I have here is: what is the PROBLEM being > solved? I know of basically no beginners who were confused or intimidated > by the syntax of Cabal's file format. It's fairly commonplace for > beginners to be confused by the *semantics*: which fields are needed and > what they mean, how package version bounds work, what flags are and how > they interact with dependencies, the relationship between libraries and > executables defined in the same file, etc. But the syntax? It's just not > an issue. I'm not sure what it means to say that people have to "learn" > it, because in introducing dozens of people to building things in Haskell, > I've never seen that learning process even be noticeable, much less an > impediment. > > With this in mind, a lot of the statements about these various languages > are not entirely convincing. That it's a superset of JSON? It's not clear > why this matters. A psychological impression of complexity? Just not > anything I've seen evidence of. Indeed, aside from the rather painful > many-years-long migration, the *cost* (though certainly not a prohibitive > one) of moving to something like YAML or TOML is that they have a bit > louder syntax, that demands more attention and feels more complex. > > There is one substantial disadvantage I'd point out to the Cabal file > format as it stands, and that's that it's pretty non-obvious how to parse > it, so we will always struggle to interact with it from automated tools, > unless those tools are also written in Haskell and can use the Cabal > library. That's a real concern; pragmatic large-scale build environments > are not tied to specific languages, and include a variety of ad-hoc > third-party tooling that needs to be integrated, and Cabal remains opaque > to them. But that doesn't seem to be what's motivating this conversation. > > On Thu, Sep 15, 2016 at 11:20 PM, Harendra Kumar > wrote: > >> I am starting a new thread for the package file format related discussion. >> >> From a developer's perspective, the major benefit of a standard and >> widely adopted format and is that people can utilize their knowledge >> acquired from elsewhere, they do not have to go through and learn >> differently looking and incomplete documentation of different tools. The >> benefit of a common config specification is that developers can choose >> tools freely without worrying about learning the same concepts presented in >> different ways. >> >> Multiple formats flying around also create a psychological impression of >> complexity in the ecosystem for newcomers. If we have consistency there are >> better chances of attracting more people to the language ecosystem. >> >> I gather the following from the discussion till now: >> >> * We have cabal, YAML and TOML as potential candidates for a common >> package format which can additionally incorporate the concept of >> snapshots/package collections and potentially more extensions useful across >> build tools. >> >> * cabal has the benefit of incumbency and backward compatibility, it has >> shortcomings which are being addressed but it is still a format which is >> very specific to Haskell ecosystem. It is not a standard and not going to >> become one. We have to always deal with it ourselves and everyone coming to >> Haskell will have to learn it. >> >> * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A >> significant chunk of developer community is already familiar with it. It is >> being used by stack and by hpack as an alternative to cabal format. The >> complaint against it is that the specification/implementation is overly >> complex. >> >> * TOML (https://github.com/toml-lang/toml) is promising, simpler than >> YAML and is being used by a few important projects but is still evolving >> and is not completely stable. On a first glance it looks pretty simple and >> a lot of other tools use a similar config format. It is aiming to become a >> standard and aiming for a wider adoption. >> >> As a next step we can perhaps do an hpack like experiment using the TOML >> format. That way we will have some experience with that as well and get to >> know if there are any potential problems expressing the existing cabal >> files. >> >> More thoughts, opinions on the topic will help create a better >> understanding about it. >> >> -harendra >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Sep 16 08:46:08 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 10:46:08 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Am 16.09.2016 um 10:24 schrieb Chris Smith: > With this in mind, a lot of the statements about these various languages > are not entirely convincing. That it's a superset of JSON? It's not clear > why this matters. It does matter for people who already know JSON: They can skip over the config file syntax and dive right into the semantics. Given that a substantial fraction of programmers knows JSON, using that syntax would create a lower entry barrier. The same argument can be made for YAML. This argument cannot be made for TOML at this time, maybe never if TOML's limitations prevent widespread adoption. > A psychological impression of complexity? Just not > anything I've seen evidence of. Indeed, aside from the rather painful > many-years-long migration, the *cost* (though certainly not a prohibitive > one) of moving to something like YAML or TOML is that they have a bit > louder syntax, that demands more attention and feels more complex. YAML's complexity is partly because it tries to cover everything, partly because it is pushing hard to be both human-readable and machine-readable. It's pretty good at this actually, though I guess 20/20 hindsight could lead to improvements - but not enough to make a new YAML version worth the effort. > There is one substantial disadvantage I'd point out to the Cabal file > format as it stands, and that's that it's pretty non-obvious how to parse > it, so we will always struggle to interact with it from automated tools, > unless those tools are also written in Haskell and can use the Cabal > library. That's a real concern; pragmatic large-scale build environments > are not tied to specific languages, and include a variety of ad-hoc > third-party tooling that needs to be integrated, and Cabal remains opaque > to them. But that doesn't seem to be what's motivating this conversation. That's implicit in the "it would be nice to have a standard format" argument, even if it hasn't been explicitly voiced yet. From yann.esposito at gmail.com Fri Sep 16 08:57:29 2016 From: yann.esposito at gmail.com (yogsototh) Date: Fri, 16 Sep 2016 01:57:29 -0700 (PDT) Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: > I guess the overriding question I have here is: what is the PROBLEM being > solved? > Let me share my experience with Clojure and lein. They use a clojure hash-map for their configuration. So yes arbitrary code could be executed and I believe this is a _very good thing_. Why? Because it makes it very easy to add sub-configuration that can be used by third party plugin. For example: - a plugin that help the use of environment variables (lein-environ) which is really helpful for application development (not so much for library development) - a plugin that use S3 for our private dependencies (not supported by default by lein) For deployment: we were able to add request to our API server that provide not only the written version but also the git commit hash. So we could be certain of the version of the server. Too much time there were sys/admin deployment errors. And that could only be achieved because we were able to run arbitrary command in the project description file. I certainly forget many other advantages of having a package description format which is simply a data structure in the hosted language. But this has by far my preference. - cabal is ok, but very imperfect, I generally need to have a lot of copy/paste, I need to change it very often while writing application with many dependencies - JSON/YAML/TOML are simply not powerful enough to match all semantics we might need to configure a project. For example we might want to have Set instead of List for some properties. Or I don't know maybe ternary tree structures. The point is: we pay a price by adding a step between the semantic and the syntax. While if our configuration format was in Haskell we could express the semantic more directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 09:15:57 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 11:15:57 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: .. for interop with other packagers / builders, .hs compatible config content could be transformed / exported to other formats. .hs -> YAML, JSON, ... is likely to be possible and easier than the other way around. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Fri Sep 16 09:36:38 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 11:36:38 +0200 Subject: [Haskell-cafe] [Haskell-community] Standard package file format Message-ID: (Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From imantc at gmail.com Fri Sep 16 09:49:56 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 11:49:56 +0200 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: Message-ID: this may be one of the 3 points on Paolo's list. In case it is not, here is another option (4?): - define .hs data records for project config, package configs - write export tools to export config records to existing formats: cabal stack yaml ... ​ this way, there is no need to revise the current workflow or modify tools. However we define a common standard content structure, most users do not need to worry about .cabal, .yaml syntax -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Fri Sep 16 10:38:18 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 12:38:18 +0200 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 12:13, Patrick Pelletier wrote: > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> (Resending from right address) >> >> We're talking about *three* options: >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> jSON). That's just an alternative to YAML/TOML/... That would need >> extensions to allow omitting optional fields entirely. >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> generates cabal description records (GenericPackageDescription >> values). That would allow abstraction over some patterns but not much >> more. But that alone is already an argument for EDSLs—the one Harendra >> already presented. >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> many others. That would potentially be a rabbit hole leading to a >> rather *different* tool—with a different package format to boot. That >> can't work as long as all libraries have to be built using the same >> tool. But stack and cabal are really about how to manage package >> databases/GHC/external environments, while extensible build tools are >> about (a more powerful form) of writing custom setup scripts. I >> suspect some extensions might be easier if more of the actual building >> was done by the setup script, but I'm not sure. > > > Options 2 and 3 both require running Haskell code at build time. > But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/), so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From harendra.kumar at gmail.com Fri Sep 16 11:05:44 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 16:35:44 +0530 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: This seems to have gone into a different direction. The original point was about the package specification format and not expressing a full fledged build system. That is an entirely different ballgame. The main point of the thread was whether it makes sense to use a single specification format for both stack and cabal install (YAML vs .cabal and then TOML came into picture). Haskell does not seem to be a choice for a package specification format unless we have a very different goal in mind. -harendra On 16 September 2016 at 16:08, Paolo Giarrusso wrote: > On 16 September 2016 at 12:13, Patrick Pelletier > wrote: > > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: > >> > >> (Resending from right address) > >> > >> We're talking about *three* options: > >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell > >> jSON). That's just an alternative to YAML/TOML/... That would need > >> extensions to allow omitting optional fields entirely. > >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply > >> generates cabal description records (GenericPackageDescription > >> values). That would allow abstraction over some patterns but not much > >> more. But that alone is already an argument for EDSLs—the one Harendra > >> already presented. > >> 3. a Haskell embedded domain-specific language (EDSL) designed for an > >> extensible build tool, like Clojure's (apparently), SBT for Scala or > >> many others. That would potentially be a rabbit hole leading to a > >> rather *different* tool—with a different package format to boot. That > >> can't work as long as all libraries have to be built using the same > >> tool. But stack and cabal are really about how to manage package > >> databases/GHC/external environments, while extensible build tools are > >> about (a more powerful form) of writing custom setup scripts. I > >> suspect some extensions might be easier if more of the actual building > >> was done by the setup script, but I'm not sure. > > > > > > Options 2 and 3 both require running Haskell code at build time. > > > But if all packages had to use the new EDSL, then cross-compilation > would essentially become impossible. > > "All packages migrate to new format" doesn't seem really a plausible > option, as I already hinted in the text you quote. > There are multiple JVM build tools because they're interoperable (like > cabal-install and Stack): each library picks its own build tool, but > they can still be linked together. > Hpack generates cabal files, stack reuses cabal or hpack files. > > In principle, option 2 just needs a non-cross-compiled program to > produce a package description—say by producing a cabal file. You just > need to runghc it, either via ghci or by compiling and running a > binary. Option 3 can be trickier depending on details, but the as long > as you account for cross-compilation in the design it should be > doable. For Template Haskell the problem is deeper (see > http://blog.ezyang.com/2016/07/what-template-haskell-gets- > wrong-and-racket-gets-right/), > so let's *not* use it here. > -- > Paolo G. Giarrusso - Ph.D. Student, Tübingen University > http://ps.informatik.uni-tuebingen.de/team/giarrusso/ > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Fri Sep 16 11:21:40 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 13:21:40 +0200 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 13:05, Harendra Kumar wrote: > This seems to have gone into a different direction. The original point was > about the package specification format and not expressing a full fledged > build system. That is an entirely different ballgame. The main point of the > thread was whether it makes sense to use a single specification format for > both stack and cabal install (YAML vs .cabal and then TOML came into > picture). Haskell does not seem to be a choice for a package specification > format unless we have a very different goal in mind. I agree "full-fledged build system" is not a possible immediate goal. But an EDSL for expressing cabal projects (as they are today) would still be in scope of your proposal—and I thought you liked the idea (see quote below). Using the earlier options: option 3 is not in scope of this thread, but option 2 is, with the only danger that the design space is so big to present a challenge. Quoting from Harendra Kumar's earlier mail: >> Why not adopt (a subset of) .hs AST file format to structure both project and package files? > Aha, that's my preferred choice. If there is a way to restrict features and we can allow just a subset we can have a nice configuration language which is a real language. In fact, I have been toying around this. If we have to express not just a package specification but a sophisticated build configuration, we need a real language. Expressing conditionals, reuse etc becomes a compromise in a purely declarative language. > For example make has so many built-in functions in it that it has become a full fledged language by itself. The google bazel build uses python as the build config language. Haskell will make a much better choice for such use cases. Pure declarative is a pain for such use cases. > On 16 September 2016 at 16:08, Paolo Giarrusso > wrote: >> >> On 16 September 2016 at 12:13, Patrick Pelletier >> wrote: >> > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> We're talking about *three* options: >> >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> >> jSON). That's just an alternative to YAML/TOML/... That would need >> >> extensions to allow omitting optional fields entirely. >> >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> >> generates cabal description records (GenericPackageDescription >> >> values). That would allow abstraction over some patterns but not much >> >> more. But that alone is already an argument for EDSLs—the one Harendra >> >> already presented. >> >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> >> many others. That would potentially be a rabbit hole leading to a >> >> rather *different* tool—with a different package format to boot. That >> >> can't work as long as all libraries have to be built using the same >> >> tool. But stack and cabal are really about how to manage package >> >> databases/GHC/external environments, while extensible build tools are >> >> about (a more powerful form) of writing custom setup scripts. I >> >> suspect some extensions might be easier if more of the actual building >> >> was done by the setup script, but I'm not sure. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From harendra.kumar at gmail.com Fri Sep 16 11:46:12 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Fri, 16 Sep 2016 17:16:12 +0530 Subject: [Haskell-cafe] [Haskell-community] Standard package file format In-Reply-To: References: <0dce0a5c-c987-d133-2d1f-781c02c3907d@funwithsoftware.org> Message-ID: On 16 September 2016 at 16:51, Paolo Giarrusso wrote: > > I agree "full-fledged build system" is not a possible immediate goal. > But an EDSL for expressing cabal projects (as they are today) would > still be in scope of your proposal—and I thought you liked the idea > (see quote below). Using the earlier options: option 3 is not in scope > of this thread, but option 2 is, with the only danger that the design > space is so big to present a challenge. > Yeah I like the idea of using Haskell for configs but perhaps in a different problem space e.g. in a build spec. See the quote from my earlier quote below, sorry for the confusion :-) Yes, maybe option 2 might work for package specifications but sounds pretty hairy to explore for this use case alone, unless we have other motivations. > Quoting from Harendra Kumar's earlier mail: > > If we have to express not just a package specification but a > sophisticated build configuration, we need a real language. Expressing > conditionals, reuse etc becomes a compromise in a purely declarative > language. > -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Fri Sep 16 12:39:15 2016 From: toad3k at gmail.com (David McBride) Date: Fri, 16 Sep 2016 08:39:15 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: While I would personally love having a package description in haskell, I don't think it is a good idea. If you can't start or modify a package without already knowing haskell, it is a huge barrier to entry. I remember trying to get started in scala and having a lot of trouble with sbt because I didn't know their operators for lists and arrays or hash tables or whatever it is that they use in their files. On Fri, Sep 16, 2016 at 4:57 AM, yogsototh wrote: > > I guess the overriding question I have here is: what is the PROBLEM being >> solved? >> > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be > used by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this > has by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at kahn.pro Fri Sep 16 13:25:38 2016 From: chris at kahn.pro (Chris Kahn) Date: Fri, 16 Sep 2016 06:25:38 -0700 Subject: [Haskell-cafe] Standard package file format Message-ID: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> I would like to second this thought. Using Haskell for package descriptions needs to be thought out and executed with great care and attention. It's really easy to go off the rails. Scala's build system lets you do very powerful things, but it also makes things unnecessarily complicated and mystifying for beginners. At my previous work where we used Scala extensively, there were many times where the team simply resorted to external tools because figuring out how to make some seemingly trivial change to an SBT module was too time consuming. On September 16, 2016 8:39:15 AM EDT, David McBride wrote: > While I would personally love having a package description in haskell, > I don't think it is a good idea. > > If you can't start or modify a package without already knowing > haskell, it is a huge barrier to entry. I remember trying to get > started in scala and having a lot of trouble with sbt because I didn't > know their operators for lists and arrays or hash tables or whatever > it is that they use in their files. > > On Fri, Sep 16, 2016 at 4:57 AM, yogsototh > wrote: >> >>> I guess the overriding question I have here is: what is the PROBLEM >>> being solved? >> >> Let me share my experience with Clojure and lein. They use a clojure >> hash-map for their configuration. So yes arbitrary code could be >> executed and I believe this is a _very good thing_. >> >> Why? Because it makes it very easy to add sub-configuration that can >> be used by third party plugin. For example: >> >> - a plugin that help the use of environment variables (lein-environ) >> which is really helpful for application development (not so much >> for library development) >> - a plugin that use S3 for our private dependencies (not supported by >> default by lein) >> >> >> For deployment: we were able to add request to our API server that >> provide not only the written version but also the git commit hash. So >> we could be certain of the version of the server. Too much time there >> were sys/admin deployment errors. And that could only be achieved >> because we were able to run arbitrary command in the project >> description file. >> >> I certainly forget many other advantages of having a package >> description format which is simply a data structure in the hosted >> language. But this has by far my preference. >> >> - cabal is ok, but very imperfect, I generally need to have a lot of >> copy/paste, I need to change it very often while writing >> application with many dependencies >> - JSON/YAML/TOML are simply not powerful enough to match all >> semantics we might need to configure a project. For example we >> might want to have Set instead of List for some properties. Or I >> don't know maybe ternary tree structures. >> >> The point is: we pay a price by adding a step between the semantic >> and the syntax. >> While if our configuration format was in Haskell we could express the >> semantic more directly. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skosyrev at ptsecurity.com Fri Sep 16 13:37:05 2016 From: skosyrev at ptsecurity.com (Kosyrev Serge) Date: Fri, 16 Sep 2016 16:37:05 +0300 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <87zin89da6.fsf@ptsecurity.com> David McBride writes: > While I would personally love having a package description in haskell, > I don't think it is a good idea. I think we all can agree, that using the fully-fledged language for configuration is an extremely bad idea from many perspectives. The worst of all, IMO, is that it makes reasoning about the configuration equivalent to the halting problem. And god, does it hurt in practice! -- speaking as someone who had spent a non-trivial amount of time on doing exactly this stuff in another age and for another language. However. This does not mean that we cannot find a subset of the language that would be a point of balance between the needs of expressivity, learnability and decidability. After all JSON was born in roughly this spirit, wasn't it? The wins are obvious to me: - the syntax is immediately obvious to the target audience - minimum effort to get existent Haskell tools to work with the "new" format at the source level -- syntax highlighting, checking, etc. The only required additions would be restriction enforcement - no third-party libraries need to be used as dependencies for our core tooling > If you can't start or modify a package without already knowing > haskell, it is a huge barrier to entry. I'm unconvinced that this problem cannot be resolved within the subsetting approach. > I remember trying to get > started in scala and having a lot of trouble with sbt because I didn't > know their operators for lists and arrays or hash tables or whatever > it is that they use in their files. That is because they committed to the sin of employing the whole of Scala for the thing. Bad for them. But also.. let's not commit the mistake of conflating the surface syntax and the semantics. The semantics are dictated by need -- whose sharpening effect on the learning curve is unavoidable. I'm willing to argue that a large part of your confusion came from the /semantics/ of sbt, not the syntax. The syntax differences, OTOH, can and ought to be trivialized. -- с уважениeм / respectfully, Косырев Сергей From imantc at gmail.com Fri Sep 16 13:38:01 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 15:38:01 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> Message-ID: my experience with Gradle was frustrating too. Even with some experience with Java. a lot of what is often called "complexity" stems from lack of types and gaps in comments / documentation. language needs to be learnt anyway. If config syntax needs to be learnt in addition to language syntax, this is always extra work. for 1st timers to be able to write hello world, sample config files and a few tutorials would go a long way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From skosyrev at ptsecurity.com Fri Sep 16 13:42:18 2016 From: skosyrev at ptsecurity.com (Kosyrev Serge) Date: Fri, 16 Sep 2016 16:42:18 +0300 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> Message-ID: <87y42s9d1h.fsf@ptsecurity.com> Chris Kahn writes: > I would like to second this thought. Using Haskell for package > descriptions needs to be thought out and executed with great care and > attention. It's really easy to go off the rails. > > Scala's build system lets you do very powerful things, but it also > makes things unnecessarily complicated and mystifying for beginners. > At my previous work where we used Scala extensively, there were many > times where the team simply resorted to external tools because > figuring out how to make some seemingly trivial change to an SBT > module was too time consuming. Let me guess (have no idea about sbt) -- unbridled Turing completeness? Declarativity is king for configuration, and Turing completeness ain't it -- please, see my other mail about subsetting Haskell. -- с уважениeм / respectfully, Косырев Сергей From Andrew.Butterfield at scss.tcd.ie Fri Sep 16 08:59:48 2016 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Fri, 16 Sep 2016 09:59:48 +0100 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <33096B3E-54BA-4DD9-B03E-C8817333413D@scss.tcd.ie> > On 16 Sep 2016, at 09:24, Chris Smith wrote: > > I guess the overriding question I have here is: what is the PROBLEM being solved? I know of basically no beginners who were confused or intimidated by the syntax of Cabal's file format. As a "beginner"(*), I fully agree. However having more than one language in the mix can be confusing and complicating... > It's fairly commonplace for beginners to be confused by the *semantics*: which fields are needed and what they mean, how package version bounds work, what flags are and how they interact with dependencies, the relationship between libraries and executables defined in the same file, etc. It's all about the semantics - it should preferably be formalised, and ideally the relevant library/package system should be able to check/enforce rules. > But the syntax? It's just not an issue. I'm not sure what it means to say that people have to "learn" it, because in introducing dozens of people to building things in Haskell, I've never seen that learning process even be noticeable, much less an impediment. I quite agree > Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland (*) I've only started to use cabal recently, because a TA of mine built a cabal-based coursework grading system for me - I generally do application devpt in Haskell and the only build command I need is ghc --make.... Currently moving quickly onto stack this year.... From jo at durchholz.org Fri Sep 16 13:51:48 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 15:51:48 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <87zin89da6.fsf@ptsecurity.com> References: <87zin89da6.fsf@ptsecurity.com> Message-ID: Am 16.09.2016 um 15:37 schrieb Kosyrev Serge: > The worst of all, IMO, is that it makes reasoning about the > configuration equivalent to the halting problem. That's a solved problem: Generate an execution plan, which would need to be fully evaluated in Haskell; then execute it and don't feed anything back into it. It's easy to reason about the plan in that scenario. This is what Gradle does. > And god, does it hurt in practice! -- speaking as someone who had spent > a non-trivial amount of time on doing exactly this stuff in another age > and for another language. Which language? > This does not mean that we cannot find a subset of the language that > would be a point of balance between the needs of expressivity, > learnability and decidability. Subsettings makes it hard to know what works and what doesn't. A Haskell subset would have to be strict - which begs the question what's the point in calling this a subset of Haskell (and even if there is a point, it will draw ridicule along the lines of "Haskell is unsuitable for describing its own configurations"). > After all JSON was born in roughly this spirit, wasn't it? JSON was/is a serialization format, first and foremost. >> If you can't start or modify a package without already knowing >> haskell, it is a huge barrier to entry. > > I'm unconvinced that this problem cannot be resolved within the subsetting approach. Actually subsetting is making this worse: Things freshly learned for Haskell won't work in the config language, restrictions encountered in the config language will be unthinkingly transferred to Haskell. Having two subtly but fundamentally different languages is about the worst thing you can expose a learner to. From imantc at gmail.com Fri Sep 16 13:52:42 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 15:52:42 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <87y42s9d1h.fsf@ptsecurity.com> References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> <87y42s9d1h.fsf@ptsecurity.com> Message-ID: .. if this helps the discussion, here is cabal file "spec" (see also other files in the same directory) these types are used to parse .cabal. one benefit from using these types in reverse (to generate .cabal from .hs) would be: it is possible to write a few libs which generate well-formed cabal files from a simplified API. It is possible this was done already. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Sep 16 14:00:13 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 16 Sep 2016 16:00:13 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> Message-ID: <51ec26f6-802b-fe5c-ac84-f0668f0cd321@durchholz.org> Am 16.09.2016 um 15:38 schrieb Imants Cekusins: > a lot of what is often called "complexity" stems from lack of types and > gaps in comments / documentation. That's a big issue with Gradle. The third problem I know Gradle for is that it makes it surprisingly difficult to inspect the execution plan. From heraldhoi at gmail.com Fri Sep 16 14:03:17 2016 From: heraldhoi at gmail.com (Geraldus) Date: Fri, 16 Sep 2016 14:03:17 +0000 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <51ec26f6-802b-fe5c-ac84-f0668f0cd321@durchholz.org> References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> <51ec26f6-802b-fe5c-ac84-f0668f0cd321@durchholz.org> Message-ID: > Actually subsetting is making this worse: Things freshly learned for > Haskell won't work in the config language, restrictions encountered in > the config language will be unthinkingly transferred to Haskell. I agree. This is exactly what I felt when I tried to use Fay language, which is a «proper subset» of Haskell (in the end I switched to GHCJS). пт, 16 сент. 2016 г. в 19:00, Joachim Durchholz : > Am 16.09.2016 um 15:38 schrieb Imants Cekusins: > > a lot of what is often called "complexity" stems from lack of types and > > gaps in comments / documentation. > > That's a big issue with Gradle. > > The third problem I know Gradle for is that it makes it surprisingly > difficult to inspect the execution plan. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From manny at fpcomplete.com Fri Sep 16 14:05:19 2016 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Fri, 16 Sep 2016 14:05:19 +0000 Subject: [Haskell-cafe] ANN: stack-1.2.0 Message-ID: See https://haskellstack.org for installation and upgrade instructions. Release notes: * On many Un*x systems, Stack can now be installed with a simple one-liner: wget -qO- https://get.haskellstack.org/ | sh * The fix for [#2175](https://github.com/commercialhaskell/stack/issues/2175) entails that stack must perform a full clone of a large Git repo of Hackage meta-information. The total download size is about 200 MB. Please be aware of this when upgrading your stack installation. * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as there are reports of GHC panics when building some packages (including Stack itself). See [#2577]( https://github.com/commercialhaskell/stack/issues/2577) * This version of Stack does not build on ARM or PowerPC systems (see [store#37](https://github.com/fpco/store/issues/37)). Please stay with version 1.1.2 for now on those architectures. This will be rectified soon! * We are now releasing a [statically linked Stack binary for 64-bit Linux]( https://www.stackage.org/stack/linux-x86_64-static). Please try it and let us know if you run into any trouble on your platform. * We are planning some changes to our Linux releases, including dropping our Ubuntu, Debian, CentOS, and Fedora package repositories and switching to statically linked binaries. We would value your feedback in [#2534](https://github.com/commercialhaskell/stack/issues/2534). Major changes: * Add `stack hoogle` command. [#55](https://github.com/commercialhaskell/stack/issues/55) * Support for absolute file path in `url` field of `setup-info` or `--ghc-bindist` * Add support for rendering GHCi scripts targeting different GHCi like applications [#2457](https://github.com/commercialhaskell/stack/pull/2457) Behavior changes: * Remove `stack ide start` and `stack ide load-targets` commands. [#2178](https://github.com/commercialhaskell/stack/issues/2178) * Support .buildinfo files in `stack ghci`. [#2242](https://github.com/commercialhaskell/stack/pull/2242) * Support -ferror-spans syntax in GHC error messages. * Avoid unpacking ghc to `/tmp` [#996](https://github.com/commercialhaskell/stack/issues/996) * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC variant and can no longer be specified using the `ghc-variant` option, and instead is treated more like a slightly different platform. Other enhancements: * Use the `store` package for binary serialization of most caches. * Only require minor version match for Docker stack exe. This way, we can make patch releases for version bounds and similar build issues without needing to upload new binaries for Docker. * Stack/Nix: Passes the right ghc derivation as an argument to the `shell.nix` when a custom `shell.nix` is used See [#2243](https://github.com/commercialhaskell/stack/issues/2243) * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template Haskell can work (See _e.g._ [this HaskellR issue]( https://github.com/tweag/HaskellR/issues/253)) * Parse CLI arguments and configuration files into less permissive types, improving error messages for bad inputs. [#2267](https://github.com/commercialhaskell/stack/issues/2267) * Add the ability to explictly specify a gcc executable. [#593](https://github.com/commercialhaskell/stack/issues/593) * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a derivation like `haskell.compiler.ghc801` See [#2259](https://github.com/commercialhaskell/stack/issues/2259) * Perform some subprocesses during setup concurrently, slightly speeding up most commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) * `stack setup` no longer unpacks to the system temp dir on posix systems. [#996](https://github.com/commercialhaskell/stack/issues/996) * `stack setup` detects libtinfo6 and ncurses6 and can download alternate GHC bindists [#257](https://github.com/commercialhaskell/stack/issues/257) [#2302](https://github.com/commercialhaskell/stack/issues/2302). * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist [#2103](https://github.com/commercialhaskell/stack/issues/2103) * Custom `stack` binaries list dependency versions in output for `--version`. See [#2222](https://github.com/commercialhaskell/stack/issues/2222) and [#2450](https://github.com/commercialhaskell/stack/issues/2450). * Use a pretty printer to output dependency resolution errors. [#1912](https://github.com/commercialhaskell/stack/issues/1912) * Remove the `--os` flag [#2227](https://github.com/commercialhaskell/stack/issues/2227) * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. [#2293](https://github.com/commercialhaskell/stack/issues/2293). * Add `stack ide targets` command. * Enhance debug logging with subprocess timings. * Pretty-print YAML parse errors [#2374](https://github.com/commercialhaskell/stack/issues/2374) * Clarify confusing `stack setup` output [#2314](https://github.com/commercialhaskell/stack/issues/2314) * Delete `Stack.Types` multimodule to improve build times [#2405](https://github.com/commercialhaskell/stack/issues/2405) * Remove spurious newlines in build logs [#2418](https://github.com/commercialhaskell/stack/issues/2418) * Interpreter: Provide a way to hide implicit packages [#1208](https://github.com/commercialhaskell/stack/issues/1208) * Check executability in exec lookup [#2489](https://github.com/commercialhaskell/stack/issues/2489) Bug fixes: * Fix cabal warning about use of a deprecated cabal flag [#2350](https://github.com/commercialhaskell/stack/issues/2350) * Support most executable extensions on Windows [#2225](https://github.com/commercialhaskell/stack/issues/2225) * Detect resolver change in `stack solver` [#2252](https://github.com/commercialhaskell/stack/issues/2252) * Fix a bug in docker image creation where the wrong base image was selected [#2376](https://github.com/commercialhaskell/stack/issues/2376) * Ignore special entries when unpacking tarballs [#2361](https://github.com/commercialhaskell/stack/issues/2361) * Fixes src directory pollution of `style.css` and `highlight.js` with GHC 8's haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) * Handle filepaths with spaces in `stack ghci` [#2266](https://github.com/commercialhaskell/stack/issues/2266) * Apply ghc-options to snapshot packages [#2289](https://github.com/commercialhaskell/stack/issues/2289) * stack sdist: Fix timestamp in tarball [#2394](https://github.com/commercialhaskell/stack/pull/2394) * Allow global Stack arguments with a script [#2316](https://github.com/commercialhaskell/stack/issues/2316) * Inconsistency between ToJSON and FromJSON instances of PackageLocation [#2412](https://github.com/commercialhaskell/stack/pull/2412) * Perform Unicode normalization on filepaths [#1810](https://github.com/commercialhaskell/stack/issues/1810) * Solver: always keep ghc wired-in as hard constraints [#2453](https://github.com/commercialhaskell/stack/issues/2453) * Support OpenBSD's tar where possible, require GNU tar for xz support [#2283](https://github.com/commercialhaskell/stack/issues/2283) * Fix using --coverage with Cabal-1.24 [#2424](https://github.com/commercialhaskell/stack/issues/2424) * When marking exe installed, remove old version [#2373](https://github.com/commercialhaskell/stack/issues/2373) * Stop truncating all-cabal-hashes git repo [#2175](https://github.com/commercialhaskell/stack/issues/2175) * Handle non-ASCII filenames on Windows [#2491](https://github.com/commercialhaskell/stack/issues/2491) * Avoid using multiple versions of a package in script interpreter by passing package-id to ghc/runghc [#1957](https://github.com/commercialhaskell/stack/issues/1957) * Only pre-load compiler version when using nix integration [#2459](https://github.com/commercialhaskell/stack/issues/2459) * Solver: parse cabal errors also on Windows [#2502](https://github.com/commercialhaskell/stack/issues/2502) * Allow exec and ghci commands in interpreter mode. Scripts can now automatically open in the repl by using `exec ghci` instead of `runghc` in the shebang command. [#2510](https://github.com/commercialhaskell/stack/issues/2510) * Now consider a package to be dirty when an extra-source-file is changed. See [#2040](https://github.com/commercialhaskell/stack/issues/2040) Thanks to all our contributors for this release: * Aaron Friel * Andrew Cowie * AndrewRademacher * Anton Felix Lorenzen * Brian McKenna * Chris Done * Dan Aloni * danald * Daniel Casanueva * Denis * Denis Kasak * Emanuel Borsboom * erewok * Gabor Greif * Gurkenglas * Harendra Kumar * hesiod * Judah Jacobson * Khan Thompson * Mathieu Boespflug * Michael Sloan * Michael Snoyman * Mohit Agarwal * Moritz Angermann * Oleg Grenrus * Paolo G. Giarrusso * Philipp Kant * Ryan Desfosses * Sid Kapur * Sidharth Kapur * Simon Jakobi * Tim Dysinger * Tim Düsterhus * Tobias Markus * YPares * Yuriy Syrovetskiy * Yves Parès (Ywen) * ___ -------------- next part -------------- An HTML attachment was scrubbed... URL: From manny at fpcomplete.com Fri Sep 16 14:09:37 2016 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Fri, 16 Sep 2016 14:09:37 +0000 Subject: [Haskell-cafe] ANN: stack-1.2.0 In-Reply-To: References: Message-ID: As a followup, a bug that may cause problems in build environments like Travis CI has been discovered: if you have a version of `git` < 1.8.2 (released in early 2013), `stack build` will fail with an error like 'fatal: error in object: unshallow 05a8ba81a30b775e3aab8269642317345708bcfa' when it tries to update the package index on first startup. See https://github.com/commercialhaskell/stack/issues/2602 for more details. On Fri, Sep 16, 2016 at 7:05 AM Emanuel Borsboom wrote: > See https://haskellstack.org for installation and upgrade instructions. > > Release notes: > > * On many Un*x systems, Stack can now be installed with a simple > one-liner: > > wget -qO- https://get.haskellstack.org/ | sh > > * The fix for > [#2175](https://github.com/commercialhaskell/stack/issues/2175) > entails that stack must perform a full clone of a large Git repo of > Hackage meta-information. The total download size is about 200 MB. > Please be aware of this when upgrading your stack installation. > > * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as > there > are reports of GHC panics when building some packages (including Stack > itself). See [#2577]( > https://github.com/commercialhaskell/stack/issues/2577) > > * This version of Stack does not build on ARM or PowerPC systems (see > [store#37](https://github.com/fpco/store/issues/37)). Please stay with > version 1.1.2 for now on those architectures. This will be rectified > soon! > > * We are now releasing a > [statically linked Stack binary for 64-bit Linux]( > https://www.stackage.org/stack/linux-x86_64-static). > Please try it and let us know if you run into any trouble on your > platform. > > * We are planning some changes to our Linux releases, including dropping > our > Ubuntu, Debian, CentOS, and Fedora package repositories and switching to > statically linked binaries. We would value your feedback in > [#2534](https://github.com/commercialhaskell/stack/issues/2534). > > Major changes: > > * Add `stack hoogle` command. > [#55](https://github.com/commercialhaskell/stack/issues/55) > * Support for absolute file path in `url` field of `setup-info` or > `--ghc-bindist` > * Add support for rendering GHCi scripts targeting different GHCi like > applications > [#2457](https://github.com/commercialhaskell/stack/pull/2457) > > Behavior changes: > > * Remove `stack ide start` and `stack ide load-targets` commands. > [#2178](https://github.com/commercialhaskell/stack/issues/2178) > * Support .buildinfo files in `stack ghci`. > [#2242](https://github.com/commercialhaskell/stack/pull/2242) > * Support -ferror-spans syntax in GHC error messages. > * Avoid unpacking ghc to `/tmp` > [#996](https://github.com/commercialhaskell/stack/issues/996) > * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC > variant and can no longer be specified using the `ghc-variant` option, > and instead is treated more like a slightly different platform. > > Other enhancements: > > * Use the `store` package for binary serialization of most caches. > * Only require minor version match for Docker stack exe. > This way, we can make patch releases for version bounds and similar > build issues without needing to upload new binaries for Docker. > * Stack/Nix: Passes the right ghc derivation as an argument to the > `shell.nix` when a > custom `shell.nix` is used > See [#2243](https://github.com/commercialhaskell/stack/issues/2243) > * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template > Haskell can work > (See _e.g._ [this HaskellR issue]( > https://github.com/tweag/HaskellR/issues/253)) > * Parse CLI arguments and configuration files into less permissive types, > improving error messages for bad inputs. > [#2267](https://github.com/commercialhaskell/stack/issues/2267) > * Add the ability to explictly specify a gcc executable. > [#593](https://github.com/commercialhaskell/stack/issues/593) > * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a > derivation > like `haskell.compiler.ghc801` > See [#2259](https://github.com/commercialhaskell/stack/issues/2259) > * Perform some subprocesses during setup concurrently, slightly speeding > up most > commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) > * `stack setup` no longer unpacks to the system temp dir on posix systems. > [#996](https://github.com/commercialhaskell/stack/issues/996) > * `stack setup` detects libtinfo6 and ncurses6 and can download alternate > GHC > bindists [#257](https://github.com/commercialhaskell/stack/issues/257) > [#2302](https://github.com/commercialhaskell/stack/issues/2302). > * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist > [#2103](https://github.com/commercialhaskell/stack/issues/2103) > * Custom `stack` binaries list dependency versions in output for > `--version`. > See [#2222](https://github.com/commercialhaskell/stack/issues/2222) > and [#2450](https://github.com/commercialhaskell/stack/issues/2450). > * Use a pretty printer to output dependency resolution errors. > [#1912](https://github.com/commercialhaskell/stack/issues/1912) > * Remove the `--os` flag > [#2227](https://github.com/commercialhaskell/stack/issues/2227) > * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. > [#2293](https://github.com/commercialhaskell/stack/issues/2293). > * Add `stack ide targets` command. > * Enhance debug logging with subprocess timings. > * Pretty-print YAML parse errors > [#2374](https://github.com/commercialhaskell/stack/issues/2374) > * Clarify confusing `stack setup` output > [#2314](https://github.com/commercialhaskell/stack/issues/2314) > * Delete `Stack.Types` multimodule to improve build times > [#2405](https://github.com/commercialhaskell/stack/issues/2405) > * Remove spurious newlines in build logs > [#2418](https://github.com/commercialhaskell/stack/issues/2418) > * Interpreter: Provide a way to hide implicit packages > [#1208](https://github.com/commercialhaskell/stack/issues/1208) > * Check executability in exec lookup > [#2489](https://github.com/commercialhaskell/stack/issues/2489) > > Bug fixes: > > * Fix cabal warning about use of a deprecated cabal flag > [#2350](https://github.com/commercialhaskell/stack/issues/2350) > * Support most executable extensions on Windows > [#2225](https://github.com/commercialhaskell/stack/issues/2225) > * Detect resolver change in `stack solver` > [#2252](https://github.com/commercialhaskell/stack/issues/2252) > * Fix a bug in docker image creation where the wrong base image was > selected > [#2376](https://github.com/commercialhaskell/stack/issues/2376) > * Ignore special entries when unpacking tarballs > [#2361](https://github.com/commercialhaskell/stack/issues/2361) > * Fixes src directory pollution of `style.css` and `highlight.js` with GHC > 8's > haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) > * Handle filepaths with spaces in `stack ghci` > [#2266](https://github.com/commercialhaskell/stack/issues/2266) > * Apply ghc-options to snapshot packages > [#2289](https://github.com/commercialhaskell/stack/issues/2289) > * stack sdist: Fix timestamp in tarball > [#2394](https://github.com/commercialhaskell/stack/pull/2394) > * Allow global Stack arguments with a script > [#2316](https://github.com/commercialhaskell/stack/issues/2316) > * Inconsistency between ToJSON and FromJSON instances of PackageLocation > [#2412](https://github.com/commercialhaskell/stack/pull/2412) > * Perform Unicode normalization on filepaths > [#1810](https://github.com/commercialhaskell/stack/issues/1810) > * Solver: always keep ghc wired-in as hard constraints > [#2453](https://github.com/commercialhaskell/stack/issues/2453) > * Support OpenBSD's tar where possible, require GNU tar for xz support > [#2283](https://github.com/commercialhaskell/stack/issues/2283) > * Fix using --coverage with Cabal-1.24 > [#2424](https://github.com/commercialhaskell/stack/issues/2424) > * When marking exe installed, remove old version > [#2373](https://github.com/commercialhaskell/stack/issues/2373) > * Stop truncating all-cabal-hashes git repo > [#2175](https://github.com/commercialhaskell/stack/issues/2175) > * Handle non-ASCII filenames on Windows > [#2491](https://github.com/commercialhaskell/stack/issues/2491) > * Avoid using multiple versions of a package in script interpreter > by passing package-id to ghc/runghc > [#1957](https://github.com/commercialhaskell/stack/issues/1957) > * Only pre-load compiler version when using nix integration > [#2459](https://github.com/commercialhaskell/stack/issues/2459) > * Solver: parse cabal errors also on Windows > [#2502](https://github.com/commercialhaskell/stack/issues/2502) > * Allow exec and ghci commands in interpreter mode. > Scripts can now automatically open in the repl by using `exec ghci` > instead of `runghc` in the shebang command. > [#2510](https://github.com/commercialhaskell/stack/issues/2510) > * Now consider a package to be dirty when an extra-source-file is changed. > See [#2040](https://github.com/commercialhaskell/stack/issues/2040) > > Thanks to all our contributors for this release: > > * Aaron Friel > * Andrew Cowie > * AndrewRademacher > * Anton Felix Lorenzen > * Brian McKenna > * Chris Done > * Dan Aloni > * danald > * Daniel Casanueva > * Denis > * Denis Kasak > * Emanuel Borsboom > * erewok > * Gabor Greif > * Gurkenglas > * Harendra Kumar > * hesiod > * Judah Jacobson > * Khan Thompson > * Mathieu Boespflug > * Michael Sloan > * Michael Snoyman > * Mohit Agarwal > * Moritz Angermann > * Oleg Grenrus > * Paolo G. Giarrusso > * Philipp Kant > * Ryan Desfosses > * Sid Kapur > * Sidharth Kapur > * Simon Jakobi > * Tim Dysinger > * Tim Düsterhus > * Tobias Markus > * YPares > * Yuriy Syrovetskiy > * Yves Parès (Ywen) > * ___ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Fri Sep 16 14:10:46 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 16 Sep 2016 10:10:46 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: On 2016-09-16 09:51 AM, Joachim Durchholz wrote: > >> This does not mean that we cannot find a subset of the language that >> would be a point of balance between the needs of expressivity, >> learnability and decidability. > > Subsettings makes it hard to know what works and what doesn't. > A Haskell subset would have to be strict - which begs the question > what's the point in calling this a subset of Haskell (and even if there > is a point, it will draw ridicule along the lines of "Haskell is > unsuitable for describing its own configurations"). Haskell is indeed unsuitable for describing the package configuration, IMO, but not because it's lazy. It's because it lacks any syntax for long and human-readable string literals (package description, anyone?). That also condemns every subset of Haskell. >> After all JSON was born in roughly this spirit, wasn't it? Yes, and JSON (and JavaScript) would suck for the very same reason. This deficiency of JSON was a major incentive for creating YAML. I'm mildly in favour of supporting another package format in addition to .cabal, as long as compatibility is kept, and as long as the new format is actually superior. I think any subset of Haskell would be a setback from usability perspective. One major benefit of YAML that I haven't seen mentioned is that it could be used to replace the README.md file at the same time. Right now a package description consists of both .cabal and (optionally) Markdown. I suspect the latter language is actually harder for complete beginners. From heraldhoi at gmail.com Fri Sep 16 14:13:27 2016 From: heraldhoi at gmail.com (Geraldus) Date: Fri, 16 Sep 2016 14:13:27 +0000 Subject: [Haskell-cafe] Issue with building executables using Cabal on Travis Message-ID: Hi Café! Recently we added an executable section to our Transient-Universe package and now Travis cabal builds always failing. The error message is: In-place registering transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) Linking dist/build/monitorService/monitorService ... No errors or warnings could be found in the package. Re-configuring with test suites enabled. If this fails, please run configure manually. Resolving dependencies... Configuring transient-universe-0.3.4... Package has no buildable test suites. Building source dist for transient-universe-0.3.4... Preprocessing library transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist Installing library in /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX Installing executable(s) in /home/travis/.cabal/bin Warning: The directory /home/travis/.cabal/bin is not in the system search path. cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. (Full log — https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you can see that other Cabal builds fail with same error, however all Stack builds are fine). This is a chunk of cabal file: extra-source-files: src/client/Transient/Move/Services/MonitorService.hs src/server/Transient/Move/Services/MonitorService.hs executable monitorService build-depends: base >4 && <5 if !impl(ghcjs >=0.1) hs-source-dirs: src/server/Transient/Monitor/Services build-depends: transformers , transient >=0.4.4 , transient-universe else hs-source-dirs: src/client/Transient/Monitor/Services main-is: MonitorService.hs default-language: Haskell2010 ghc-options: -threaded -rtsopts Have anyone faced similar issue? -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 14:29:04 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 16:29:04 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: > it lacks any syntax for long and human-readable string literals (package description, anyone?). ​ can {- comments -} be used for package description? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Fri Sep 16 14:38:32 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 16 Sep 2016 10:38:32 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> On 2016-09-16 10:29 AM, Imants Cekusins wrote: >> it lacks any syntax for long and human-readable string literals (package description, anyone?). > ​ > can {- comments -} be used for package description? > I suppose they could, but that would rather defeat the purpose of using a Haskell subset in the first place. Haskell ignores comments, package descriptions should not be ignored. From olf at aatal-apotheke.de Fri Sep 16 14:43:58 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 16 Sep 2016 16:43:58 +0200 (CEST) Subject: [Haskell-cafe] implement SOAP-based standard Message-ID: <1929673648.534350.4ce9504f-c583-409b-9935-4ed9cb0048ce.open-xchange@webmail.strato.de> Dear Haskellers, I am considering implementing the OPC XML DA standard [1] in Haskell. OPC XML DA is based on SOAP and is used for communicating with servers controlling hardware such as power plants. Currently the only open implementation known to me is PyOPC [2], which is based on an outdated Python libraries. However, Python seems not the nicest language for writing code that is devoid of bugs showing at runtime only. The OPC XML DA standard comes with a WSDL document (600 lines). There is a wsdl package on hackage, but it is incomplete. Can anyone share experience in implementing a webservice specified as WSDL? Actually, the client side would be enough for my purposes. That is, compose well-formed messages and parse the responses. Thanks, Olaf [1] https://opcfoundation.org/developer-tools/specifications-classic/xml-data-access/ [2] https://libraries.io/pypi/PyOPC From imantc at gmail.com Fri Sep 16 14:48:17 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 16:48:17 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> References: <87zin89da6.fsf@ptsecurity.com> <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> Message-ID: ok how about a pragma:7.13.6.3. Annotating modules You can annotate modules with the ANN pragma by using the module keyword. For example: {-# ANN module (Just "A `Maybe String' annotation") #-} ​ if the topic is *Standard package file format*, why not agree on e.g. adopting *GenericPackageDescription* or another similar haskell type (rather than a text-based file) as the standard? then any format (cabal, yaml, json, ...) may be used as long as a library exists and is maintained for each such format, which parses / produces the format from / to the standard type? how about this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Fri Sep 16 15:21:23 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 16 Sep 2016 11:21:23 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> Message-ID: On 2016-09-16 10:48 AM, Imants Cekusins wrote: > ok how about a pragma: > > 7.13.6.3. Annotating modules > > You can annotate modules with the |ANN| pragma by using > the |module| keyword. For example: > > {-# ANN module (Just "A `Maybe String' annotation") #-} I suppose this could do, but there are some downsides: - somewhat cumbersome syntax, - reliance on a GHC extension, and worst of all, - not a Haskell value. The last point implies that the package.hs with this kind of module annotation could not produce a proper GenericPackageDescription when executed as a Haskell program. > if the topic is _Standard package file format_, why not agree on e.g. > adopting *GenericPackageDescription* or another similar haskell type > (rather than a text-based file) as the standard? > > then any format (cabal, yaml, json, ...) may be used as long as a > library exists and is maintained for each such format, which parses / > produces the format from / to the standard type? This makes perfect sense to me. The devil may be in the details. Would cabal-install need to link in all these maintained libraries statically? Or would there be some plug-in mechanism to load them on demand? From imantc at gmail.com Fri Sep 16 15:35:53 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 17:35:53 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> Message-ID: > Would cabal-install need to link in all these maintained libraries statically? Or would there be some plug-in mechanism to load them on demand? well the libraries would need to be official and some with the packager.​ the formats would be perfectly interchangeable i.e. cabal -> standard_type -> yaml -> standard_type -> json -> standard_type -> cabal would produce the same cabal file only 1 config file per package to avoid confusion however if the user prefers working with format F, they can always convert the format which came with the package, to F the file can always be validated by virtue of parsing and reproducing the original file without errors. it comes at a price of duplicated efforts however it would give every choice one can wish for. If one must use yaml, they use yaml etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 15:36:52 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 17:36:52 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> <6d677bb8-886e-ad01-0574-6f62d44eb8cd@stilo.com> Message-ID: ... the libraries would need to be official and *come* with the packager.​ ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Fri Sep 16 17:07:53 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 16 Sep 2016 19:07:53 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> References: <1282767C-807F-49AA-9868-461FC3CAFF84@yandex.ru> Message-ID: On 2016-09-16 09:30, MigMit wrote: > Sbt seems to be doing rather well, using full Scala in configurations. > Sbt is a *build* description, *NOT* a package description format. Sbt uses ivy.xml files for the latter. (With interop for consuming Maven pom.xml files such that it can leverage the already-huge Maven repositories.) From spam at scientician.net Fri Sep 16 17:14:52 2016 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 16 Sep 2016 19:14:52 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: On 2016-09-16 16:10, Mario Blažević wrote: >>> After all JSON was born in roughly this spirit, wasn't it? > > Yes, and JSON (and JavaScript) would suck for the very same reason. > This deficiency of JSON was a major incentive for creating YAML. > > I'm mildly in favour of supporting another package format in > addition to .cabal, as long as compatibility is kept, and as long as the > new format is actually superior. I think any subset of Haskell would be > a setback from usability perspective. > This may be somewhat heretical, but I don't actually think we need to have a human-editable format. (Of course it should probably be *reasonably* human-readable/editable just for debugging and such.) Just provide simple commands to view/manipulate whatever package settings there are. Helpfully said commands could also sanity check whatever you're trying to do and perhaps provide better error messages than a tool which only has the "final" package description to work with. For beginners a simple GUI could be provided and IDEs could do their own thing. Problem solves. From imantc at gmail.com Fri Sep 16 17:58:07 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 19:58:07 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: > I don't actually think we need to have a human-editable format. .. store settings as serialized Haskell type, and use custom (non-official) viewers / editors to display them formatted to user preferences? ​ sounds good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Sep 16 18:49:36 2016 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 16 Sep 2016 20:49:36 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: 2016-09-16 19:14 GMT+02:00 Bardur Arantsson : > This may be somewhat heretical, but I don't actually think we need to > have a human-editable format. [...] Coming back to the central question (see Chris' mail): What problem do we solve by doing that? Replacing a relatively easy to read format by something unreadable by humans? That's probably the opposite of what we want... > [...] For beginners a simple GUI could be provided and IDEs could do their > own > thing. > If somebody thinks a GUI is a good idea, we don't need to change something at all: Just write a GUI for reading/editing .cabal files. > Problem solves. > Which problem? :-) Unless we really define what we want to improve and why, the whole discussion is pointless. Is it readability by humans? Being "standard" (whatever that means)? Being easily parsable, probably by a separate library? Being more flexible by what one can express? Having more abstraction facilities in the description? I have the impression that different people in this discussion try to solve different problems. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Sep 16 20:02:58 2016 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 16 Sep 2016 22:02:58 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: > what we want to improve and why how about these: 1. Adopt common standard for different package tools. 2. Give users and packager devs a choice of config file formats / representations. 3. Explore ways to simplify manual package configuration. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Sep 16 20:59:18 2016 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 16 Sep 2016 22:59:18 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87zin89da6.fsf@ptsecurity.com> Message-ID: 2016-09-16 22:02 GMT+02:00 Imants Cekusins : > [...] > > 1. Adopt common standard for different package tools. > > What are these tools? AFAICT we are talking about cabal and stack only, and from the recent discussion it seems that stack has slightly different goals: One stack.yaml can reference vaious cabal package descriptions, something I've never use until now, because I wasn''t even aware that it is possible. :-). So apart from the different surface syntax, there seems to be more fundamental differences. > > 1. Give users and packager devs a choice of config file formats / > representations. > > Why is this even a goal? On the contrary, I see this as an anti-goal, because it leads to useless creativity and fragmentation. > > 1. Explore ways to simplify manual package configuration. > > This is a worthwhile goal IMHO, but we need to be more concrete, e.g. how can repetitive stuff like the tons of almost-copy-n-paste in https://github.com/haskell-opengl/GLUT/blob/master/GLUT.cabal be avoided? This has nothing to do with syntax, more with abstraction facilities and semantics: If we just switch to JSON or YAML, GLUT.cabal would as repetitive as before, only in a different surface syntax. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu.ionita at acons.at Fri Sep 16 22:10:52 2016 From: nicu.ionita at acons.at (Nicu Ionita) Date: Fri, 16 Sep 2016 22:10:52 +0000 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 Message-ID: Is anybody else experiencing really slow compilations with GHC 7.10.2 on Windows 10? I use stack to compile the project and run it under a mingw64 environment provided by Github bash. The CPU usage is very low all the time (meaning: GHC does barely use the CPU). On same computer with Ubuntu 16.04 it just compiles normally, but under Windows it is for sure 10x slower, maybe even more. Nicu -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Sep 16 22:13:58 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 17 Sep 2016 00:13:58 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: (Harendra Kumar's message of "Fri, 16 Sep 2016 11:50:15 +0530") References: Message-ID: <8737kza3x5.fsf@gnu.org> (resent from different account, sorry if dupe) On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote: [...] > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. I'm not sure if this has been pointed out already, but beyond turning a proper grammar into a stringly-typed one, shoehorning some features of .cabal files into YAML syntax really appear like a case of the "Genius Tailor"[1], e.g. consider the `hpack` example when: - condition: flag(fast) then: ghc-options: -O2 else: ghc-options: -O0 besides looking quite awkward IMHO (just as an exercise, try inserting a nested if/then/else in that example above), the prospect that a standard format like YAML would allow to reuse standard tooling/libraries for YAML seems quite weak to me; if, for instance, you run the above through a YAML pretty-printer, you easily end up with something like when: - else: ghc-options: -O0 then: ghc-options: -O2 condition: flag(fast) or any other ordering depending on how the keys are sorted/hashed. Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if by accident you place a 2nd `else:` branch somewhere, you end up with an ambiguous .yaml file which may either result in an error, in the first key getting dropped (most likely variant), or in the 2nd key getting dropped. Which one you get depends on the YAML parser implementation. I really don't understand the appeal of applying the golden hammer of YAML, if `.cabal`'s grammar is already self-evident and concise with its syntax: if flag(fast) ghc-options: -O2 else ghc-options: -O0 where this if/then/else construct is encoded in the grammar proper rather than being merely a semantic interpretation after decoding a general grammar designed for simpler typed data-representations which isn't even accurate enough (since it has additional symmetries/freedoms) to capture the desired grammar faithfully, which make YAML quite error-prone for this specific application. [1]: The "Genius Tailor" was mentioned recently in a related discussion here: https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html -- hvr From p.giarrusso at gmail.com Fri Sep 16 22:48:35 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 15:48:35 -0700 (PDT) Subject: [Haskell-cafe] Issue with building executables using Cabal on Travis In-Reply-To: References: Message-ID: <5fdfce10-d288-467c-9b3c-1f1d189b5324@googlegroups.com> On Friday, September 16, 2016 at 4:13:44 PM UTC+2, Артур Файзрахманов wrote: > > Hi Café! > > Recently we added an executable section to our Transient-Universe package > and now Travis cabal builds always failing. The error message is: > > In-place registering transient-universe-0.3.4... > Preprocessing executable 'monitorService' for transient-universe-0.3.4... > [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) > Linking dist/build/monitorService/monitorService ... > No errors or warnings could be found in the package. > Re-configuring with test suites enabled. If this fails, please run configure > manually. > Resolving dependencies... > Configuring transient-universe-0.3.4... > Package has no buildable test suites. > Building source dist for transient-universe-0.3.4... > Preprocessing library transient-universe-0.3.4... > Preprocessing executable 'monitorService' for transient-universe-0.3.4... > cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist > Installing library in > /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX > Installing executable(s) in /home/travis/.cabal/bin > Warning: The directory /home/travis/.cabal/bin is not in the system search > path. > cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. > > (Full log — > https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you > can see that other Cabal builds fail with same error, however all Stack > builds are fine). > Not sure if you figured (you already reverted the change in https://github.com/agocorona/transient-universe/pull/16), but the key error is cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist and the error message is correct. The tricky bit is that this only fails when you run cabal sdist, not in the normal workflow—I remember being hit by this at some point. IIUC you're using the Travis config stack suggests (which in turn comes HVR's config)—maybe that needs more docs to help troubleshooting? That's full of subtleties that you don't learn by copy-pasting it. Cheers, Paolo > This is a chunk of cabal file: > > extra-source-files: src/client/Transient/Move/Services/MonitorService.hs > src/server/Transient/Move/Services/MonitorService.hs > > executable monitorService > build-depends: base >4 && <5 > if !impl(ghcjs >=0.1) > hs-source-dirs: src/server/Transient/Monitor/Services > build-depends: transformers > , transient >=0.4.4 > , transient-universe > else > hs-source-dirs: src/client/Transient/Monitor/Services > main-is: MonitorService.hs > default-language: Haskell2010 > ghc-options: -threaded -rtsopts > > > Have anyone faced similar issue? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Fri Sep 16 23:53:20 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 17 Sep 2016 05:23:20 +0530 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <8737kza3x5.fsf@gnu.org> References: <8737kza3x5.fsf@gnu.org> Message-ID: On 17 September 2016 at 03:43, Herbert Valerio Riedel wrote: > > I'm not sure if this has been pointed out already, but beyond turning a > proper grammar into a stringly-typed one, shoehorning some features of > .cabal files into YAML syntax really appear like a case of the "Genius > Tailor"[1], e.g. consider the `hpack` example > > when: > - condition: flag(fast) > then: > ghc-options: -O2 > else: > ghc-options: -O0 > > I agree. Supporting conditionals with YAML looks hacky! -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Sat Sep 17 00:27:14 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Fri, 16 Sep 2016 17:27:14 -0700 (PDT) Subject: [Haskell-cafe] Standard package file format In-Reply-To: <87y42s9d1h.fsf@ptsecurity.com> References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> <87y42s9d1h.fsf@ptsecurity.com> Message-ID: On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote: > > Chris Kahn writes: > > I would like to second this thought. Using Haskell for package > > descriptions needs to be thought out and executed with great care and > > attention. It's really easy to go off the rails. > > > > Scala's build system lets you do very powerful things, but it also > > makes things unnecessarily complicated and mystifying for beginners. > > At my previous work where we used Scala extensively, there were many > > times where the team simply resorted to external tools because > > figuring out how to make some seemingly trivial change to an SBT > > module was too time consuming. > > Let me guess (have no idea about sbt) -- unbridled Turing completeness? > > Declarativity is king for configuration, and Turing completeness ain't it > -- > please, see my other mail about subsetting Haskell. > That's not the main problem with SBT. How do I explain it? Take this as an example of what Haskell should *not* do. # SBT made difficult Look, we all know a monad is just a monoid in the category of endofunctors, right?. Now, a SBT build configuration is just a heterogeneously-typed map from keys to monadic values that can be evaluated to a graph of setting transformers and build actions, so what's the problem? And oh, I forgot to mention keys aren't simple strings but have a hierarchy themselves, and this hierarchy is used for inheritance and overriding of settings (nothing as simple as OO inheritance, mind you, think of something like CSS but different). Isn't using Haskell supposed to require a PhD? So why would its build tools use something so simple as nested records, like Cabal does? I think I'm trolling, but the above is somewhat accurate (except for any misunderstanding of SBT I might have)—I personally enjoy using SBT and its power, and once you learn it can be reasonably easy, but I think Kmett's lens library might be simpler to learn. In fairness, many SBT builds can be read without having any clue of the above, because they look like imperative programs. But as soon as you need to do a bit more or you make a type error, you end up facing some of the above complexity—if you want, the "imperative program" abstraction is extremely leaky. For instance, here's something "easy" (but count the amount of custom symbolic operators): scalaVersion := "2.11.0" scalacOptions += "-deprecation" libraryDependencies += org.scalatest" %% "scalatest" % "2.0" Then you want to use one setting when defining another, and suddenly you end up with: libraryDependencies <+= scalaVersion (ver => "org.scala-lang" % "scala-compiler" % ver) Luckily, this can be done more easily nowadays, thanks to Scala macros O_O. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Fri Sep 16 21:57:58 2016 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Fri, 16 Sep 2016 23:57:58 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: (Harendra Kumar's message of "Fri, 16 Sep 2016 11:50:15 +0530") References: Message-ID: <87intva4nt.fsf@gnu.org> On 2016-09-16 at 08:20:15 +0200, Harendra Kumar wrote: [...] > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It is > being used by stack and by hpack as an alternative to cabal format. The > complaint against it is that the specification/implementation is overly > complex. I'm not sure if this has been pointed out already, but beyond turning a proper grammar into a stringly-typed one, shoehorning some features of .cabal files into YAML syntax really appear like a case of the "Genius Tailor"[1], e.g. consider the `hpack` example when: - condition: flag(fast) then: ghc-options: -O2 else: ghc-options: -O0 besides looking quite awkward IMHO (just as an exercise, try inserting a nested if/then/else in that example above), the prospect that a standard format like YAML would allow to reuse standard tooling/libraries for YAML seems quite weak to me; if, for instance, you run the above through a YAML pretty-printer, you easily end up with something like when: - else: ghc-options: -O0 then: ghc-options: -O2 condition: flag(fast) or any other ordering depending on how the keys are sorted/hashed. Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if by accident you place a 2nd `else:` branch somewhere, you end up with an ambiguous .yaml file which may either result in an error, in the first key getting dropped (most likely variant), or in the 2nd key getting dropped. Which one you get depends on the YAML parser implementation. I really don't understand the appeal of applying the golden hammer of YAML, if `.cabal`'s grammar is already self-evident and concise with its syntax: if flag(fast) ghc-options: -O2 else ghc-options: -O0 where this if/then/else construct is encoded in the grammar proper rather than being merely a semantic interpretation after decoding a general grammar designed for simpler typed data-representations which isn't even accurate enough (since it has additional symmetries/freedoms) to capture the desired grammar faithfully, which make YAML quite error-prone for this specific application. [1]: The "Genius Tailor" was mentioned recently in a related discussion here: https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124868.html -- hvr From agentm at themactionfaction.com Sat Sep 17 01:20:38 2016 From: agentm at themactionfaction.com (A.M.) Date: Fri, 16 Sep 2016 21:20:38 -0400 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 In-Reply-To: References: Message-ID: On 09/16/2016 06:10 PM, Nicu Ionita wrote: > Is anybody else experiencing really slow compilations with GHC 7.10.2 on > Windows 10? > > I use stack to compile the project and run it under a mingw64 > environment provided by Github bash. The CPU usage is very low all the > time (meaning: GHC does barely use the CPU). On same computer with > Ubuntu 16.04 it just compiles normally, but under Windows it is for sure > 10x slower, maybe even more. Are you using virtualization? I see the same thing under virtualbox on Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I never see stack-invoked ghc use more than one CPU. On rare occasions, the linker phase hangs. I have confirmed that ghc reports 12 capabilities. I'm just glad that Windows is not my primary development platform; it's entirely possible that virtualization is the cause. VirtualBox is not known for being a speed demon, but the compilation speed is indeed embarrassing. Cheers, M -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From harendra.kumar at gmail.com Sat Sep 17 02:35:38 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 17 Sep 2016 08:05:38 +0530 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> <87y42s9d1h.fsf@ptsecurity.com> Message-ID: Since I triggered this discussion I feel obligated to summarize the important points that were presented. Is there a good place to record Haskell ecosystem related discussions (some wiki)? -harendra On 17 September 2016 at 05:57, Paolo Giarrusso wrote: > > > On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote: >> >> Chris Kahn writes: >> > I would like to second this thought. Using Haskell for package >> > descriptions needs to be thought out and executed with great care and >> > attention. It's really easy to go off the rails. >> > >> > Scala's build system lets you do very powerful things, but it also >> > makes things unnecessarily complicated and mystifying for beginners. >> > At my previous work where we used Scala extensively, there were many >> > times where the team simply resorted to external tools because >> > figuring out how to make some seemingly trivial change to an SBT >> > module was too time consuming. >> >> Let me guess (have no idea about sbt) -- unbridled Turing completeness? >> > > >> Declarativity is king for configuration, and Turing completeness ain't it >> -- >> please, see my other mail about subsetting Haskell. >> > > That's not the main problem with SBT. How do I explain it? Take this as an > example of what Haskell should *not* do. > > # SBT made difficult > > Look, we all know a monad is just a monoid in the category of > endofunctors, right?. Now, a SBT build configuration is just a > heterogeneously-typed map from keys to monadic values that can be evaluated > to a graph of setting transformers and build actions, so what's the problem? > And oh, I forgot to mention keys aren't simple strings but have a > hierarchy themselves, and this hierarchy is used for inheritance and > overriding of settings (nothing as simple as OO inheritance, mind you, > think of something like CSS but different). > Isn't using Haskell supposed to require a PhD? So why would its build > tools use something so simple as nested records, like Cabal does? > > I think I'm trolling, but the above is somewhat accurate (except for any > misunderstanding of SBT I might have)—I personally enjoy using SBT and its > power, and once you learn it can be reasonably easy, but I think Kmett's > lens library might be simpler to learn. > > In fairness, many SBT builds can be read without having any clue of the > above, because they look like imperative programs. But as soon as you need > to do a bit more or you make a type error, you end up facing some of the > above complexity—if you want, the "imperative program" abstraction is > extremely leaky. > > For instance, here's something "easy" (but count the amount of custom > symbolic operators): > > scalaVersion := "2.11.0" > scalacOptions += "-deprecation" > libraryDependencies += org.scalatest" %% "scalatest" % "2.0" > > Then you want to use one setting when defining another, and suddenly you > end up with: > > libraryDependencies <+= scalaVersion (ver => "org.scala-lang" % > "scala-compiler" % ver) > > Luckily, this can be done more easily nowadays, thanks to Scala macros O_O. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Sep 17 04:47:52 2016 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 17 Sep 2016 06:47:52 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <87intva4nt.fsf@gnu.org> References: <87intva4nt.fsf@gnu.org> Message-ID: On 2016-09-16 23:57, Herbert Valerio Riedel wrote: > Besides, many YAML (& JSON) parsers silently drop duplicate keys, so if > by accident you place a 2nd `else:` branch somewhere, you end up with an > ambiguous .yaml file which may either result in an error, in the first > key getting dropped (most likely variant), or in the 2nd key getting > dropped. Which one you get depends on the YAML parser implementation. I was actually curious about this, and it's interesting to note that even JSON which was supposed to have *ONE STANDARD* now apparently has two, an ECMA one and and IETF RFC (seems to be more recent). So I'd say JSON technically _allows_ duplicate keys, but that you cannot reasonably any type of sane behavior in practice if you do that. Source: http://stackoverflow.com/a/23195243 (Didn't check up on what the situation is in YAML. YAML is too awful to contemplate regardless.) Regards, From nicu.ionita at acons.at Sat Sep 17 06:04:59 2016 From: nicu.ionita at acons.at (Nicu Ionita) Date: Sat, 17 Sep 2016 06:04:59 +0000 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 In-Reply-To: References: Message-ID: No virtualisation, it is a dual boot maschine. 1 CPU would be good :-) In my case it is a very small fraction of it. Nicu ------ Originalnachricht ------ Von: "A.M." An: haskell-cafe at haskell.org Gesendet: 17.09.2016 03:20:38 Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >On 09/16/2016 06:10 PM, Nicu Ionita wrote: >> Is anybody else experiencing really slow compilations with GHC 7.10.2 >>on >> Windows 10? >> >> I use stack to compile the project and run it under a mingw64 >> environment provided by Github bash. The CPU usage is very low all >>the >> time (meaning: GHC does barely use the CPU). On same computer with >> Ubuntu 16.04 it just compiles normally, but under Windows it is for >>sure >> 10x slower, maybe even more. > >Are you using virtualization? I see the same thing under virtualbox on >Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I >never see stack-invoked ghc use more than one CPU. On rare occasions, >the linker phase hangs. I have confirmed that ghc reports 12 >capabilities. > >I'm just glad that Windows is not my primary development platform; it's >entirely possible that virtualization is the cause. VirtualBox is not >known for being a speed demon, but the compilation speed is indeed >embarrassing. > >Cheers, >M > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Sep 17 06:27:37 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 17 Sep 2016 08:27:37 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: <7c52b052-1f9f-45c6-1787-fe644222b59b@durchholz.org> Am 17.09.2016 um 01:53 schrieb Harendra Kumar: > I agree. Supporting conditionals with YAML looks hacky! All I have seen was direct translation and conclusion that it doesn't work. I haven't seen any attempts at making it look well. Also, while aesthetics isn't irrelevant, it's a pretty weak argument. From hvriedel at gmail.com Sat Sep 17 06:29:02 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 17 Sep 2016 08:29:02 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: (Bardur Arantsson's message of "Sat, 17 Sep 2016 06:47:52 +0200") References: <87intva4nt.fsf@gnu.org> Message-ID: <87h99favkh.fsf@gnu.org> On 2016-09-17 at 06:47:52 +0200, Bardur Arantsson wrote: [...] > I was actually curious about this, and it's interesting to note that > even JSON which was supposed to have *ONE STANDARD* now apparently has > two, an ECMA one and and IETF RFC (seems to be more recent). Btw, that's partly because ECMA and IETF weren't able to agree who "owns" JSON, for more details see https://www.tbray.org/ongoing/When/201x/2014/03/05/RFC7159-JSON -- hvr From jo at durchholz.org Sat Sep 17 06:41:37 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 17 Sep 2016 08:41:37 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <8737kza3x5.fsf@gnu.org> References: <8737kza3x5.fsf@gnu.org> Message-ID: Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel: > the prospect that a standard > format like YAML would allow to reuse standard tooling/libraries for > YAML seems quite weak to me; It's not about standard tooling, it's about tools written by third parties. Tools that you didn't have the time or interest to write yourself, but which still help make your ecosystem more useful to others. > if, for instance, you run the above through > a YAML pretty-printer, you easily end up with something like > > when: > - else: > ghc-options: -O0 > then: > ghc-options: -O2 > condition: flag(fast) > > or any other ordering depending on how the keys are sorted/hashed. Only if you use a bad pretty-printer that parses the YAML, then writes it in prettified form. Such a pretty-printer would also lose comments. In other words: I'd be surprised to find a pretty-printer in actual use that works that way. > Besides, many YAML (& JSON) parsers silently drop duplicate keys, That's indeed a common bug/misfeature due to historical accidents. It's easy to fix though, and libraries have started to acquire options to get that reported as an error. > I really don't understand the appeal of applying the golden hammer of > YAML, if `.cabal`'s grammar is already self-evident and concise with its > syntax: > > if flag(fast) > ghc-options: -O2 > else > ghc-options: -O0 > > where this if/then/else construct is encoded in the grammar proper > rather than being merely a semantic interpretation after decoding a > general grammar designed for simpler typed data-representations which > isn't even accurate enough (since it has additional symmetries/freedoms) > to capture the desired grammar faithfully, which make YAML quite > error-prone for this specific application. Yeah it isn't nice. Changing the grammar always produces that kind of awkwardnesses. However, for a fair comparison, you need to actively look for things that work better with the alternate grammar before you conclude it's worse. From malcolm.wallace at me.com Sat Sep 17 06:44:30 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Sat, 17 Sep 2016 07:44:30 +0100 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 In-Reply-To: References: Message-ID: Do you have Symantec Endpoint Protection or similar antivirus? We found that under certain paranoid settings, even "ghc --version" took upwards of seven seconds, and compilation was slowed by a couple of orders of magnitude. We think the AV was scanning the (large) compiler binary, plus any DLLs it loads, plus the source, interface, and object files read and generated, On every invocation. Linking was absolutely dog slow. We also think the AV was deliberately throttled to never use more than 10% of CPU time, to avoid being noticeable to the user. It is possible that there are AV settings you can tweak to avoid the paranoia, and trust the compiler, and any other file that has already been scanned once. Regards, Malcolm (iPhone) On 17 Sep 2016, at 07:04, Nicu Ionita wrote: No virtualisation, it is a dual boot maschine. 1 CPU would be good :-) In my case it is a very small fraction of it. Nicu ------ Originalnachricht ------ Von: "A.M." An: haskell-cafe at haskell.org Gesendet: 17.09.2016 03:20:38 Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> On 09/16/2016 06:10 PM, Nicu Ionita wrote: >> Is anybody else experiencing really slow compilations with GHC 7.10.2 on >> Windows 10? >> >> I use stack to compile the project and run it under a mingw64 >> environment provided by Github bash. The CPU usage is very low all the >> time (meaning: GHC does barely use the CPU). On same computer with >> Ubuntu 16.04 it just compiles normally, but under Windows it is for sure >> 10x slower, maybe even more. > > Are you using virtualization? I see the same thing under virtualbox on > Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I > never see stack-invoked ghc use more than one CPU. On rare occasions, > the linker phase hangs. I have confirmed that ghc reports 12 capabilities. > > I'm just glad that Windows is not my primary development platform; it's > entirely possible that virtualization is the cause. VirtualBox is not > known for being a speed demon, but the compilation speed is indeed > embarrassing. > > Cheers, > M _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sat Sep 17 06:54:14 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sat, 17 Sep 2016 08:54:14 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: > Give users and packager devs a choice of config file formats / representations. > Why is this even a goal? On the contrary, I see this as an anti-goal, because it leads to useless creativity and fragmentation. ​ such creativity and fragmentation may actually give benefits. can MVC [1] be relevant here? currently both config content (let's call it a *model*) and representation ( *view*: specific config file type) are bundled. if a common *model *is agreed on*,* package tool and IDE devs could pick any *view (*format*)* that best suits their / users needs. such fragmentation would not break the workflow. If someone thinks of a convenient format and believe it worth their time to write a *controller* for it, why not? [1] mvc -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Sep 17 06:57:32 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 17 Sep 2016 02:57:32 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: On Sat, Sep 17, 2016 at 2:41 AM, Joachim Durchholz wrote: > Changing the grammar always produces that kind of awkwardnesses. > However, for a fair comparison, you need to actively look for things that > work better with the alternate grammar before you conclude it's worse. > The burden is on you to prove that the massive upheaval of a switch is justified, not on others to prove that your preference won't work. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Sep 17 07:00:47 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 17 Sep 2016 03:00:47 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: On Sat, Sep 17, 2016 at 2:54 AM, Imants Cekusins wrote: > currently both config content (let's call it a *model*) and > representation (*view*: specific config file type) are bundled. > > if a common *model *is agreed on*,* package tool and IDE devs could pick > any *view (*format*)* that best suits their / users needs. > > such fragmentation would not break the workflow. If someone thinks of a > convenient format and believe it worth their time to write a *controller* > for it, why not? > Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages? Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write? -- 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 imantc at gmail.com Sat Sep 17 07:06:21 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sat, 17 Sep 2016 09:06:21 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: > Do I have to obtain whatever whizzy new controller you've come up with in order to work with your packages? > Do I have to do this when everyone has come up with their own whizzy new controller and I need to fit their packages into whatever I am trying to write? ​ that's the while point. If we could agree on a standard serializeable model, each controller would ensure the link between the *view* and the *model.* user could open a package in any IDE / environment. The environment's controller would display the model in its own / user preferred view. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu.ionita at acons.at Sat Sep 17 07:14:18 2016 From: nicu.ionita at acons.at (Nicu Ionita) Date: Sat, 17 Sep 2016 07:14:18 +0000 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 In-Reply-To: References: Message-ID: Sorry, I forgot to answer to all... ------ Originalnachricht ------ Von: "Nicu Ionita" An: "Malcolm Wallace" Gesendet: 17.09.2016 09:12:30 Betreff: Re[2]: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >Oh, this could be a good hint! I don't have other protection except >windows defender, which is own Windows AV. (Reviews suggest that this >should be enough, altough on other PC - not with Windows 10 - I use >different AVs) But maybe the Windows own AV exhibits the same >behaviour. I will check this, thanks! >Nicu > >------ Originalnachricht ------ >Von: "Malcolm Wallace" >An: "Nicu Ionita" >Cc: "haskell-cafe at haskell.org" >Gesendet: 17.09.2016 08:44:30 >Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 > >>Do you have Symantec Endpoint Protection or similar antivirus? We >>found that under certain paranoid settings, even "ghc --version" >>took upwards of seven seconds, and compilation was slowed by a couple >>of orders of magnitude. We think the AV was scanning the (large) >>compiler binary, plus any DLLs it loads, plus the source, interface, >>and object files read and generated, On every invocation. Linking was >>absolutely dog slow. We also think the AV was deliberately throttled >>to never use more than 10% of CPU time, to avoid being noticeable to >>the user. >> >>It is possible that there are AV settings you can tweak to avoid the >>paranoia, and trust the compiler, and any other file that has already >>been scanned once. >> >> Regards, >> Malcolm (iPhone) >> >>On 17 Sep 2016, at 07:04, Nicu Ionita wrote: >> >>No virtualisation, it is a dual boot maschine. >>1 CPU would be good :-) In my case it is a very small fraction of it. >>Nicu >> >>------ Originalnachricht ------ >>Von: "A.M." >>An: haskell-cafe at haskell.org >>Gesendet: 17.09.2016 03:20:38 >>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> >>>On 09/16/2016 06:10 PM, Nicu Ionita wrote: >>>> Is anybody else experiencing really slow compilations with GHC >>>>7.10.2 on >>>> Windows 10? >>>> >>>> I use stack to compile the project and run it under a mingw64 >>>> environment provided by Github bash. The CPU usage is very low all >>>>the >>>> time (meaning: GHC does barely use the CPU). On same computer with >>>> Ubuntu 16.04 it just compiles normally, but under Windows it is for >>>>sure >>>> 10x slower, maybe even more. >>> >>>Are you using virtualization? I see the same thing under virtualbox >>>on >>>Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I >>>never see stack-invoked ghc use more than one CPU. On rare occasions, >>>the linker phase hangs. I have confirmed that ghc reports 12 >>>capabilities. >>> >>>I'm just glad that Windows is not my primary development platform; >>>it's >>>entirely possible that virtualization is the cause. VirtualBox is not >>>known for being a speed demon, but the compilation speed is indeed >>>embarrassing. >>> >>>Cheers, >>>M >>> >>> >>_______________________________________________ >>Haskell-Cafe mailing list >>To (un)subscribe, modify options or view archives go to: >>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sat Sep 17 07:17:22 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sat, 17 Sep 2016 09:17:22 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: .. the model would be shipped with packages. pretty printing the config model to formatted yet non-editable config view (like the docs) may be made part of build process. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Sep 17 07:18:34 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 17 Sep 2016 03:18:34 -0400 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: On Sat, Sep 17, 2016 at 3:06 AM, Imants Cekusins wrote: > that's the while point. If we could agree on a standard serializeable > model, That seems like a big "if". Especially since many dev tools exist to extend the model, and quite aside from "so where's the 'standard' now", conflicts you can currently control (mostly) suddenly become problematic. (I'm tempted to point to how gtk2hs's configuration phase works. pTk may be an even more severe example, although non-Haskell.) -- 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 jo at durchholz.org Sat Sep 17 07:22:51 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 17 Sep 2016 09:22:51 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: Am 17.09.2016 um 08:57 schrieb Brandon Allbery: > On Sat, Sep 17, 2016 at 2:41 AM, Joachim Durchholz wrote: > >> Changing the grammar always produces that kind of awkwardnesses. >> However, for a fair comparison, you need to actively look for things that >> work better with the alternate grammar before you conclude it's worse. > > The burden is on you to prove that the massive upheaval of a switch is > justified, not on others to prove that your preference won't work. I do like YAML, but I know far too little about the various use cases to justify any preference; it's quite possible that it's not a good fit, but I can't really decide it. All I can do is provide knowledge about YAML, which in some cases was really necessary, and pointing out one-sided arguments such as Herbert's; doing a review of Cabal config usecases and see how well they map to YAML is, sadly, beyond my capabilities. Contributing the best I can and all that. From imantc at gmail.com Sat Sep 17 07:23:22 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sat, 17 Sep 2016 09:23:22 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: > That seems like a big "if". the model may be versioned. it may include "tool T only section" which the other tools skip over or simply display with *show* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Sat Sep 17 07:25:48 2016 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 17 Sep 2016 09:25:48 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: (Joachim Durchholz's message of "Sat, 17 Sep 2016 08:41:37 +0200") References: <8737kza3x5.fsf@gnu.org> Message-ID: <87d1k3asxv.fsf@gnu.org> Hello, On 2016-09-17 at 08:41:37 +0200, Joachim Durchholz wrote: > Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel: >> the prospect that a standard format like YAML would allow to reuse >> standard tooling/libraries for YAML seems quite weak to me; > > It's not about standard tooling, it's about tools written by third > parties. Tools that you didn't have the time or interest to write > yourself, but which still help make your ecosystem more useful to > others. Sure, but we don't need to throw out the baby with the bathwater to accomplish that! Oleg is currently working on a new parser for cabal.config, cabal.project & ${pkg}.cabal grammar (NB: cabal already uses one standard unified syntax for all its configuration/description files) which lends itself better to provide equivalent of ghc-exactprint (i.e. perfect roundtripping, allowing for faithful refactoring tooling). Then 3rd parties can then use this new parser as a library. [..] >> I really don't understand the appeal of applying the golden hammer of >> YAML, if `.cabal`'s grammar is already self-evident and concise with its >> syntax: >> >> if flag(fast) >> ghc-options: -O2 >> else >> ghc-options: -O0 >> >> where this if/then/else construct is encoded in the grammar proper >> rather than being merely a semantic interpretation after decoding a >> general grammar designed for simpler typed data-representations which >> isn't even accurate enough (since it has additional symmetries/freedoms) >> to capture the desired grammar faithfully, which make YAML quite >> error-prone for this specific application. > > Yeah it isn't nice. > Changing the grammar always produces that kind of awkwardnesses. > However, for a fair comparison, you need to actively look for things > that work better with the alternate grammar before you conclude it's > worse. Well, that burden of proof lies with those who argue YAML to be superior to .cabal syntax, doesn't it? The if/then/else awkwardness is just one aspect I pointed out explicitly. I hinted at other issues which result from first parsing into an inappropriate data-model just for the sake of using YAML, and then having to re-parse that interim lossy data-model for real into the actual data-model we're interested in (and hoping we didn't loose some of the essential information). But I see no need to invest time to spell those problems out until I see a compelling argument that e.g. YAML syntax is really preferable (to justify the costs incurred) to the status quo in the first place. -- hvr From spam at scientician.net Sat Sep 17 07:51:25 2016 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 17 Sep 2016 09:51:25 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <87d1k3asxv.fsf@gnu.org> References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: On 2016-09-17 09:25, Herbert Valerio Riedel wrote: > Hello, > > On 2016-09-17 at 08:41:37 +0200, Joachim Durchholz wrote: >> Am 17.09.2016 um 00:13 schrieb Herbert Valerio Riedel: >>> the prospect that a standard format like YAML would allow to reuse >>> standard tooling/libraries for YAML seems quite weak to me; >> >> It's not about standard tooling, it's about tools written by third >> parties. Tools that you didn't have the time or interest to write >> yourself, but which still help make your ecosystem more useful to >> others. > > Sure, but we don't need to throw out the baby with the bathwater to > accomplish that! > > Oleg is currently working on a new parser for cabal.config, > cabal.project & ${pkg}.cabal grammar (NB: cabal already uses one > standard unified syntax for all its configuration/description files) > which lends itself better to provide equivalent of ghc-exactprint > (i.e. perfect roundtripping, allowing for faithful refactoring > tooling). Then 3rd parties can then use this new parser as a library. I didn't see anything in the PR about exporting that parser as a library. Do you have a reference for that? Regardless: It will only help third party code written in Haskell. Much as I like most userland software to be written in Haskell it won't help e.g. IntelliJ IDEA one whit. Regards, From lonetiger at gmail.com Sat Sep 17 07:56:11 2016 From: lonetiger at gmail.com (Phyx) Date: Sat, 17 Sep 2016 08:56:11 +0100 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 Message-ID: > Is anybody else experiencing really slow compilations with GHC 7.10.2 on > Windows 10? The problem comes down to these lines https://github.com/ghc/ghc/blob/e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/libraries/base/include/HsBase.h#L525 The issue is that the entire Windows support in GHC Is mostly provided through POSIX support. Windows however isn't a POSIX system, and these APIs were implemented for compatibility and not performance. This is the reason why any I/O operation on GHC Windows will be significantly slower. This is the same reason why Console I/O is also much slower. Why Unicode support is a bit wonky etc. GHC Is currently just not using native Windows syscalls, because by large most developers of GHC don't use Windows. There are other issues (but I won't go in detail on the user list). We are trying to fix this, there are multiple tickets open such as https://ghc.haskell.org/trac/ghc/ticket/11394 but it's a big task and there are very limited resources so priority is given to things currently broken rather than just slow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Sep 17 08:50:29 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 17 Sep 2016 10:50:29 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: Am 17.09.2016 um 09:51 schrieb Bardur Arantsson: > Regardless: It will only help third party code written in Haskell. Much > as I like most userland software to be written in Haskell it won't help > e.g. IntelliJ IDEA one whit. Unless Haskell runs on the JVM. Do you know whether Frege (https://github.com/Frege) is a viable option for that? At least at the surface, it qualifies, but I don't know whether the details (performance, Java library interoperability, stability, availability of Haskell language extensions) work out well enough for that. From heraldhoi at gmail.com Sat Sep 17 09:00:40 2016 From: heraldhoi at gmail.com (Geraldus) Date: Sat, 17 Sep 2016 09:00:40 +0000 Subject: [Haskell-cafe] Issue with building executables using Cabal on Travis In-Reply-To: <5fdfce10-d288-467c-9b3c-1f1d189b5324@googlegroups.com> References: <5fdfce10-d288-467c-9b3c-1f1d189b5324@googlegroups.com> Message-ID: Hey Paolo! Thank you! Yes, after a closer look I found that executable is built indeed, and error occurs somewhere after `cabal test` command. Running `cabal sdist` (in project root) locally yields exact same error! And you're right I've followed the instructions from Stack's docs and copy-pasted entire script (though I've made some changes to have GHCJS build too). Finally, thanks to you Paolo, I've spotted typos in cabal script. As you can see I have `Transient/Move` in extra source files section, however in executable section there are `Transient/Monitor` by mistake. After fixing that now `sdist` command succeeds locally! Very appreciate! сб, 17 сент. 2016 г. в 3:48, Paolo Giarrusso : > > > On Friday, September 16, 2016 at 4:13:44 PM UTC+2, Артур Файзрахманов > wrote: >> >> Hi Café! >> >> Recently we added an executable section to our Transient-Universe package >> and now Travis cabal builds always failing. The error message is: >> >> In-place registering transient-universe-0.3.4... >> Preprocessing executable 'monitorService' for transient-universe-0.3.4... >> [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) >> Linking dist/build/monitorService/monitorService ... >> No errors or warnings could be found in the package. >> Re-configuring with test suites enabled. If this fails, please run configure >> manually. >> Resolving dependencies... >> Configuring transient-universe-0.3.4... >> Package has no buildable test suites. >> Building source dist for transient-universe-0.3.4... >> Preprocessing library transient-universe-0.3.4... >> Preprocessing executable 'monitorService' for transient-universe-0.3.4... >> cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist >> Installing library in >> /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX >> Installing executable(s) in /home/travis/.cabal/bin >> Warning: The directory /home/travis/.cabal/bin is not in the system search >> path. >> cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. >> >> (Full log — >> https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you >> can see that other Cabal builds fail with same error, however all Stack >> builds are fine). >> > > Not sure if you figured (you already reverted the change in > https://github.com/agocorona/transient-universe/pull/16), but the key > error is > > cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist > > and the error message is correct. The tricky bit is that this only fails > when you run cabal sdist, not in the normal workflow—I remember being hit > by this at some point. > > IIUC you're using the Travis config stack suggests (which in turn comes > HVR's config)—maybe that needs more docs to help troubleshooting? That's > full of subtleties that you don't learn by copy-pasting it. > > Cheers, > Paolo > > >> This is a chunk of cabal file: >> >> extra-source-files: src/client/Transient/Move/Services/MonitorService.hs >> src/server/Transient/Move/Services/MonitorService.hs >> >> executable monitorService >> build-depends: base >4 && <5 >> if !impl(ghcjs >=0.1) >> hs-source-dirs: src/server/Transient/Monitor/Services >> build-depends: transformers >> , transient >=0.4.4 >> , transient-universe >> else >> hs-source-dirs: src/client/Transient/Monitor/Services >> main-is: MonitorService.hs >> default-language: Haskell2010 >> ghc-options: -threaded -rtsopts >> >> >> Have anyone faced similar issue? >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Sat Sep 17 09:35:53 2016 From: spam at scientician.net (Bardur Arantsson) Date: Sat, 17 Sep 2016 11:35:53 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: On 2016-09-17 10:50, Joachim Durchholz wrote: > Am 17.09.2016 um 09:51 schrieb Bardur Arantsson: >> Regardless: It will only help third party code written in Haskell. Much >> as I like most userland software to be written in Haskell it won't help >> e.g. IntelliJ IDEA one whit. > > Unless Haskell runs on the JVM. I think people have been wishing for that for a while... some people even worked on it, but so far nothing's come of it AFAIK. > Do you know whether Frege (https://github.com/Frege) is a viable option > for that? Not in the least last time I checked. It's missing far too many of the extensions that almost everybody uses as a matter of course. Maybe given a few more years, but I'm not holding my breath. Regards, From ezyang at mit.edu Sat Sep 17 09:48:02 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Sat, 17 Sep 2016 18:48:02 +0900 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <1474032338.4049502.727784409.70E7C6D5@webmail.messagingengine.com> <87y42s9d1h.fsf@ptsecurity.com> Message-ID: <1474105625-sup-5068@sabre> https://github.com/ghc-proposals/ghc-proposals/ could be used for this purpose. There is also the Trac wiki but I find it is a bit too hard to keep under control with comments. Edward Excerpts from Harendra Kumar's message of 2016-09-17 08:05:38 +0530: > Since I triggered this discussion I feel obligated to summarize the > important points that were presented. Is there a good place to record > Haskell ecosystem related discussions (some wiki)? > > -harendra > > On 17 September 2016 at 05:57, Paolo Giarrusso > wrote: > > > > > > > On Friday, September 16, 2016 at 3:42:48 PM UTC+2, Kosyrev Serge wrote: > >> > >> Chris Kahn writes: > >> > I would like to second this thought. Using Haskell for package > >> > descriptions needs to be thought out and executed with great care and > >> > attention. It's really easy to go off the rails. > >> > > >> > Scala's build system lets you do very powerful things, but it also > >> > makes things unnecessarily complicated and mystifying for beginners. > >> > At my previous work where we used Scala extensively, there were many > >> > times where the team simply resorted to external tools because > >> > figuring out how to make some seemingly trivial change to an SBT > >> > module was too time consuming. > >> > >> Let me guess (have no idea about sbt) -- unbridled Turing completeness? > >> > > > > > >> Declarativity is king for configuration, and Turing completeness ain't it > >> -- > >> please, see my other mail about subsetting Haskell. > >> > > > > That's not the main problem with SBT. How do I explain it? Take this as an > > example of what Haskell should *not* do. > > > > # SBT made difficult > > > > Look, we all know a monad is just a monoid in the category of > > endofunctors, right?. Now, a SBT build configuration is just a > > heterogeneously-typed map from keys to monadic values that can be evaluated > > to a graph of setting transformers and build actions, so what's the problem? > > And oh, I forgot to mention keys aren't simple strings but have a > > hierarchy themselves, and this hierarchy is used for inheritance and > > overriding of settings (nothing as simple as OO inheritance, mind you, > > think of something like CSS but different). > > Isn't using Haskell supposed to require a PhD? So why would its build > > tools use something so simple as nested records, like Cabal does? > > > > I think I'm trolling, but the above is somewhat accurate (except for any > > misunderstanding of SBT I might have)—I personally enjoy using SBT and its > > power, and once you learn it can be reasonably easy, but I think Kmett's > > lens library might be simpler to learn. > > > > In fairness, many SBT builds can be read without having any clue of the > > above, because they look like imperative programs. But as soon as you need > > to do a bit more or you make a type error, you end up facing some of the > > above complexity—if you want, the "imperative program" abstraction is > > extremely leaky. > > > > For instance, here's something "easy" (but count the amount of custom > > symbolic operators): > > > > scalaVersion := "2.11.0" > > scalacOptions += "-deprecation" > > libraryDependencies += org.scalatest" %% "scalatest" % "2.0" > > > > Then you want to use one setting when defining another, and suddenly you > > end up with: > > > > libraryDependencies <+= scalaVersion (ver => "org.scala-lang" % > > "scala-compiler" % ver) > > > > Luckily, this can be done more easily nowadays, thanks to Scala macros O_O. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > From yann.esposito at gmail.com Sat Sep 17 10:06:43 2016 From: yann.esposito at gmail.com (Yann Esposito) Date: Sat, 17 Sep 2016 03:06:43 -0700 (PDT) Subject: [Haskell-cafe] ANN: stack-1.2.0 In-Reply-To: References: Message-ID: <07d749dd-aea4-40af-844b-88a0b557cdac@googlegroups.com> Just to note, on OS X, wget is not installed by default. So in one of my script I use: curl -sSL https://get.haskellstack.org/ | sh instead. On Friday, September 16, 2016 at 4:05:31 PM UTC+2, Emanuel Borsboom wrote: > > See https://haskellstack.org for installation and upgrade instructions. > > Release notes: > > * On many Un*x systems, Stack can now be installed with a simple > one-liner: > > wget -qO- https://get.haskellstack.org/ | sh > > * The fix for > [#2175](https://github.com/commercialhaskell/stack/issues/2175) > entails that stack must perform a full clone of a large Git repo of > Hackage meta-information. The total download size is about 200 MB. > Please be aware of this when upgrading your stack installation. > > * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as > there > are reports of GHC panics when building some packages (including Stack > itself). See [#2577]( > https://github.com/commercialhaskell/stack/issues/2577) > > * This version of Stack does not build on ARM or PowerPC systems (see > [store#37](https://github.com/fpco/store/issues/37)). Please stay with > version 1.1.2 for now on those architectures. This will be rectified > soon! > > * We are now releasing a > [statically linked Stack binary for 64-bit Linux]( > https://www.stackage.org/stack/linux-x86_64-static). > Please try it and let us know if you run into any trouble on your > platform. > > * We are planning some changes to our Linux releases, including dropping > our > Ubuntu, Debian, CentOS, and Fedora package repositories and switching to > statically linked binaries. We would value your feedback in > [#2534](https://github.com/commercialhaskell/stack/issues/2534). > > Major changes: > > * Add `stack hoogle` command. > [#55](https://github.com/commercialhaskell/stack/issues/55) > * Support for absolute file path in `url` field of `setup-info` or > `--ghc-bindist` > * Add support for rendering GHCi scripts targeting different GHCi like > applications > [#2457](https://github.com/commercialhaskell/stack/pull/2457) > > Behavior changes: > > * Remove `stack ide start` and `stack ide load-targets` commands. > [#2178](https://github.com/commercialhaskell/stack/issues/2178) > * Support .buildinfo files in `stack ghci`. > [#2242](https://github.com/commercialhaskell/stack/pull/2242) > * Support -ferror-spans syntax in GHC error messages. > * Avoid unpacking ghc to `/tmp` > [#996](https://github.com/commercialhaskell/stack/issues/996) > * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC > variant and can no longer be specified using the `ghc-variant` option, > and instead is treated more like a slightly different platform. > > Other enhancements: > > * Use the `store` package for binary serialization of most caches. > * Only require minor version match for Docker stack exe. > This way, we can make patch releases for version bounds and similar > build issues without needing to upload new binaries for Docker. > * Stack/Nix: Passes the right ghc derivation as an argument to the > `shell.nix` when a > custom `shell.nix` is used > See [#2243](https://github.com/commercialhaskell/stack/issues/2243) > * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template > Haskell can work > (See _e.g._ [this HaskellR issue]( > https://github.com/tweag/HaskellR/issues/253)) > * Parse CLI arguments and configuration files into less permissive types, > improving error messages for bad inputs. > [#2267](https://github.com/commercialhaskell/stack/issues/2267) > * Add the ability to explictly specify a gcc executable. > [#593](https://github.com/commercialhaskell/stack/issues/593) > * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a > derivation > like `haskell.compiler.ghc801` > See [#2259](https://github.com/commercialhaskell/stack/issues/2259) > * Perform some subprocesses during setup concurrently, slightly speeding > up most > commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) > * `stack setup` no longer unpacks to the system temp dir on posix systems. > [#996](https://github.com/commercialhaskell/stack/issues/996) > * `stack setup` detects libtinfo6 and ncurses6 and can download alternate > GHC > bindists [#257](https://github.com/commercialhaskell/stack/issues/257) > [#2302](https://github.com/commercialhaskell/stack/issues/2302). > * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist > [#2103](https://github.com/commercialhaskell/stack/issues/2103) > * Custom `stack` binaries list dependency versions in output for > `--version`. > See [#2222](https://github.com/commercialhaskell/stack/issues/2222) > and [#2450](https://github.com/commercialhaskell/stack/issues/2450). > * Use a pretty printer to output dependency resolution errors. > [#1912](https://github.com/commercialhaskell/stack/issues/1912) > * Remove the `--os` flag > [#2227](https://github.com/commercialhaskell/stack/issues/2227) > * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. > [#2293](https://github.com/commercialhaskell/stack/issues/2293). > * Add `stack ide targets` command. > * Enhance debug logging with subprocess timings. > * Pretty-print YAML parse errors > [#2374](https://github.com/commercialhaskell/stack/issues/2374) > * Clarify confusing `stack setup` output > [#2314](https://github.com/commercialhaskell/stack/issues/2314) > * Delete `Stack.Types` multimodule to improve build times > [#2405](https://github.com/commercialhaskell/stack/issues/2405) > * Remove spurious newlines in build logs > [#2418](https://github.com/commercialhaskell/stack/issues/2418) > * Interpreter: Provide a way to hide implicit packages > [#1208](https://github.com/commercialhaskell/stack/issues/1208) > * Check executability in exec lookup > [#2489](https://github.com/commercialhaskell/stack/issues/2489) > > Bug fixes: > > * Fix cabal warning about use of a deprecated cabal flag > [#2350](https://github.com/commercialhaskell/stack/issues/2350) > * Support most executable extensions on Windows > [#2225](https://github.com/commercialhaskell/stack/issues/2225) > * Detect resolver change in `stack solver` > [#2252](https://github.com/commercialhaskell/stack/issues/2252) > * Fix a bug in docker image creation where the wrong base image was > selected > [#2376](https://github.com/commercialhaskell/stack/issues/2376) > * Ignore special entries when unpacking tarballs > [#2361](https://github.com/commercialhaskell/stack/issues/2361) > * Fixes src directory pollution of `style.css` and `highlight.js` with GHC > 8's > haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) > * Handle filepaths with spaces in `stack ghci` > [#2266](https://github.com/commercialhaskell/stack/issues/2266) > * Apply ghc-options to snapshot packages > [#2289](https://github.com/commercialhaskell/stack/issues/2289) > * stack sdist: Fix timestamp in tarball > [#2394](https://github.com/commercialhaskell/stack/pull/2394) > * Allow global Stack arguments with a script > [#2316](https://github.com/commercialhaskell/stack/issues/2316) > * Inconsistency between ToJSON and FromJSON instances of PackageLocation > [#2412](https://github.com/commercialhaskell/stack/pull/2412) > * Perform Unicode normalization on filepaths > [#1810](https://github.com/commercialhaskell/stack/issues/1810) > * Solver: always keep ghc wired-in as hard constraints > [#2453](https://github.com/commercialhaskell/stack/issues/2453) > * Support OpenBSD's tar where possible, require GNU tar for xz support > [#2283](https://github.com/commercialhaskell/stack/issues/2283) > * Fix using --coverage with Cabal-1.24 > [#2424](https://github.com/commercialhaskell/stack/issues/2424) > * When marking exe installed, remove old version > [#2373](https://github.com/commercialhaskell/stack/issues/2373) > * Stop truncating all-cabal-hashes git repo > [#2175](https://github.com/commercialhaskell/stack/issues/2175) > * Handle non-ASCII filenames on Windows > [#2491](https://github.com/commercialhaskell/stack/issues/2491) > * Avoid using multiple versions of a package in script interpreter > by passing package-id to ghc/runghc > [#1957](https://github.com/commercialhaskell/stack/issues/1957) > * Only pre-load compiler version when using nix integration > [#2459](https://github.com/commercialhaskell/stack/issues/2459) > * Solver: parse cabal errors also on Windows > [#2502](https://github.com/commercialhaskell/stack/issues/2502) > * Allow exec and ghci commands in interpreter mode. > Scripts can now automatically open in the repl by using `exec ghci` > instead of `runghc` in the shebang command. > [#2510](https://github.com/commercialhaskell/stack/issues/2510) > * Now consider a package to be dirty when an extra-source-file is changed. > See [#2040](https://github.com/commercialhaskell/stack/issues/2040) > > Thanks to all our contributors for this release: > > * Aaron Friel > * Andrew Cowie > * AndrewRademacher > * Anton Felix Lorenzen > * Brian McKenna > * Chris Done > * Dan Aloni > * danald > * Daniel Casanueva > * Denis > * Denis Kasak > * Emanuel Borsboom > * erewok > * Gabor Greif > * Gurkenglas > * Harendra Kumar > * hesiod > * Judah Jacobson > * Khan Thompson > * Mathieu Boespflug > * Michael Sloan > * Michael Snoyman > * Mohit Agarwal > * Moritz Angermann > * Oleg Grenrus > * Paolo G. Giarrusso > * Philipp Kant > * Ryan Desfosses > * Sid Kapur > * Sidharth Kapur > * Simon Jakobi > * Tim Dysinger > * Tim Düsterhus > * Tobias Markus > * YPares > * Yuriy Syrovetskiy > * Yves Parès (Ywen) > * ___ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sat Sep 17 11:31:40 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sat, 17 Sep 2016 13:31:40 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: <7591faca-5d44-09b9-e738-ae0a0fa21e94@durchholz.org> Am 17.09.2016 um 11:35 schrieb Bardur Arantsson: > On 2016-09-17 10:50, Joachim Durchholz wrote: >> Do you know whether Frege (https://github.com/Frege) is a viable option >> for that? > > Not in the least last time I checked. It's missing far too many of the > extensions that almost everybody uses as a matter of course. Pity. Any idea how hard it would be to make it compile ghc? From nikita at karetnikov.org Sat Sep 17 12:00:50 2016 From: nikita at karetnikov.org (Nikita Karetnikov) Date: Sat, 17 Sep 2016 15:00:50 +0300 Subject: [Haskell-cafe] Looking for a source level debugger Message-ID: Originally sent this to /r/haskell, but it doesn't show up there for some reason, so re-sending here. Is anyone aware of a source level debugger that can be used with GHC? That is, something integrated into an editor (as a plugin, perhaps) that can highlight the line being executed, show locals, etc. (Think of WinDbg without the registers window.) I'm mostly interested in something that can work on a Linux-based system, but solutions for other platforms are welcome, too! I've heard that Sublime can run on 3 OSes, is there a solution for it, for instance? P.S. I'm not looking for opinions on whether you think a debugger is necessary or not when programming in Haskell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Sat Sep 17 12:12:07 2016 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sat, 17 Sep 2016 09:12:07 -0300 Subject: [Haskell-cafe] Looking for a source level debugger In-Reply-To: References: Message-ID: <49aa8c73-0309-f4c0-4a37-7063dccb9fe6@gmail.com> On 17/09/16 09:00, Nikita Karetnikov wrote: > Is anyone aware of a source level debugger that can be used with GHC? > That is, something integrated into an editor (as a plugin, perhaps) that > can highlight the line being executed, show locals, etc. ghci is a interactive debugger also, it isn't that useful in haskell as you reduce expressions instead of evaluating step by step a set of commands. You can check out on the repl with :? the commands (read for the ones with :step :next section). From deywos at mit.edu Sat Sep 17 12:20:20 2016 From: deywos at mit.edu (Deven Lahoti) Date: Sat, 17 Sep 2016 08:20:20 -0400 Subject: [Haskell-cafe] Looking for a source level debugger In-Reply-To: <49aa8c73-0309-f4c0-4a37-7063dccb9fe6@gmail.com> References: <49aa8c73-0309-f4c0-4a37-7063dccb9fe6@gmail.com> Message-ID: On 17/09/16 09:00, Nikita Karetnikov wrote: > I'm not looking for opinions on whether you think a debugger is necessary or not when programming in Haskell. On 17/09/2016 08:12, Ruben Astudillo wrote: > it isn't that useful in haskell as > you reduce expressions instead of evaluating step by step a set of > commands. You can check out on the repl with :? the commands (read for > the ones with :step :next section). ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicu.ionita at acons.at Sat Sep 17 13:14:40 2016 From: nicu.ionita at acons.at (Nicu Ionita) Date: Sat, 17 Sep 2016 13:14:40 +0000 Subject: [Haskell-cafe] Very _very_ slow compiles on Windows 10 - solved In-Reply-To: References: Message-ID: Yes, this is it! I deactivated Windows Defender real time protection mode, then I compiled again: normal compilation times. Thanks for the hint! Nicu ------ Originalnachricht ------ Von: "Nicu Ionita" An: "haskell-cafe at haskell.org" Gesendet: 17.09.2016 09:14:18 Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >Sorry, I forgot to answer to all... > >------ Originalnachricht ------ >Von: "Nicu Ionita" >An: "Malcolm Wallace" >Gesendet: 17.09.2016 09:12:30 >Betreff: Re[2]: [Haskell-cafe] Very _very_ slow compiles on Windows 10 > >>Oh, this could be a good hint! I don't have other protection except >>windows defender, which is own Windows AV. (Reviews suggest that this >>should be enough, altough on other PC - not with Windows 10 - I use >>different AVs) But maybe the Windows own AV exhibits the same >>behaviour. I will check this, thanks! >>Nicu >> >>------ Originalnachricht ------ >>Von: "Malcolm Wallace" >>An: "Nicu Ionita" >>Cc: "haskell-cafe at haskell.org" >>Gesendet: 17.09.2016 08:44:30 >>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> >>>Do you have Symantec Endpoint Protection or similar antivirus? We >>>found that under certain paranoid settings, even "ghc --version" >>>took upwards of seven seconds, and compilation was slowed by a couple >>>of orders of magnitude. We think the AV was scanning the (large) >>>compiler binary, plus any DLLs it loads, plus the source, interface, >>>and object files read and generated, On every invocation. Linking was >>>absolutely dog slow. We also think the AV was deliberately throttled >>>to never use more than 10% of CPU time, to avoid being noticeable to >>>the user. >>> >>>It is possible that there are AV settings you can tweak to avoid the >>>paranoia, and trust the compiler, and any other file that has already >>>been scanned once. >>> >>> Regards, >>> Malcolm (iPhone) >>> >>>On 17 Sep 2016, at 07:04, Nicu Ionita wrote: >>> >>>No virtualisation, it is a dual boot maschine. >>>1 CPU would be good :-) In my case it is a very small fraction of it. >>>Nicu >>> >>>------ Originalnachricht ------ >>>Von: "A.M." >>>An: haskell-cafe at haskell.org >>>Gesendet: 17.09.2016 03:20:38 >>>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >>> >>>>On 09/16/2016 06:10 PM, Nicu Ionita wrote: >>>>> Is anybody else experiencing really slow compilations with GHC >>>>>7.10.2 on >>>>> Windows 10? >>>>> >>>>> I use stack to compile the project and run it under a mingw64 >>>>> environment provided by Github bash. The CPU usage is very low all >>>>>the >>>>> time (meaning: GHC does barely use the CPU). On same computer with >>>>> Ubuntu 16.04 it just compiles normally, but under Windows it is >>>>>for sure >>>>> 10x slower, maybe even more. >>>> >>>>Are you using virtualization? I see the same thing under virtualbox >>>>on >>>>Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, >>>>I >>>>never see stack-invoked ghc use more than one CPU. On rare >>>>occasions, >>>>the linker phase hangs. I have confirmed that ghc reports 12 >>>>capabilities. >>>> >>>>I'm just glad that Windows is not my primary development platform; >>>>it's >>>>entirely possible that virtualization is the cause. VirtualBox is >>>>not >>>>known for being a speed demon, but the compilation speed is indeed >>>>embarrassing. >>>> >>>>Cheers, >>>>M >>>> >>>> >>>_______________________________________________ >>>Haskell-Cafe mailing list >>>To (un)subscribe, modify options or view archives go to: >>>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahulmutt at gmail.com Sat Sep 17 14:05:38 2016 From: rahulmutt at gmail.com (Rahul Muttineni) Date: Sat, 17 Sep 2016 19:35:38 +0530 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: Hi Joachim, Besides Frege, Haskell does indeed run on the JVM now via GHCVM [1] - it was my HSoC project. I'll be doing a release in a couple days once I get a couple issues sorted out and the installation is streamlined. I'm currently working with Cary Robbins on getting the HaskForce Intellij Plugin working for GHCVM. If all goes well, GHCVM 0.0.1 will ship with ghcvm, ghcvm-pkg, cabalvm (a fork of cabal-install 1.22.9.0/Cabal 1.22.8.0 that supports GHCVM), a working Intellij plugin, and will support all of GHC 7.10.3 extensions other than Template Haskell + interoperation with Java libraries. You can join us on Gitter for live updates [2]. [1] http://github.org/rahulmut/ghcvm [2] http://gitter.im/rahulmutt/ghcvm Thanks, Rahul On Sat, Sep 17, 2016 at 2:20 PM, Joachim Durchholz wrote: > Am 17.09.2016 um 09:51 schrieb Bardur Arantsson: > >> Regardless: It will only help third party code written in Haskell. Much >> as I like most userland software to be written in Haskell it won't help >> e.g. IntelliJ IDEA one whit. >> > > Unless Haskell runs on the JVM. > Do you know whether Frege (https://github.com/Frege) is a viable option > for that? At least at the surface, it qualifies, but I don't know whether > the details (performance, Java library interoperability, stability, > availability of Haskell language extensions) work out well enough for that. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Rahul Muttineni -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Sat Sep 17 15:15:32 2016 From: simon at joyful.com (Simon Michael) Date: Sat, 17 Sep 2016 08:15:32 -0700 Subject: [Haskell-cafe] help wanted: hledger Message-ID: <1EA50EFB-32F8-4A7A-B034-284F08C52F1E@joyful.com> Hey all, I believe hledger (http://hledger.org) is a useful project, with potential to be much better. I have more ideas and know-how than free time. By now the project has a fairly large surface area, such that I'm often avoiding it when I have only small chunks of time to work on something. So I'm putting out the call for help! I'm grateful for the occasional contributions over the last 9 years, and I would welcome more collaborators to share the work. That sounds appealing, right ? Really, this is a fun project, since you can use it to save money and time and build your wealth-accumulation skills. And as an active contributor, you will have access to free tutoring from a 9y haskeller, 20y consultant and FOSS developer, and 30y coder (that's me). Here are some particular areas needing help: - Release 0.28 (or should it be 1.0 ?) has been pending for a long time, partly because hledger, hledger-ui, hledger-web & hledger-api are released together. This is the number one priority at the moment. Also: - Integrate John Wiegley's ledger4 code as an additional parser, increasing our compatibility with Ledger, making hledger features more easily accessible to Ledger users. - Website beautification and marketing in general. - Contribute, solicit or raise funding, so we can sponsor developers/designers/minions, set meaningful issue bounties, etc. - UIs/integration for mobile/small-screen devices. - More import/export formats, easier migration to and from other tools. I hope you'll check out hledger and get involved. http://hledger.org -> Contribute Best! -Simon From vshabanoff at gmail.com Sat Sep 17 22:19:42 2016 From: vshabanoff at gmail.com (Vladimir Shabanov) Date: Sun, 18 Sep 2016 01:19:42 +0300 Subject: [Haskell-cafe] New maintainer for HsOpenSSL Message-ID: Hello, I would like to become a new maintainer for HsOpenSSL package. Package was last updated on January 6, 2015 and no new commits at https://github.com/phonohawk/HsOpenSSL since then. My pull request https://github.com/phonohawk/HsOpenSSL/pull/40 is waiting here for more than a year. And there are ten more ignored pull requests. I've mailed current maintainer https://github.com/phonohawk/ pho at cielonegro.org four months ago and received no answer. Since there are no other maintainers I want to become the one. Who am I? Developer of BazQux Reader which is a commercial Haskell application that uses HsOpenSSL 24x7 in its crawler. Will be glad to hear any suggestions or objections. If not, I'm planning to wait for a few weeks and ask Hackage admins for maintenance rights. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Sun Sep 18 10:31:09 2016 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sun, 18 Sep 2016 12:31:09 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> <87d1k3asxv.fsf@gnu.org> Message-ID: <20160918103109.GA7130@octa> On Sat, Sep 17, 2016 at 09:51:25AM +0200, Bardur Arantsson wrote: > Regardless: It will only help third party code written in Haskell. Much > as I like most userland software to be written in Haskell it won't help > e.g. IntelliJ IDEA one whit. If you're talking about more IDEs supporting Haskell, then having a more standard package format really won't help that much. Getting good and stable support there's a need for tools that can be called by IDEs. Building a Haskell project IDEs won't read the cabal file and call ghc, but they just call cabal. The same is the case for e.g. auto completion or any other IDE operation that needs to consider the whole project, the configuration and all of its dependencies. Reimplemeting cabals logic in every IDE doesn't make that much sense and at the end it won't work that well and it will easily break. From amindfv at gmail.com Sun Sep 18 11:45:24 2016 From: amindfv at gmail.com (Tom Murphy) Date: Sun, 18 Sep 2016 12:45:24 +0100 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <7c52b052-1f9f-45c6-1787-fe644222b59b@durchholz.org> References: <8737kza3x5.fsf@gnu.org> <7c52b052-1f9f-45c6-1787-fe644222b59b@durchholz.org> Message-ID: On Sat, Sep 17, 2016 at 7:27 AM, Joachim Durchholz wrote: > Am 17.09.2016 um 01:53 schrieb Harendra Kumar: > >> I agree. Supporting conditionals with YAML looks hacky! >> > > All I have seen was direct translation and conclusion that it doesn't work. > I haven't seen any attempts at making it look well. > > Also, while aesthetics isn't irrelevant, it's a pretty weak argument. > > Read the next paragraph in hvr's email: he was very much not talking about aesthetics. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sun Sep 18 12:03:38 2016 From: amindfv at gmail.com (Tom Murphy) Date: Sun, 18 Sep 2016 13:03:38 +0100 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: On Fri, Sep 16, 2016 at 4:35 PM, Imants Cekusins wrote: > > Would cabal-install need to link in all these maintained libraries > statically? Or would there be some plug-in mechanism to load them on demand? > > well the libraries would need to be official and some with the packager.​ > > the formats would be perfectly interchangeable i.e. > cabal -> standard_type -> yaml -> standard_type -> json -> standard_type > -> cabal > would produce the same cabal file > > only 1 config file per package to avoid confusion > > however if the user prefers working with format F, they can always convert > the format which came with the package, to F > > Even just looking at the set of features which is 1:1 betw. YAML and JSON, we're essentially just talking about key-value pairs with a couple of common types for the values. This isn't all .cabal files contain (e.g. see hvr's points about conditionals), but if it were true, is it really worth changing how Cabal works for a diffferent color bikeshed? On Sat, Sep 17, 2016 at 8:06 AM, Imants Cekusins wrote: > > Do I have to obtain whatever whizzy new controller you've come up with > in order to work with your packages? > > Do I have to do this when everyone has come up with their own whizzy new > controller and I need to fit their packages into whatever I am trying to > write? > ​ > that's the while point. If we could agree on a standard serializeable > model, each controller would ensure the link between the *view* and the > *model.* > > user could open a package in any IDE / environment. The environment's > controller would display the model in its own / user preferred view. > > Why not have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else? In general, though, I don't think the fragmentation is worth it. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Sun Sep 18 13:07:51 2016 From: gale at sefer.org (Yitzchak Gale) Date: Sun, 18 Sep 2016 16:07:51 +0300 Subject: [Haskell-cafe] implement SOAP-based standard In-Reply-To: <1929673648.534350.4ce9504f-c583-409b-9935-4ed9cb0048ce.open-xchange@webmail.strato.de> References: <1929673648.534350.4ce9504f-c583-409b-9935-4ed9cb0048ce.open-xchange@webmail.strato.de> Message-ID: When we come across a SOAP-based service we must provide or use, our approach is to use a REST-based wrapper. So far we have always been able to find existing solutions. For example, for SAML, there are services that already provide a REST-base wrapper for SAML-based identity providers, such as StormPath, Ping, and Shibboleth. If we didn't find an existing solution for some SOAP service, we would probably write our own REST wrapper in C# or Java and use that. Hope this helps, Yitz On Fri, Sep 16, 2016 at 5:43 PM, Olaf Klinke wrote: > Dear Haskellers, > > I am considering implementing the OPC XML DA standard [1] in Haskell. OPC XML DA > is based on SOAP and is used for communicating with servers controlling hardware > such as power plants. Currently the only open implementation known to me is > PyOPC [2], which is based on an outdated Python libraries. However, Python seems > not the nicest language for writing code that is devoid of bugs showing at > runtime only. The OPC XML DA standard comes with a WSDL document (600 lines). > There is a wsdl package on hackage, but it is incomplete. > Can anyone share experience in implementing a webservice specified as WSDL? > Actually, the client side would be enough for my purposes. That is, compose > well-formed messages and parse the responses. > > Thanks, > Olaf > > [1] > https://opcfoundation.org/developer-tools/specifications-classic/xml-data-access/ > [2] https://libraries.io/pypi/PyOPC > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From imantc at gmail.com Sun Sep 18 14:27:31 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sun, 18 Sep 2016 16:27:31 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: here are some charts to highlight differences between - currently used text based config and - suggested model based config -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sun Sep 18 15:40:11 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sun, 18 Sep 2016 17:40:11 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: > Why not have .cabal files be the standard model, and anyone can write tools on top to translate to/from .cabal if users really want to use something else? ​ .cabal file is representation rather than a model. It is parsed to model. Being a distinct file type with its own AST, it needs quite a bit of attention. It needs to be parsed, updated, validated, formatted. Another config format emerged. More problems (distinct file type etc). More formats may follow. Is there hope to agree on common format (as per thread title), if common content can not be agreed on? Isn't config first of all about content? Is the common format going to contain incompatible / conflicting data items? With common content, display format will not matter at all, neither will package tool nor IDE used to work on a project. Config being a Haskell type, it would be well formed. The options would be well known. Users and IDE devs will not need to worry about indenting, commas, line breaks and other *goodies*. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Sep 18 16:58:45 2016 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 18 Sep 2016 18:58:45 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: 2016-09-18 17:40 GMT+02:00 Imants Cekusins : > .cabal file is representation rather than a model. It is parsed to model. > Well, that's the case for basically everything you give to a program, so I don't see the point here. A .hs file is e.g. just a textual representation of the more abstract notion of a Haskell program/module, too. A .cabal file is just a textual representation of a the abstract notion of a Haskell package description. > Being a distinct file type with its own AST, > Distinct from what? > it needs quite a bit of attention. > >From whom? > It needs to be parsed, updated, validated, formatted. > This will be the case for whatever is being used, so again: What's the point? It doesn't matter if it's in its own .cabal syntax, in some Haskell-like syntax, JSON, YAML, or even some graphical representation. > Another config format emerged. > I'm not sure what config format is meant here. If it's stack.yaml, it *must* be somehow different (even if we ignore the surface syntax), because it describes a project, not a single package. > More problems (distinct file type etc). > What are the actual problems here? > More formats may follow. > If they are for different purposes, that's OK and is to be expected. > Is there hope to agree on common format (as per thread title), if common > content can not be agreed on? Isn't config first of all about content? Is > the common format going to contain incompatible / conflicting data items? > .cabal files describe "how a package looks like" and a stack.yaml describes "how to build a project in a reproducable way", which are different (although related) things. What should "common" mean here? > With common content, display format will not matter at all, neither will > package tool nor IDE used to work on a project. > > Config being a Haskell type, it would be well formed. The options would be > well known. > > Users and IDE devs will not need to worry about indenting, commas, line > breaks and other *goodies*. > Somehow you will always need a concrete representation of abstract notions (call them "models", "ASTs", etc.), otherwise you won't be able to process them. So you will always need to care about some kind of syntax etc., I can't see how using a "Haskell type" will help here. And you will need some semantics for the representation. Even if we used e.g. JSON (or whatever is en vogue at the moment), IDEs will not magically start understanding and supporting Haskell projects. Again: What is the actual problem we're trying to solve? I still haven't seen a concrete use case which is hard/impossible with the current state of affairs. Personally, I would e.g. like to see some abstraction facilities to avoid repetition in .cabal files with lots of executables, but I don't care about the concrete syntax (and Cabal's internal model/AST wouldn't be affected, either). -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Sun Sep 18 17:38:06 2016 From: imantc at gmail.com (Imants Cekusins) Date: Sun, 18 Sep 2016 19:38:06 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: > Well, that's the case for basically everything you give to a program, so I don't see the point here. A .hs file is e.g. just a textual representation of the more abstract notion of a Haskell program/module, too. A .cabal file is just a textual representation of a the abstract notion of a Haskell package description. yes, .hs AST etc must be implemented. However implementing cabal in addition to that is more work. > Distinct from what? from .hs. > [attention] From whom? IDE devs >> It needs to be parsed, updated, validated, formatted. > This will be the case for whatever is being used, so again: What's the point? It doesn't matter if it's in its own .cabal syntax, in some Haskell-like syntax, JSON, YAML, or even some graphical representation. if serialized model is used, then parsing, update, validation, formatting are no longer necessary I'm not sure what config format is meant here. If it's stack.yaml, it > *must* be somehow different (even if we ignore the surface syntax), because > it describes a project, not a single package. > What standard package format are we trying to agree then? > > >> More problems (distinct file type etc). >> > > What are the actual problems here? > implementing each new file type in IDE is a lot of work. That is, if IDE is trying to do anything with contents of that file. Such as support syncing renamed file to config. > > >> More formats may follow. >> > > If they are for different purposes, that's OK and is to be expected. > Each new format would need to be implemented. Time spent on implementing new formats is time not spent on implementing any other features. It may take nearly as long as implementing .hs support itself. Is this even thought about? If this may be avoided, why not at least consider this as an option? > .cabal files describe "how a package looks like" and a stack.yaml > describes "how to build a project in a reproducable way", which are > different (although related) things. What should "common" mean here? > Standard package file format (as the thread is called). Isn't it about cabal and yaml? Anyway, can not a common config file be used for both purposes? If not, can common file type / model be used for both purposes - sharing the common parts of the type structure? > Somehow you will always need a concrete representation of abstract notions > (call them "models", "ASTs", etc.), otherwise you won't be able to process > them. So you will always need to care about some kind of syntax etc., I > can't see how using a "Haskell type" will help here. And you will need some > semantics for the representation. Even if we used e.g. JSON (or whatever is > en vogue at the moment), IDEs will not magically start understanding and > supporting Haskell projects. > > well if config is expressed in terms of Haskell syntax, implemented .hs support will be enough to support editing these config files. Each file type (including .cabal) takes time to implement. > Again: What is the actual problem we're trying to solve? I still haven't > seen a concrete use case which is hard/impossible with the current state of > affairs. Personally, I would e.g. like to see some abstraction facilities > to avoid repetition in .cabal files with lots of executables, but I don't > care about the concrete syntax (and Cabal's internal model/AST wouldn't be > affected, either). > adopting standard package file format. Which could be addressed even better by adopting typed standard config content. the problems as I see them are: - users need to learn .cabal (.yaml, ...) syntax in addition to .hs syntax - IDE need to implement each such syntax on top of .hs. That is, if support / sync of these configs to code files is expected. Am I the only one who sees these as issues that need / can be solved? Also maybe let's be more specific: what is this thread - *Standard package file format* - all about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Sep 18 18:39:48 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 18 Sep 2016 20:39:48 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: <40e6a83a-7c1a-26c7-6106-16d8481a1f0f@durchholz.org> Am 18.09.2016 um 14:03 schrieb Tom Murphy: > Even just looking at the set of features which is 1:1 betw. YAML and JSON, > we're essentially just talking about key-value pairs with a couple of > common types for the values. This is just as correct as saying that Haskell is about functions - i.e. superficially correct but mostly beside the point. For JSON, it's string-to-whatever maps, arrays, and primitive types. For YAML, it's string-to-whatever maps, arrays, primitive types, references (so you can have shared and circular data structures), and arbitrary types (it will use constructors to deserialize). > This isn't all .cabal files contain (e.g. see > hvr's points about conditionals), but if it were true, is it really worth > changing how Cabal works for a diffferent color bikeshed? It's bikeshedding if and only if interoperability is irrelevant. However, in today's world, rejecting interoperability is insanity. So: no bikeshedding, there are real issues. It's still quite possible that it's simply not worth it; the cons associated with changing the buildfile format are pretty weighty after all, and if the Cabal people say they can fix the known problems with that format, it's probably a better idea to see what comes of that before pursuing alternate formats. From svenpanne at gmail.com Sun Sep 18 19:38:38 2016 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 18 Sep 2016 21:38:38 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <8737kza3x5.fsf@gnu.org> Message-ID: 2016-09-18 19:38 GMT+02:00 Imants Cekusins : > yes, .hs AST etc must be implemented. > If we're talking about a Haskell tool, it *is* already implemented: Just look into the Cabal project on github. If we're not talking about a Haskell tool and something outside the cabal/hackage/stackage ecosystem, writing an AST and a parser for it will be the least of your problems: The main problem will be how to map cabal's/stack's view what is a package/project to your tool's view. I don't think there's an universally agreed upon notion of what is a package or project, almost every IDE out there has its own view of what those mean, each with its pros and cons (which may be heavily influenced by the package/project programming language, not the language in which the IDE is written). > However implementing cabal in addition to that is more work. > Are we talking about parsing/printing here? If yes, there's already work in that direction (making the frontend, i.e. parser/printer/AST, a separate library), at least that's what I understood so far. > > Distinct from what? > from .hs. > And that's perfectly fine: A project/package description is something fundamentally different than a turing-complete general-purpose programming language. A project/package description should be a mostly static, declarative thing, perhaps with a few conditionals and/or (hygienic) macros or such for convenience/brevity, but not something which can calculate fibonacci numbers or solve differential equations. > > [attention] From whom? > IDE devs > Hmmm, so parsing some package/project description is a problem when writing an IDE? I highly doubt that this is relevant compared to the amount of work needed for an average IDE. > >> It needs to be parsed, updated, validated, formatted. > > This will be the case for whatever is being used, so again: What's the > point? It doesn't matter if it's in its own .cabal syntax, in some > Haskell-like syntax, JSON, YAML, or even some graphical representation. > > if serialized model is used, > then parsing, update, validation, formatting are no longer necessary > Huh? What's a "serialized model" then? Whatever you do, you have to parse/validate/... any description. Even if you choose some subset of Haskell (which is probably a bad idea IMHO because it's either too general or not really Haskell anymore), there has to be *some* parser etc. Where should that come from? Neither Emacs nor VIM can e.g. parse/print Haskell out of the box, VS probably can't either. > > I'm not sure what config format is meant here. If it's stack.yaml, it >> *must* be somehow different (even if we ignore the surface syntax), because >> it describes a project, not a single package. >> > > What standard package format are we trying to agree then? > stack.yaml is not a "package format", so there is nothing to agree on. > More problems (distinct file type etc). >>> >> >> What are the actual problems here? >> > > implementing each new file type in IDE is a lot of work. That is, if IDE > is trying to do anything with contents of that file. Such as support > syncing renamed file to config. > > >> >> >>> More formats may follow. >>> >> >> If they are for different purposes, that's OK and is to be expected. >> > > Each new format would need to be implemented. Time spent on implementing > new formats is time not spent on implementing any other features. It may > take nearly as long as implementing .hs support itself. Is this even > thought about? > stack.yaml is not .cabal in a new syntax, there is new functionality. Even if both were e.g. written in YAML, your shiny hypothetical IDE wouldn't suddenly support reproducible multi-package builds out of the box if it couldn't do so before. > > If this may be avoided, why not at least consider this as an option? > > >> .cabal files describe "how a package looks like" and a stack.yaml >> describes "how to build a project in a reproducable way", which are >> different (although related) things. What should "common" mean here? >> > > > Standard package file format (as the thread is called). Isn't it about > cabal and yaml? > If we are really only talking about a *package* format, there is currently only .cabal and a single format is by definition "standard". :-) > well if config is expressed in terms of Haskell syntax, implemented .hs > support will be enough to support editing these config files. > Each file type (including .cabal) takes time to implement. > Again: Where is that ominous ".hs support" coming from? > the problems as I see them are: > > - users need to learn .cabal (.yaml, ...) syntax in addition to .hs > syntax > > As has already been mentioned by others, I *highly* doubt that the .cabal syntax itself poses the slightest problem for anyone. The semantics are a different story, but you have to learn them anyway. > > - IDE need to implement each such syntax on top of .hs. That is, if > support / sync of these configs to code files is expected. > > You just update your internal view of the package/project and write out the changed part. With library support for .cabal and YAML files that's trivial. Am I the only one who sees these as issues that need / can be solved? > > Also maybe let's be more specific: what is this thread - *Standard > package file format* - all about? > That's the central question IMHO. :-) The current discussion seems to drift towards: Do we need the current package/project dichotomy or can we throw everything together? (Note that e.g. Visual Studio distinguishes projects and solutions, too, perhaps there's a reason for that?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Sun Sep 18 23:22:03 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 19 Sep 2016 11:22:03 +1200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <2e4de9b3-f4a4-c245-d4ee-58b44e660c89@cs.otago.ac.nz> YAML and TOML are not, strictly speaking, package file formats. They are *meta-formats*. There is, by design, nothing about them that ties them in any way to any kind of package system. That means that other, even more popular, meta-formats should be considered. In particular, while XML and JSON are not by any means *wonderful*, they are far better known than TOML or even YAML. On 16/09/16 6:20 PM, Harendra Kumar wrote: > From a developer's perspective, the major benefit of a standard and > widely adopted format and is that people can utilize their knowledge > acquired from elsewhere, they do not have to go through and learn > differently looking and incomplete documentation of different tools. The > benefit of a common config specification is that developers can choose > tools freely without worrying about learning the same concepts presented > in different ways. If we are talking about *meta-formats*, this is only half true. No amount of knowledge about YAML per se will tell you how to use YAML to describe Haskell packages. Nor will it let you choose tools freely if what you want is tools that understand your *package file format* specifically. (For example, editors that can drop in handy templates, or validate a description.) > * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A > significant chunk of developer community is already familiar with it. It > is being used by stack and by hpack as an alternative to cabal format. > The complaint against it is that the specification/implementation is > overly complex. It's not clear what "standard" means in this context. yaml.org *calls* it "standard", but as the joke puts it, "CALLING a tail a leg doesn't MAKE it a leg." XML is a standard: it's managed by a well-known body. JSON is both an ECMA standard and an Internet RFC. There are other complaints: - that there is no *other* reason for most Haskell programmers to be aware of YAML, - that stack and hpack do not use "YAML" but an underspecified subset of YAML, and that - that due to YAML's complexity different implementations tend to implement different subsets, meaning less interoperability than you'd expect, - that the Ruby documentation for its YAML module http://ruby-doc.org/stdlib-1.9.3/libdoc/yaml/rdoc/YAML.html says "Do not use YAML to load untrusted data. Doing so is unsafe and could allow malicious input to execute arbitrary code inside your application." I must admit I'm surprised. - ... Could I respectfully suggest that the first step in a project like this is to describe the *semantics* of your package management information in a language-neutral way? I know a great language for describing abstract data types and giving them semantics. It's named for some logician, I think his surname was Curry. (:-) Seriously, there seems to be an endemic problem with programmers racing to syntax without thinking over-much about semantics. It happened with XML. It happened again with RDF. Eventually the semantics gets patched up, after pointless pain and suffering. Having nutted out exactly what the issues are with the semantics, then you can experiment with syntax. From ok at cs.otago.ac.nz Mon Sep 19 00:12:04 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 19 Sep 2016 12:12:04 +1200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: On 16/09/16 6:37 PM, Tobias Dammers wrote: > Another factor in favor of YAML is that it is a superset of JSON, Here is a simple string in JSON: "Where's the Golden Fleece?" Here is the same string in YAML: --- Where's the Golden Fleece? ... Superset? I understand "language X is a superset of language Y" to mean that if I have a document in language Y it can be correctly processed by a language X processor. If you mean that any data value that can be represented in JSON can be represented (differently!) in YAML, fine, but that's not the same thing. There are many textual formats that generalise JSON. Heck, even GNUSTEP Property List format does *that*. (And no, I do not recommend adopting that for anything.) For that matter, any JSON document can be transcoded with no loss of structural information into XML and vice versa. That doesn't mean that JSON is a superset of XML! Familiarity with JSON semantics and syntax did not help me AT ALL when faced with YAML. Here's another meta-format worthy of consideration. A *package* is a collection of resources with relationships between them and relationships linking them to other things like authors (think Dublin Core). Is there a standard (genuinely standard) notation specifically for describing resources and their relationships, with quite a few tools for not just reading it and writing it but actually reasoning with it? Why yes. It's called RDF. http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/ The design of RDF is intended to meet the following goals: * having a simple data model * having formal semantics and provable inference * using an extensible URI-based vocabulary * using an XML-based syntax * supporting use of XML schema datatypes * allowing anyone to make statements about any resource There is a human-friendly syntax interconvertible with the XML one, Turtle. http://www.w3.org/TR/turtle/ Now RDF (whether XML or Turtle) is *not* designed for presenting single data values. But that's not really what a package format wants to do anyway. Am I seriously recommending RDF (or possibly OWL-DL) as a good way to describe packages? I am certainly serious that it should be CONSIDERED. And I'm particularly serious about that for two reasons. (1) JSON, XML, TOML, and YAML are all about serialising *data values*. That's all they do. Anything beyond that is up to you. RDF and OWL are all about describing *relationships* between *resources*. It's worth considering carefully what you want to say in a package file format. If you want to describe *relationships*, then something that deals with data values may not be the right *kind* of "language". Simply jarring people loose from the idea that a "single possibly structured data value" language is the ONLY kind of language is of value in itself. (2) JSON, XML, TOML, and YAML are all about serialising *data values*. *Single* possibly structured data values. That's all they do. There is no sense in which there is any standard way to *combine* data in these forms. In contrast, RDF was *invented* to have a way of patching together multiple sets of facts from multiple sources. Given a collection of package descriptions in YAML, all you have is a bunch of text files; what you do with them is *entirely* up to you. Given a bunch of RDF/XML or RDF/Turtle files, there is a *standard* way to write a query (SPARQL) which integrates them. It becomes possible to write consistency-checking queries that can be processed by multiple tools. It becomes possible to ask "if I need these, what else do I need?" in a standard way. Again, the idea here is to get people thinking that having a documented semantics that can be processed by existing description logic tools has value, so that something at a higher semantic level than YAML or XML might be worth thinking about. From ok at cs.otago.ac.nz Mon Sep 19 00:27:17 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 19 Sep 2016 12:27:17 +1200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <87intva4nt.fsf@gnu.org> Message-ID: On 17/09/16 4:47 PM, Bardur Arantsson wrote: >> > I was actually curious about this, and it's interesting to note that > even JSON which was supposed to have *ONE STANDARD* now apparently has > two, an ECMA one and and IETF RFC (seems to be more recent). It's a long sad story. The ECMA standard exists for largely politcal reasons. The RFC is the "active" one. JSON is a textbook example of "syntax-first". From monkleyon at googlemail.com Mon Sep 19 03:27:17 2016 From: monkleyon at googlemail.com (MarLinn) Date: Mon, 19 Sep 2016 05:27:17 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: <11b43486-9f50-afc9-cb8d-d1afa5f1af60@gmail.com> An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Mon Sep 19 03:55:33 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 18 Sep 2016 22:55:33 -0500 Subject: [Haskell-cafe] Standard package file format In-Reply-To: <11b43486-9f50-afc9-cb8d-d1afa5f1af60@gmail.com> References: <11b43486-9f50-afc9-cb8d-d1afa5f1af60@gmail.com> Message-ID: While y'all are going 'round about this, an argument parser in Rust has its own blog, api docs, twitter account, github, and tutorial videos. https://clap.rs/ And it supports YAML in addition to plain old Rust code. From ok at cs.otago.ac.nz Mon Sep 19 05:15:38 2016 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Mon, 19 Sep 2016 17:15:38 +1200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: <11b43486-9f50-afc9-cb8d-d1afa5f1af60@gmail.com> Message-ID: <18c3863795505d95696537a3c322a36d.squirrel@chasm.otago.ac.nz> > While y'all are going 'round about this, an argument parser in Rust > has its own blog, api docs, twitter account, github, and tutorial > videos. > > https://clap.rs/ An *argument parser*? Visits web page incredulously. Great balls of fire, it's true. I really don't want to use an argument parser that requires that much documentation. Life is too short. From jo at durchholz.org Mon Sep 19 07:21:50 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 19 Sep 2016 09:21:50 +0200 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: Am 19.09.2016 um 02:12 schrieb Richard A. O'Keefe: > > > On 16/09/16 6:37 PM, Tobias Dammers wrote: >> Another factor in favor of YAML is that it is a superset of JSON, > > Here is a simple string in JSON: > > "Where's the Golden Fleece?" > > Here is the same string in YAML: > > --- Where's the Golden Fleece? > ... > > Superset? Yes. The original string is also valid in YAML if used in the position where JSON allows a string. > If you mean that any data value that can be represented in JSON > can be represented (differently!) in YAML, fine, but that's not > the same thing. Sure, but any valid JSON is also valid YAML. Modulo some exotic exceptions for valid-but-useless and valid-but-probably-not-what-the-sender-intended JSON. > Familiarity with JSON semantics and syntax did not help me AT ALL > when faced with YAML. Sure, YAML is a massive superset. The advantage is more in interoperability - you can hook a YAML parser to JSON-outputting processes and expect that it will "just work", so you don't have to worry about syntax, so you don't need separate frontends for YAML and JSON for your webservice. > Am I seriously recommending RDF (or possibly OWL-DL) as a good > way to describe packages? I am certainly serious that it should > be CONSIDERED. +1 > (1) JSON, XML, TOML, and YAML are all about serialising *data values*. > That's all they do. Anything beyond that is up to you. > RDF and OWL are all about describing *relationships* between > *resources*. It's worth considering carefully what you want to > say in a package file format. If you want to describe > *relationships*, then something that deals with data values may > not be the right *kind* of "language". > > Simply jarring people loose from the idea that a "single possibly > structured data value" language is the ONLY kind of language is > of value in itself. It does have its advantages. That's why everybody is using XML these days, after all. Even though XML does have some pretty horrible properties (too much noise being the most prominent). > (2) JSON, XML, TOML, and YAML are all about serialising *data values*. > *Single* possibly structured data values. > That's all they do. There is no sense in which there is any > standard way to *combine* data in these forms. Yes, that's supposed to live at the semantic level, i.e. in the types. For JSON and TOML that's a serious restriction. In XML and YAML, you can keep type information (better standardization for that in YAML than in XML), so you can stick user-defined semantics into the serialization format if you want to. I.e. you can achieve RDF in XML or YAML by writing types that handle combinability or anything else that you want, these things aren't tied into the language. It is still possible that RDF is more convenient :-) From qdunkan at gmail.com Tue Sep 20 18:25:15 2016 From: qdunkan at gmail.com (Evan Laforge) Date: Tue, 20 Sep 2016 11:25:15 -0700 Subject: [Haskell-cafe] Standard package file format In-Reply-To: References: Message-ID: I haven't totally followed this whole thread, so apologies if this isn't entirely relevant, but I use shake for building, and cabal for dependencies. The shakefile has the list of packages and required versions, and generates the .cabal file, which is used with --only-dependencies to get dependencies. I think it works well. I can't do builds in cabal anyway since it can't handle anything complicated, but even if I had a simple build I'd prefer shake since it's so much nicer. Since it's in haskell, it's flexible but can't be analyzed, though I can't think of why you'd want to analyze it. Meanwhile, cabal is just fine at expressing packages and versions, and is basically just a way to tell cabal-install what to download and install. Since I generate it, I don't care much about the format, but the existing one seems perfectly adequate. From tobias.grosser at inf.ethz.ch Wed Sep 21 14:02:01 2016 From: tobias.grosser at inf.ethz.ch (Tobias Grosser) Date: Wed, 21 Sep 2016 16:02:01 +0200 Subject: [Haskell-cafe] PLDI 2017 call for papers Message-ID: <1474466521.3026399.732628401.50FAD4F8@webmail.messagingengine.com> *Call for Contributions* ==================== 2017 ACM Conference on Programming Language Design and Implementation (PLDI) June 19-23, 2017 in Barcelona, Spain http://conf.researchr.org/home/pldi-2017 PLDI is the premier forum in the field of programming languages and programming systems research, covering the areas of design implementation, theory, applications, and performance. PLDI welcomes outstanding research which clearly advances the field and has the potential to make a lasting contribution. *Important Dates* =============== Research paper submissions due 15 Nov 2016 Author response period 26-28 Jan 2017 Author notification 13 Feb 2017 *Author Instructions* ================== http://conf.researchr.org/track/pldi-2017/pldi-2017-papers Submission site: https://pldi17.hotcrp.com/ *Organizing Committee* ==================== General Chair: Albert Cohen, INRIA, France Program Chair: Martin Vechev, ETH Zurich, Switzerland Workshops & Tutorials Chair: Aaron Smith, University of Edinburgh Publicity Chairs: Adrian Sampson, Cornell, USA Tobias Grosser, ETH Zurich, Switzerland http://conf.researchr.org/committee/pldi-2017/pldi-2017-organizing-committee -- Tobias Grosser From codygman.consulting at gmail.com Thu Sep 22 00:23:58 2016 From: codygman.consulting at gmail.com (Cody Goodman) Date: Wed, 21 Sep 2016 19:23:58 -0500 Subject: [Haskell-cafe] Debugging hanging template Haskell In-Reply-To: References: Message-ID: Can you use the ghci debugger to do this? I tried adding a piece of template Haskell to the frames library and now compilation never terminates: https://github.com/acowley/Frames/pull/59 One compiler warning warned me of overlapping instances in relation to my ZonedTime lift instance which could totally be wrong. I have a feeling maybe the overlapping instances could be making compilation hang, but I'm not sure. I'm more looking for help on how to move forward and keep debugging this than an answer, but if you only have time for an answer I'll gladly do the reverse engineering work to teach myself. Thanks all! -------------- next part -------------- An HTML attachment was scrubbed... URL: From defigueiredo at ucdavis.edu Thu Sep 22 23:26:36 2016 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Thu, 22 Sep 2016 17:26:36 -0600 Subject: [Haskell-cafe] The meaning of categories constructed from HASK In-Reply-To: References: Message-ID: <36383e22-0b32-426d-7c9f-5e611bbca233@ucdavis.edu> In category theory, there are many ways one can make new categories out of an old one. In particular, given a category C one can construct: 1. The arrows category of C: arrows in C become objects and commutative squares in C become arrows 2. The slice category of C given an object A: arrows into a distinguished object A become objects in the slice commutative triangles become arrows There are also functors going from C to these new categories (and back). Are these constructed categories useful when C = `Hask` (the category of haskell types and functions)? What do they represent in programming terms? In other words, is there intuition for what the arrows category of Hask is? What about the slice category of Hask over a specific type? Do the functors between these match some programming abstractions? Any pointers are much appreciated. Thanks, Dimitri From amindfv at gmail.com Thu Sep 22 23:39:10 2016 From: amindfv at gmail.com (Tom Murphy) Date: Fri, 23 Sep 2016 08:39:10 +0900 Subject: [Haskell-cafe] MPTCs and extended defaulting In-Reply-To: References: Message-ID: Bump -- is this feasible? It would be extremely helpful for an EDSL of mine. Tom On Tue, Aug 30, 2016 at 5:23 AM, Tom Murphy wrote: > I've got a case in a library I'm working on where having > -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it > possible? > > I.e., we can now write: > > ``` > {-# LANGUAGE ExtendedDefaultRules #-} > > data AB = A | B Double deriving (Show) > > class Foo x where > foo :: x -> AB > > instance Foo Double where > foo = B > > main = print $ foo 5 > ``` > > And -XExtendedDefaultRules makes sure we don't need to write "5 :: Double" > > > If, though, I want 'Foo' to take another parameter (here, a :: [Symbol]), > it falls apart: > > ``` > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExtendedDefaultRules #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE MultiParamTypeClasses #-} > > import GHC.TypeLits > > data AB = A | B Double deriving (Show) > > class Foo x (a :: [Symbol]) where > foo :: x -> AB > > instance Foo Double a where > foo = B > > main = print $ foo 5 > ``` > > Is there a reason MPTCs can't support ExtendedDefaultRules? > > Thanks! > Tom > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Thu Sep 22 23:56:33 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 22 Sep 2016 18:56:33 -0500 Subject: [Haskell-cafe] MPTCs and extended defaulting In-Reply-To: References: Message-ID: {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} import GHC.TypeLits data AB = A | B Double deriving (Show) class Foo x (a :: [Symbol]) where foo :: x -> AB instance (b ~ Double) => Foo b a where foo = B main = print $ foo 5 On Thu, Sep 22, 2016 at 6:39 PM, Tom Murphy wrote: > Bump -- is this feasible? It would be extremely helpful for an EDSL of mine. > > Tom > > On Tue, Aug 30, 2016 at 5:23 AM, Tom Murphy wrote: >> >> I've got a case in a library I'm working on where having >> -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it >> possible? >> >> I.e., we can now write: >> >> ``` >> {-# LANGUAGE ExtendedDefaultRules #-} >> >> data AB = A | B Double deriving (Show) >> >> class Foo x where >> foo :: x -> AB >> >> instance Foo Double where >> foo = B >> >> main = print $ foo 5 >> ``` >> >> And -XExtendedDefaultRules makes sure we don't need to write "5 :: Double" >> >> >> If, though, I want 'Foo' to take another parameter (here, a :: [Symbol]), >> it falls apart: >> >> ``` >> {-# LANGUAGE DataKinds #-} >> {-# LANGUAGE ExtendedDefaultRules #-} >> {-# LANGUAGE KindSignatures #-} >> {-# LANGUAGE MultiParamTypeClasses #-} >> >> import GHC.TypeLits >> >> data AB = A | B Double deriving (Show) >> >> class Foo x (a :: [Symbol]) where >> foo :: x -> AB >> >> instance Foo Double a where >> foo = B >> >> main = print $ foo 5 >> ``` >> >> Is there a reason MPTCs can't support ExtendedDefaultRules? >> >> Thanks! >> Tom >> >> >> >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From amindfv at gmail.com Fri Sep 23 00:15:05 2016 From: amindfv at gmail.com (Tom Murphy) Date: Fri, 23 Sep 2016 09:15:05 +0900 Subject: [Haskell-cafe] MPTCs and extended defaulting In-Reply-To: References: Message-ID: With GHC 8.0.1 I get a type error: error: • Could not deduce (Foo x a0) from the context: Foo x a bound by the type signature for: foo :: Foo x a => x -> AB On Fri, Sep 23, 2016 at 8:56 AM, Christopher Allen wrote: > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExtendedDefaultRules #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies #-} > > import GHC.TypeLits > > data AB = A | B Double deriving (Show) > > class Foo x (a :: [Symbol]) where > foo :: x -> AB > > instance (b ~ Double) => Foo b a where > foo = B > > main = print $ foo 5 > > On Thu, Sep 22, 2016 at 6:39 PM, Tom Murphy wrote: > > Bump -- is this feasible? It would be extremely helpful for an EDSL of > mine. > > > > Tom > > > > On Tue, Aug 30, 2016 at 5:23 AM, Tom Murphy wrote: > >> > >> I've got a case in a library I'm working on where having > >> -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it > >> possible? > >> > >> I.e., we can now write: > >> > >> ``` > >> {-# LANGUAGE ExtendedDefaultRules #-} > >> > >> data AB = A | B Double deriving (Show) > >> > >> class Foo x where > >> foo :: x -> AB > >> > >> instance Foo Double where > >> foo = B > >> > >> main = print $ foo 5 > >> ``` > >> > >> And -XExtendedDefaultRules makes sure we don't need to write "5 :: > Double" > >> > >> > >> If, though, I want 'Foo' to take another parameter (here, a :: > [Symbol]), > >> it falls apart: > >> > >> ``` > >> {-# LANGUAGE DataKinds #-} > >> {-# LANGUAGE ExtendedDefaultRules #-} > >> {-# LANGUAGE KindSignatures #-} > >> {-# LANGUAGE MultiParamTypeClasses #-} > >> > >> import GHC.TypeLits > >> > >> data AB = A | B Double deriving (Show) > >> > >> class Foo x (a :: [Symbol]) where > >> foo :: x -> AB > >> > >> instance Foo Double a where > >> foo = B > >> > >> main = print $ foo 5 > >> ``` > >> > >> Is there a reason MPTCs can't support ExtendedDefaultRules? > >> > >> Thanks! > >> Tom > >> > >> > >> > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Chris Allen > Currently working on http://haskellbook.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Fri Sep 23 00:17:44 2016 From: amindfv at gmail.com (Tom Murphy) Date: Fri, 23 Sep 2016 09:17:44 +0900 Subject: [Haskell-cafe] MPTCs and extended defaulting In-Reply-To: References: Message-ID: Ah, looks like that's unrelated to the original issue, though -- thanks! Tom On Fri, Sep 23, 2016 at 9:15 AM, Tom Murphy wrote: > With GHC 8.0.1 I get a type error: > > error: > • Could not deduce (Foo x a0) > from the context: Foo x a > bound by the type signature for: > foo :: Foo x a => x -> AB > > > On Fri, Sep 23, 2016 at 8:56 AM, Christopher Allen > wrote: > >> {-# LANGUAGE DataKinds #-} >> {-# LANGUAGE ExtendedDefaultRules #-} >> {-# LANGUAGE FlexibleInstances #-} >> {-# LANGUAGE KindSignatures #-} >> {-# LANGUAGE MultiParamTypeClasses #-} >> {-# LANGUAGE TypeFamilies #-} >> >> import GHC.TypeLits >> >> data AB = A | B Double deriving (Show) >> >> class Foo x (a :: [Symbol]) where >> foo :: x -> AB >> >> instance (b ~ Double) => Foo b a where >> foo = B >> >> main = print $ foo 5 >> >> On Thu, Sep 22, 2016 at 6:39 PM, Tom Murphy wrote: >> > Bump -- is this feasible? It would be extremely helpful for an EDSL of >> mine. >> > >> > Tom >> > >> > On Tue, Aug 30, 2016 at 5:23 AM, Tom Murphy wrote: >> >> >> >> I've got a case in a library I'm working on where having >> >> -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it >> >> possible? >> >> >> >> I.e., we can now write: >> >> >> >> ``` >> >> {-# LANGUAGE ExtendedDefaultRules #-} >> >> >> >> data AB = A | B Double deriving (Show) >> >> >> >> class Foo x where >> >> foo :: x -> AB >> >> >> >> instance Foo Double where >> >> foo = B >> >> >> >> main = print $ foo 5 >> >> ``` >> >> >> >> And -XExtendedDefaultRules makes sure we don't need to write "5 :: >> Double" >> >> >> >> >> >> If, though, I want 'Foo' to take another parameter (here, a :: >> [Symbol]), >> >> it falls apart: >> >> >> >> ``` >> >> {-# LANGUAGE DataKinds #-} >> >> {-# LANGUAGE ExtendedDefaultRules #-} >> >> {-# LANGUAGE KindSignatures #-} >> >> {-# LANGUAGE MultiParamTypeClasses #-} >> >> >> >> import GHC.TypeLits >> >> >> >> data AB = A | B Double deriving (Show) >> >> >> >> class Foo x (a :: [Symbol]) where >> >> foo :: x -> AB >> >> >> >> instance Foo Double a where >> >> foo = B >> >> >> >> main = print $ foo 5 >> >> ``` >> >> >> >> Is there a reason MPTCs can't support ExtendedDefaultRules? >> >> >> >> Thanks! >> >> Tom >> >> >> >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Chris Allen >> Currently working on http://haskellbook.com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From handongwinter at didichuxing.com Fri Sep 23 02:47:41 2016 From: handongwinter at didichuxing.com (=?gb2312?B?uqu2rCi7+bShxr3MqLK/KQ==?=) Date: Fri, 23 Sep 2016 02:47:41 +0000 Subject: [Haskell-cafe] Announcing binary-parsers Message-ID: Hi all, I am happy to announce binary-parsers. A ByteString parsing library built on binary. I borrowed lots of design/tests/document from attoparsec so that i can build its shape very quickly, thank you bos! And thanks to binary's excellent design, the codebase is very small(<500 loc). From my benchmark, it’s insanely fast, it outperforms attoparsec by 10%~30% in aeson benchmark. it’s also slightly faster than scanner(a non-backtracking parser designed for speed) in http request benchmark. I’d like to ask you to give it a shot if you need super fast ByteString parsing. These parsers are just binary's Get monads, so you can seamlessly combine them with combinators from binary package. You can now write more complex Binary instances using comprehensive combinators, with serialisation packages like blaze-texual. all these goodies come for free! Happy hacking! Github: https://github.com/winterland1989/binary-parsers Hackage: http://hackage.haskell.org/package/binary-parsers Winterland -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Sep 23 05:50:51 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 23 Sep 2016 01:50:51 -0400 Subject: [Haskell-cafe] The meaning of categories constructed from HASK In-Reply-To: <36383e22-0b32-426d-7c9f-5e611bbca233@ucdavis.edu> References: <36383e22-0b32-426d-7c9f-5e611bbca233@ucdavis.edu> Message-ID: It's generally quite hard or impossible to express commutative diagrams as Haskell types since it's (currently) impossible to talk about term equality at the type level. I imagine someone who actually knows category theory can describe some ways they use such concepts to design or analyse Haskell code, though. On Sep 22, 2016 7:26 PM, "Dimitri DeFigueiredo" wrote: > In category theory, there are many ways one can make new categories out > of an old one. > > In particular, given a category C one can construct: > > 1. The arrows category of C: > arrows in C become objects and > commutative squares in C become arrows > 2. The slice category of C given an object A: > arrows into a distinguished object A become objects in the slice > commutative triangles become arrows > > There are also functors going from C to these new categories (and back). > > Are these constructed categories useful when C = `Hask` (the category of > haskell types and functions)? > What do they represent in programming terms? > > In other words, is there intuition for what the arrows category of Hask is? > What about the slice category of Hask over a specific type? > Do the functors between these match some programming abstractions? > > Any pointers are much appreciated. > > Thanks, > > Dimitri > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.stutterheim at me.com Fri Sep 23 09:09:42 2016 From: j.stutterheim at me.com (J. Stutterheim) Date: Fri, 23 Sep 2016 11:09:42 +0200 Subject: [Haskell-cafe] Understanding fgl's gfiltermap Message-ID: <1AB0675E-59BB-416C-8128-92B49F56FF42@me.com> Hi all, While playing with the fgl library [1] (git rev. 71b66d6), I encountered a situation where the library behaved different from what I expected. I now wonder whether I should adjust my expectations, or whether fgl has a bug. What I want to do is filter out nodes and edges based on edge labels. For a specific edge label l, if a node has an incoming or outgoing edge l it can stay, otherwise I want to remove it from my graph. Likewise, any edge that doesn't have label l needs to be removed from my graph. I wrote a program to do this using gfiltermap, but I got the wrong graph as a result. During debugging, I found that gfiltermap behaved differently from what I would expect. Take the following program: ```haskell {-# LANGUAGE TupleSections #-} module Test where import Debug.Trace import Data.Graph.Inductive main :: IO () main = prettyPrint test test :: Gr () () test = gfiltermap (Just . traceShowId) testGraph where {- - ASCII art representation of the graph: - - 1 <-4<-- 2 - /\ -/| - \ / - \3\/_ -} testGraph = mkGraph testNodes testEdges where testNodes = map (,()) [1, 2, 3, 4] testEdges = [ (2, 4, ()) , (4, 1, ()) , (2, 3, ()) , (3, 1, ()) , (3, 2, ()) ] ``` This simple program just reconstructs the original graph, but prints the contexts in the process. When it's done, it pretty prints the resulting graph. The debug tracing + pretty printing gives the following output (in that order): ([((),3),((),4)],1,(),[]) ([((),3)],2,(),[((),3),((),4)]) ([],3,(),[]) ([],4,(),[]) 1:()->[] 2:()->[((),3),((),4)] 3:()->[((),1),((),2)] 4:()->[((),1)] The pretty-printed graph correctly shows that there is an edges going from node 4 to node 1. However, the traced output shows node 4 (last line of trace output) with no successors and no predecessors. I would expect nodes 1 and 2 to be included in that tuple as the successor and predecessor in that tuple. Note that these two representations of the same graph _are_ isomorphic. Despite the isomorphism, this makes implementing my graph filter significantly more clumsy than I would like it to be. So my question is: are my expectations from the library wrong, or is this a bug? - Jurriën [1] https://hackage.haskell.org/package/fgl -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3117 bytes Desc: not available URL: From ivan.miljenovic at gmail.com Fri Sep 23 09:27:02 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 23 Sep 2016 18:27:02 +0900 Subject: [Haskell-cafe] Understanding fgl's gfiltermap In-Reply-To: <1AB0675E-59BB-416C-8128-92B49F56FF42@me.com> References: <1AB0675E-59BB-416C-8128-92B49F56FF42@me.com> Message-ID: On 23 September 2016 at 18:09, J. Stutterheim wrote: > Hi all, > > While playing with the fgl library [1] (git rev. 71b66d6), I encountered a situation where the library behaved different from what I expected. I now wonder whether I should adjust my expectations, or whether fgl has a bug. > > What I want to do is filter out nodes and edges based on edge labels. For a specific edge label l, if a node has an incoming or outgoing edge l it can stay, otherwise I want to remove it from my graph. Likewise, any edge that doesn't have label l needs to be removed from my graph. > > I wrote a program to do this using gfiltermap, but I got the wrong graph as a result. During debugging, I found that gfiltermap behaved differently from what I would expect. Take the following program: > > ```haskell > {-# LANGUAGE TupleSections #-} > > module Test where > > import Debug.Trace > import Data.Graph.Inductive > > main :: IO () > main = prettyPrint test > > test :: Gr () () > test = gfiltermap (Just . traceShowId) testGraph > where > {- > - ASCII art representation of the graph: > - > - 1 <-4<-- 2 > - /\ -/| > - \ / > - \3\/_ > -} > testGraph = mkGraph testNodes testEdges > where > testNodes = map (,()) [1, 2, 3, 4] > testEdges = [ (2, 4, ()) > , (4, 1, ()) > , (2, 3, ()) > , (3, 1, ()) > , (3, 2, ()) > ] > ``` > > This simple program just reconstructs the original graph, but prints the contexts in the process. When it's done, it pretty prints the resulting graph. The debug tracing + pretty printing gives the following output (in that order): > > ([((),3),((),4)],1,(),[]) > ([((),3)],2,(),[((),3),((),4)]) > ([],3,(),[]) > ([],4,(),[]) > > 1:()->[] > 2:()->[((),3),((),4)] > 3:()->[((),1),((),2)] > 4:()->[((),1)] > > The pretty-printed graph correctly shows that there is an edges going from node 4 to node 1. However, the traced output shows node 4 (last line of trace output) with no successors and no predecessors. I would expect nodes 1 and 2 to be included in that tuple as the successor and predecessor in that tuple. Note that these two representations of the same graph _are_ isomorphic. > > Despite the isomorphism, this makes implementing my graph filter significantly more clumsy than I would like it to be. So my question is: are my expectations from the library wrong, or is this a bug? This is how gfiltermap works: it deconstructs the graph inductively using matchAny. > > > - Jurriën > > > [1] https://hackage.haskell.org/package/fgl > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From chneukirchen at gmail.com Fri Sep 23 19:55:59 2016 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Fri, 23 Sep 2016 21:55:59 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2016-09-26 @ 19:30 Message-ID: <87mviytmpc.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 26 at *Max-Emanuel-Brauerei* at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2016/ *Please add yourself quickly so we can get enough places.* Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From mgsloan at gmail.com Sat Sep 24 00:54:34 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Fri, 23 Sep 2016 17:54:34 -0700 Subject: [Haskell-cafe] Debugging hanging template Haskell In-Reply-To: References: Message-ID: Hi! While not quite what you are looking for, I would suggest doing print debugging via Debug.Trace.trace or traceShow or traceShowId . If you make it print repeatedly, well, that's the bit that is hanging. -Michael On Wed, Sep 21, 2016 at 5:23 PM, Cody Goodman wrote: > Can you use the ghci debugger to do this? I tried adding a piece of template > Haskell to the frames library and now compilation never terminates: > > https://github.com/acowley/Frames/pull/59 > > One compiler warning warned me of overlapping instances in relation to my > ZonedTime lift instance which could totally be wrong. > > I have a feeling maybe the overlapping instances could be making compilation > hang, but I'm not sure. > > I'm more looking for help on how to move forward and keep debugging this > than an answer, but if you only have time for an answer I'll gladly do the > reverse engineering work to teach myself. > > Thanks all! > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jeffbrown.the at gmail.com Sat Sep 24 07:45:41 2016 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 24 Sep 2016 00:45:41 -0700 Subject: [Haskell-cafe] The 13-line example in Text.Megaparsec.Expr In-Reply-To: References: Message-ID: I'm trying this again! The comment for Megaparsec.makeExprParser refers to "parens". When I grep for "parens" in Megaparsec I get only two occurences, both of them in comments: ./Lexer.hs:-- > parens = between (symbol "(") (symbol ")") ./Expr.hs:-- > term = parens expr <|> integer "term" If I try defining parens as in the comment from Lexer.hs, I get these errors: :37:33: Couldn't match type ‘Char’ with ‘()’ Expected type: [()] Actual type: [Char] In the first argument of ‘symbol’, namely ‘"("’ In the first argument of ‘between’, namely ‘(symbol "(")’ In the expression: between (symbol "(") (symbol ")") :37:46: Couldn't match type ‘Char’ with ‘()’ Expected type: [()] Actual type: [Char] In the first argument of ‘symbol’, namely ‘")"’ In the second argument of ‘between’, namely ‘(symbol ")")’ In the expression: between (symbol "(") (symbol ")") [1] https://hackage.haskell.org/package/megaparsec-5.0.1/docs/Text-Megaparsec-Expr.html On Mon, Feb 29, 2016 at 2:05 AM, Özgür Akgün wrote: > > On 29 February 2016 at 08:22, Stephen Tetley > wrote: > >> >> For the expression parser, Megaparsec's documentation is wrong[*] and >> probably it should use symbol rather than reservedOp. Note that symbol >> is slightly different in Megaparsec as it's a plain combinator (rather >> than one instantiated from a first class module as in Parsec) so it >> takes two args rather than one. >> >> >> [*] Well, likely wrong - I haven't got round to using Megaparsec yet. >> > > > You are right: https://github.com/mrkkrp/megaparsec/commit/ > 750adb7c70392c3195eda12d816f4a1a2305321e > > > -- > Özgür Akgün > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Jeff Brown | Jeffrey Benjamin Brown Website Facebook LinkedIn (InMail is unreliable) Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From etanter at dcc.uchile.cl Sat Sep 24 15:13:26 2016 From: etanter at dcc.uchile.cl (=?utf-8?Q?=C3=89ric_Tanter?=) Date: Sat, 24 Sep 2016 17:13:26 +0200 Subject: [Haskell-cafe] Professor Position at University of Chile Message-ID: Full-Time Academic Position Computer Science Department, University of Chile http://www.dcc.uchile.cl The Computer Science Department of the University of Chile (DCC) is offering a full-time permanent position to carry out research and teaching, at the undergraduate and graduate levels. The DCC is the leading Computer Science Department in Chile, and one of the most active in Latin America. It pioneered the use of Unix and the adoption of the Internet in Chile. Today, it has 22 full-time professors, 10 of which come from Argentina, Uruguay, Belgium, France, and Ireland. We carry out high-quality research, publishing frequently in the most prestigious international conferences and journals. The DCC is in charge of the undergraduate Computer Science program within the Engineering Faculty of the University of Chile, reaching a thousand students in the first year of Engineering, and taking care of the CS specialization from the third year onward for over two hundreds students. Our MSc and PhD programs attract the best students from Latin America, with currently around fifty students in each program. The DCC offers newcomers an individual office and necessary equipment, as well as a starting grant for initiating their research activities; further funding is then obtained permanently upon publications. This is usually complemented with funds from a personal research project obtained from Conicyt, the national research agency, and/or with funds from larger collaborative projects. An assistant professor can supervise students of any level and have a light administrative load. Professors in our department are expected to teach three courses per year; typically one of these courses is an elective that the professor can define according to his/her interests. The salary provided by the University is very competitive, and depends on the ranking (assistant, associate, full); it is complemented with research projects. The successful candidate should be an active researcher with a PhD in Computer Science (or about to obtain it before starting the position). We are interested in any area of Computer Science, and both junior and senior researchers are welcome to apply. The candidate will be evaluated on the basis of both research and teaching activities, impact, as well as vision for the future. Important Dates We accept applications until November 30, 2016. The expected starting date is March 1, 2017 (August 2017 at the latest). Location The DCC is located in Santiago de Chile. Santiago is the capital and largest city in Chile, with a lively cultural scene and delectable cuisine. It is located at the foothills of the Andes, with over 300 days of sun per year, and both ski slopes and the Pacific coast at a 1-hour drive. Santiago is well-connected through direct flights to major hubs in both Europe and the USA. Chile is a country with a lot to offer especially to nature lovers, with over 4,300 km of seashore and mountains, filled with stunning landscapes and national parks stretching from Patagonia to the Atacama desert. For enquiries, please contact Prof. Gonzalo Navarro at gnavarro at dcc.uchile.cl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Sat Sep 24 19:57:47 2016 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 24 Sep 2016 12:57:47 -0700 Subject: [Haskell-cafe] The 13-line example in Text.Megaparsec.Expr In-Reply-To: References: Message-ID: I found the answer to my most recent question while reading this tutorial[1] on megaparsec. Thanks, and apologies for the noise. [1] https://mrkkrp.github.io/megaparsec/tutorials/parsing-simple-imperative-language.html On Sat, Sep 24, 2016 at 12:45 AM, Jeffrey Brown wrote: > I'm trying this again! The comment for Megaparsec.makeExprParser refers to > "parens". When I grep for "parens" in Megaparsec I get only two occurences, > both of them in comments: > > ./Lexer.hs:-- > parens = between (symbol "(") (symbol ")") > ./Expr.hs:-- > term = parens expr <|> integer "term" > > If I try defining parens as in the comment from Lexer.hs, I get these > errors: > > :37:33: > Couldn't match type ‘Char’ with ‘()’ > Expected type: [()] > Actual type: [Char] > In the first argument of ‘symbol’, namely ‘"("’ > In the first argument of ‘between’, namely ‘(symbol "(")’ > In the expression: between (symbol "(") (symbol ")") > > :37:46: > Couldn't match type ‘Char’ with ‘()’ > Expected type: [()] > Actual type: [Char] > In the first argument of ‘symbol’, namely ‘")"’ > In the second argument of ‘between’, namely ‘(symbol ")")’ > In the expression: between (symbol "(") (symbol ")") > > [1] https://hackage.haskell.org/package/megaparsec-5.0.1/docs/ > Text-Megaparsec-Expr.html > > On Mon, Feb 29, 2016 at 2:05 AM, Özgür Akgün wrote: > >> >> On 29 February 2016 at 08:22, Stephen Tetley >> wrote: >> >>> >>> For the expression parser, Megaparsec's documentation is wrong[*] and >>> probably it should use symbol rather than reservedOp. Note that symbol >>> is slightly different in Megaparsec as it's a plain combinator (rather >>> than one instantiated from a first class module as in Parsec) so it >>> takes two args rather than one. >>> >>> >>> [*] Well, likely wrong - I haven't got round to using Megaparsec yet. >>> >> >> >> You are right: https://github.com/mrkkrp/megaparsec/commit/750adb7c7 >> 0392c3195eda12d816f4a1a2305321e >> >> >> -- >> Özgür Akgün >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Jeff Brown | Jeffrey Benjamin Brown > Website > Facebook > LinkedIn (InMail is > unreliable) > Github > -- Jeff Brown | Jeffrey Benjamin Brown Website Facebook LinkedIn (InMail is unreliable) Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Sat Sep 24 22:15:33 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 25 Sep 2016 00:15:33 +0200 Subject: [Haskell-cafe] The meaning of categories constructed from HASK Message-ID: <102A341F-712E-4290-9782-ED42DC0B923A@aatal-apotheke.de> Dear Dimitri, I've never seen arrow or slice categories in a paper on functional programming. Commutative squares are most frequently used in the definition of typeclasses, where the documentation usually reads: Instances should satisfy: f.g = h.i where f,g,h,i are some functions involved in the definition of the typeclass. Haskell can not stop you writing an instance violating the commutative square, however. Certain special arrow categories are useful, even in Haskell. For example the Eilenberg-Moore category of a monad m. Objects are arrows m a -> a and morphisms are commutative squares liftM f m a ---------> m b | | | | v v a ----------> b f Such an f is sometimes called "linear". For example, every instance of Data.Monoid comes with an arrow mconcat :: (Monoid a) => [a] -> a and commutative squares between two monoids are precisely the functions f where f mempty = mempty and f (x `mappend` y) = (f x) `mappend` (f y) I'm sure you have looked at Control.Category in package base before asking this question. The Category typeclass defined there is not capable of expressing either of your examples, because: - The hom-set of a Category must be a HASK type (although not necessarily a function type) - Each hom-set must be parametrised by two HASK types The arrow category is not expressible, because we can not forge a HASK type that somehow specifies exacltly one function. Moreover, the cummutativity of a square is not expressible, that is, there is no HASK type consisting of all functions making a certain square commute. The slice category is not expressible, for the same reason as above. There are, however, interesting instances of Control.Category where the hom-set elements are not functions. For example, one could have memoized functions between stream types. The following goes back to Dirk Pattinson and Ulrich Berger, AFAIK. Suppose i is a type of tokens such that an infinite stream of i's encodes an element of type x. Likewise, let o be a type of tokens such that an infinite stream of o's encodes an element of type y. Now consider the type Mem below. -- Run the following in ghci -XNoImplicitPrelude import Control.Category import Data.List (head,tail) -- A memoized function [i] -> [o], representing a function x -> y. -- Either requesting an input token or yielding an output token. data Mem i o = Read (i -> Mem i o) | Write o (Mem i o) instance Category Mem where id = Read (\i -> Write i id) f . g = case f of Write p f' -> Write p (f' . g) Read r -> case g of Write o g' -> (r o) . g' Read r' -> Read (\i -> f . (r' i)) -- run a memoized function. -- This is a functor from Mem to HASK. runMem :: Mem i o -> [i] -> [o] runMem f input = case f of Write o f' -> o : runMem f' input Read r -> runMem (r (head input)) (tail input) If there are only finitely many possible input tokens i, then one can replace Read (i -> Mem i o) by Read (Map i (Mem i o)) in which case the entire memoized function really is a tree. Olaf From twilson at csufresno.edu Mon Sep 26 05:48:47 2016 From: twilson at csufresno.edu (Todd Wilson) Date: Sun, 25 Sep 2016 22:48:47 -0700 Subject: [Haskell-cafe] A question on dependent types in Haskell Message-ID: I haven't yet had the pleasure of exploring the subtleties of dependently-typed programming in Haskell, but I'm finding myself in need of a little bit of it in advance of that exploration and was hoping for some suggestions. I have a type of regular expressions: data RegExp = Empty | Letter Char | Plus RegExp RegExp | Cat RegExp RegExp | Star RegExp and a type of (deterministic) finite state machines that is polymorphic in the state type: data FSM a = FSM { states :: [a], start :: a, finals :: [a], delta :: [(a,Char,a)] } I've fixed an alphabet sigma :: [Char], and I want to write the function that converts a regular expression to its associated FSM. The machines associated with Empty and Letter are given by data EmptyFSM = Etrap emptyFSM :: FSM EmptyFSM emptyFSM = FSM { states = [Etrap], start = Etrap, finals = [], delta = [(Etrap, c, Etrap) | c <- sigma] } data LetterFSM = Lstart | Lfinal | Ltrap letterFSM :: Char -> FSM LetterFSM letterFSM c = FSM { states = [Lstart, Lfinal, Ltrap], start = Lstart, finals = [Lfinal], delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] ++ [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] } Suppose I can code the constructions of the union machine, concatenation machine, and star machine so that they have the types unionFSM :: FSM a -> FSM b -> FSM (a,b) catFSM :: FSM a -> FSM b -> FSM (a,[b]) starFSM :: FSM a -> FSM [a] Now what I want to do is to put all of this together into a function that takes a regular expression and returns the associated FSM. In effect, my function should have a dependent type like reg2fsm :: {r : RegExp} -> FSM (f r) where f is the function f :: RegExp -> * f Empty = EmptyFSM f (Letter a) = LetterFSM f (Plus r1 r2) = (f r1, f r2) f (Cat r1 r2) = (f r1, [f r2]) f (Star r) = [f r] and be given by reg2fsm Empty = emptyFSM reg2fsm (Letter c) = letterFSM c reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) reg2fsm (Star r) = starFSM (reg2fsm r) What is the suggested approach to achieving this in Haskell? -- Todd Wilson A smile is not an individual Computer Science Department product; it is a co-product. California State University, Fresno -- Thich Nhat Hanh From guillaum.bouchard+haskell at gmail.com Mon Sep 26 08:23:20 2016 From: guillaum.bouchard+haskell at gmail.com (Guillaume Bouchard) Date: Mon, 26 Sep 2016 10:23:20 +0200 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: References: Message-ID: Hi Todd, Sorry, I will not answer your question, but discuss some points. On Mon, Sep 26, 2016 at 7:48 AM, Todd Wilson wrote: > Suppose I can code the constructions of the union machine, > concatenation machine, and star machine so that they have the types > > unionFSM :: FSM a -> FSM b -> FSM (a,b) > catFSM :: FSM a -> FSM b -> FSM (a,[b]) > starFSM :: FSM a -> FSM [a] What is the type of the union of an union ? For example : union fsmA (union fsmB fsmC) where fsmX are of type FSM x. Are you waiting for a triple (i.e. FSM (a, b, c)) or does a recursive tuple structures is ok ? (Such as FSM (a, (b, c))) such as your example depict ? > Now what I want to do is to put all of this together into a function > that takes a regular expression and returns the associated FSM. In > effect, my function should have a dependent type like > > reg2fsm :: {r : RegExp} -> FSM (f r) As far as I understand depend type in Haskell, you cannot do that. You need to "pack" your "typed" FSM inside a existentially qualified generic fsm, such as : data AnyFSM = forall t. AnyFsm (FSM t) And then, later, "unpack" it using a case. However I think you also need a constraint on `t` else you will not be able to recover anything from it. Sorry, my knowledge stops here. > where f is the function > > f :: RegExp -> * > f Empty = EmptyFSM > f (Letter a) = LetterFSM > f (Plus r1 r2) = (f r1, f r2) > f (Cat r1 r2) = (f r1, [f r2]) > f (Star r) = [f r] As far as I know, and I'll be happy to be proven wrong here, you cannot write a function from a value to a type. However you can "promote" your value level RegExp to a type level 'RegExp (using the DataKind extension), and in this case, you will need to use tick in from of you promoted kind (such as 'Empty, or 'Plus), but as far as I know it is still impossible to write function this way, you need to write type families, something such as : type family f (t :: RegexExp) = * where f 'Empty = EmptyFSM f ('Letter a) = LetterFSM I apologies for this partial answer, but I'm interested by your question so I wanted to contribute at my level. -- Guillaume. From michael at snoyman.com Mon Sep 26 10:32:57 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 13:32:57 +0300 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: I just realized that I had shared this answer on Twitter, but not on this mailing list. For those wanting to have direct access to GHC and other such tools, without needing to prefix calls with `stack exec -- `, the following added to your ~/.bashrc (or equivalent) will do the trick: export PATH=`stack path --bin-path` This can go as far as providing a means of using cabal-install, for example: https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2 For those without an established workflow, or open to experimenting with new workflows, I'd still recommend sticking with `stack exec -- ` in general, since it composes nicely with projects, letting you automatically switch to different GHC versions and package sets. But this is certainly another option to consider. On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of > interest (as many of us have). The discussion inspired me to take another > look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build > tool for Haskell, I have never much liked stack. One of my chief goals in > taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This > machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I > really just want the ability to run Haskell expressions in GHCi. So I skip > `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages > along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of > 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: > /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed > delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I > got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment > of our community has not celebrated stack as much as other segments have. > We all have different workflows. > > From what I understand about it, stack is great for a project-based > workflow. In this workflow, you are working on a Haskell project. You are > happy to specify settings in .cabal and stack.yaml files. And you really > want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In > this workflow, you aren’t quite as organized perhaps and do not have all > your settings written. You also want the ability just to compile a file > without changing any configurations. You want to be able to start GHCi with > a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you > prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a > project-based workflow, and don’t use it when you want a compiler-based > workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The > downloads page right now is not serving us well. (I was legitimately > scratching my head at first trying to figure out how to provision a new > computer.) Sadly, I don’t see a good option presenting itself. Both > potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) > serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell > Platform Minimal) does appear to lack a “here’s what you do first” > tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to > discover — you have to choose the oft-maligned Haskell Platform link before > you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based > workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary > warnings every time GHC is invoked outside of a project. Furthermore, stack > prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a > system GHC. Perhaps it would even be sufficient for `stack setup` to > clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we > should consider writing up criteria that potential users should consider > when choosing what workflow to start with. We’ll need to have a tighter > recommendation for those with no experience programming, but most > developers should be able to recognize what workflow they prefer and choose > accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then > we’ll really be in a quandary about which installation procedure to put > first. Perhaps we should incentivize fixing (A) and (B) by saying whichever > one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps > identified part of the burning black heart of the reason behind the vitriol > of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Mon Sep 26 12:26:47 2016 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Mon, 26 Sep 2016 09:26:47 -0300 Subject: [Haskell-cafe] Professor Position at University of Chile In-Reply-To: References: Message-ID: I am chilean (based in the UTFSM in valparaiso). In the mail it wasn't specify why a haskeller would be interested on that position. I am interested (as an alumni) in whatever talk/courses the DCC has on functional programming or what you guys are studying related to it. Can you fill me up? -- Ruben From li-yao.xia at ens.fr Mon Sep 26 08:51:27 2016 From: li-yao.xia at ens.fr (Li-yao Xia) Date: Mon, 26 Sep 2016 09:51:27 +0100 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: References: Message-ID: <7876545b-8f72-6709-c603-cd4f6b5fc8e5@ens.fr> Hello Todd, This seems like a neat place to use GADTs! Instead of trying to define f :: RegExp -> * by fully lifting RegExp to the type level, you can use GADTs to reflect the structure of a RegExp in its type: data RegExp a where -- a is the state type of the FSM associated with the regexp Empty :: RegExp EmptyFSM Letter :: RegExp LetterFSM Plus :: RegExp a -> RegExp b -> RegExp (a, b) Cat :: RegExp a -> RegExp b -> RegExp (a, [b]) Star :: RegExp a -> RegExp [a] reg2fsm :: Eq a => RegExp a -> FSM a -- ^ I assume you'll need an Eq constraint here to normalize -- the "non-deterministic states". It may be much less flexible than what you originally intended, because the RegExp type is now tied to your FSM implementation. RegExps might also become painful to pass around because of their too explicit type. If that happens to be the case, you can clean up an API which uses this regexp with an existential wrapper. data SomeRegExp where SomeRegExp :: Eq a => RegExp a -> SomeRegExp data SomeFSM where SomeFSM :: Eq a => FSM a -> SomeFSM Another simpler solution is to only use such a wrapper around FSM (i.e., your output), keeping the RegExp type as you first wrote it. You'd have: reg2fsm :: RegExp -> SomeFSM Here you totally lose the relationship between the RegExp and the FSM, so it seems to move away from what you were looking for. But if ultimately you don't care about the actual type of the state of a FSM, this gets the job done. Regards, Li-yao On 09/26/2016 06:48 AM, Todd Wilson wrote: > I haven't yet had the pleasure of exploring the subtleties of > dependently-typed programming in Haskell, but I'm finding myself in > need of a little bit of it in advance of that exploration and was > hoping for some suggestions. > > I have a type of regular expressions: > > data RegExp = Empty > | Letter Char > | Plus RegExp RegExp > | Cat RegExp RegExp > | Star RegExp > > and a type of (deterministic) finite state machines that is > polymorphic in the state type: > > data FSM a = FSM { > states :: [a], > start :: a, > finals :: [a], > delta :: [(a,Char,a)] > } > > I've fixed an alphabet sigma :: [Char], and I want to write the > function that converts a regular expression to its associated FSM. The > machines associated with Empty and Letter are given by > > data EmptyFSM = Etrap > emptyFSM :: FSM EmptyFSM > emptyFSM = FSM { > states = [Etrap], > start = Etrap, > finals = [], > delta = [(Etrap, c, Etrap) | c <- sigma] > } > > data LetterFSM = Lstart | Lfinal | Ltrap > letterFSM :: Char -> FSM LetterFSM > letterFSM c = FSM { > states = [Lstart, Lfinal, Ltrap], > start = Lstart, > finals = [Lfinal], > delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] ++ > [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] > } > > Suppose I can code the constructions of the union machine, > concatenation machine, and star machine so that they have the types > > unionFSM :: FSM a -> FSM b -> FSM (a,b) > catFSM :: FSM a -> FSM b -> FSM (a,[b]) > starFSM :: FSM a -> FSM [a] > > Now what I want to do is to put all of this together into a function > that takes a regular expression and returns the associated FSM. In > effect, my function should have a dependent type like > > reg2fsm :: {r : RegExp} -> FSM (f r) > > where f is the function > > f :: RegExp -> * > f Empty = EmptyFSM > f (Letter a) = LetterFSM > f (Plus r1 r2) = (f r1, f r2) > f (Cat r1 r2) = (f r1, [f r2]) > f (Star r) = [f r] > > and be given by > > reg2fsm Empty = emptyFSM > reg2fsm (Letter c) = letterFSM c > reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) > reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) > reg2fsm (Star r) = starFSM (reg2fsm r) > > What is the suggested approach to achieving this in Haskell? > > -- > Todd Wilson A smile is not an individual > Computer Science Department product; it is a co-product. > California State University, Fresno -- Thich Nhat Hanh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From rae at cs.brynmawr.edu Mon Sep 26 13:23:34 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 26 Sep 2016 09:23:34 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> Thanks, Michael, for repeating this here. (I'm not on Twitter, as you may have figured out.) So, as I understand it, I could use the procedure below to install a "system GHC", which could then be filled out with libraries by either `cabal install xxx` or `stack install xxx`. If this is indeed the case, I will expect to recommend stack to my students next semester, along with instructions of how to modify their PATHs. I'd also be happy to reconsider recommending stack as the one option on a downloads page, if we include the PATH updating instructions. With regard to `stack exec`: If I modify my PATH to allow direct calls to ghc(i) and then create a project with a stack.yaml, won't `stack exec` use the local settings, etc., when I'm in a subdirectory of the project? At the bottom of your email, it sounds like you're recommending not modifying my PATH, instead always using `stack exec` for a better experience. But it seems to me that modifying my path allows me to skip the `stack exec` outside of projects while still retaining the nice behavior inside of projects, a net win to my eyes. (Your opinion on this may differ, of course.) Is there something I'm missing here? (Sidenote: You used `stack build` where I expected `stack install` in your gist. I understand that the latter copies executables somewhere and the former does not, but then it seems that the binaries are available in `stack path --bin-path`, so I'm a bit confused.) Thanks again for your input here! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 26, 2016, at 6:32 AM, Michael Snoyman wrote: > > I just realized that I had shared this answer on Twitter, but not on this mailing list. > > For those wanting to have direct access to GHC and other such tools, without needing to prefix calls with `stack exec -- `, the following added to your ~/.bashrc (or equivalent) will do the trick: > > export PATH=`stack path --bin-path` > > This can go as far as providing a means of using cabal-install, for example: > > https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2 > > For those without an established workflow, or open to experimenting with new workflows, I'd still recommend sticking with `stack exec -- ` in general, since it composes nicely with projects, letting you automatically switch to different GHC versions and package sets. But this is certainly another option to consider. > > On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg > wrote: > I’ve watched the recent back-and-forth about stack with quite a bit of interest (as many of us have). The discussion inspired me to take another look at stack. Here are the results of that foray. > > First, a disclosure: While I have appreciated the emergence of a new build tool for Haskell, I have never much liked stack. One of my chief goals in taking another look is to understand better why I do not like it. > > My task: Set up a Haskell environment on a new machine (a Mac). This machine has no Haskell infrastructure on it. > > My approach: > > 1. `brew install haskell-stack`. Success. > > At this point, I do not have a Haskell project I wish to build. Instead, I really just want the ability to run Haskell expressions in GHCi. So I skip `stack new` and go straight to > > 2. `stack setup`. This succeeds, but prints out some interesting messages along the way, including > > > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of 71c0a55d0a877954d9590e285c0eb861ace2d8cc > > Right Nothing > > At the end, I am helpfully told > > > To use this GHC and packages outside of a project, consider using: > > stack ghc, stack ghci, stack runghc, or stack exec > > > > So I then > > 3. `stack ghci`. My computer’s first reaction is to say > > > Run from outside a project, using implicit global project config > > Using resolver: lts-6.17 from implicit global project's config file: /home/rae/.stack/global-project/stack.yaml > > Error parsing targets: The specified targets matched no packages. > > Perhaps you need to run 'stack init'? > > Warning: build failed, but optimistically launching GHCi anyway > > > > which doesn’t make me feel all that comfortable, but then I am indeed delivered to the GHCi prompt, which works as expected. > > Done with GHCi, I quit. I then want to double-check which version of GHC I got, so I > > 4. `stack ghc --version`. This command reports > > > Invalid option `--version’ > > Grumble. It seems I can’t interact with GHC directly. > > ———— > > At this point, I am reminded why I dislike stack: > > **It’s optimized for a different workflow than I use.** > > And I think this fact (repeated by others’ experiences) is why a segment of our community has not celebrated stack as much as other segments have. We all have different workflows. > > From what I understand about it, stack is great for a project-based workflow. In this workflow, you are working on a Haskell project. You are happy to specify settings in .cabal and stack.yaml files. And you really want your build to work in the future and on other machines. > > In my experience, stack is not great with a compiler-based workflow. In this workflow, you aren’t quite as organized perhaps and do not have all your settings written. You also want the ability just to compile a file without changing any configurations. You want to be able to start GHCi with a nice set of libraries with which to experiment. > > I definitely like a compiler-based workflow. I’m sure that many of you prefer a project-based workflow. > > The great news here is that we have a choice: use stack for a project-based workflow, and don’t use it when you want a compiler-based workflow. No one needs to convince others about personal preferences. > > But there is one nagging issue: what do we suggest to newcomers? The downloads page right now is not serving us well. (I was legitimately scratching my head at first trying to figure out how to provision a new computer.) Sadly, I don’t see a good option presenting itself. Both potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) serious shortcomings. > > A. The Haskell Toolchain (that is, what’s currently called the Haskell Platform Minimal) does appear to lack a “here’s what you do first” tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to discover — you have to choose the oft-maligned Haskell Platform link before you are told that there is a minimal variant. > > B. stack sets up GHC in a way that either 1) requires a project-based workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary warnings every time GHC is invoked outside of a project. Furthermore, stack prohibits direct interaction with GHC (as in `ghc --version`). > > There’s more good news here! Both of these problems are really easy to fix. > > To fix (A), someone just has to write the tutorial. > > To fix (B), stack just needs a new option so that `stack setup` installs a system GHC. Perhaps it would even be sufficient for `stack setup` to clearly tell the user where ghc is installed and what to add to their PATH. > > I also think, if readers agree with my conclusions about workflows, we should consider writing up criteria that potential users should consider when choosing what workflow to start with. We’ll need to have a tighter recommendation for those with no experience programming, but most developers should be able to recognize what workflow they prefer and choose accordingly. > > Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then we’ll really be in a quandary about which installation procedure to put first. Perhaps we should incentivize fixing (A) and (B) by saying whichever one happens first gets to be featured first on the page? :) > > So: Does my characterization of workflows resonate? Have I perhaps identified part of the burning black heart of the reason behind the vitriol of late? Should we fix (A) and (B)? > > I’m looking forward to hearing your thoughts. > > Richard > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Mon Sep 26 13:36:10 2016 From: sean.leather at gmail.com (Sean Leather) Date: Mon, 26 Sep 2016 15:36:10 +0200 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: Hi Michael, On Mon, Sep 26, 2016 at 12:32 PM, Michael Snoyman wrote: > For those wanting to have direct access to GHC and other such tools, > without needing to prefix calls with `stack exec -- `, the following added > to your ~/.bashrc (or equivalent) will do the trick: > > export PATH=`stack path --bin-path` This is not the side-effect-free function I expected it to be. I just tried it on a Mac after a new install of stack: $ stack path --bin-path Run from outside a project, using implicit global project config Using resolver: lts-7.0 from implicit global project's config file: ~/.stack/global-project/stack.yaml Fetched package index. Populated index cache. No compiler found, expected minor version match with ghc-8.0.1 (x86_64) (based on resolver setting in /Users/leather/.stack/global-project/stack.yaml). Try running "stack setup" to install the correct GHC into ~/.stack/programs/x86_64-osx/ The above took nearly 10 minutes and failed. I would not recommend doing that in a ~/.bashrc. See https://github.com/commercialhaskell/stack/issues/2325 for the issue I reported in July. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Sep 26 13:40:15 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 16:40:15 +0300 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> <181F4559-F28E-4BC2-9AAF-ABE344EF781A@cs.brynmawr.edu> Message-ID: On Mon, Sep 26, 2016 at 4:23 PM, Richard Eisenberg wrote: > Thanks, Michael, for repeating this here. (I'm not on Twitter, as you may > have figured out.) > > So, as I understand it, I could use the procedure below to install a > "system GHC", which could then be filled out with libraries by either > `cabal install xxx` or `stack install xxx`. > > If this is indeed the case, I will expect to recommend stack to my > students next semester, along with instructions of how to modify their > PATHs. I'd also be happy to reconsider recommending stack as the one option > on a downloads page, if we include the PATH updating instructions. > > This is _almost_ the case. When you use `stack install xxx` (or, for that matter, `cabal install xxx` inside a sandbox), no packages will be registered in the default user package database. Without modifying `GHC_PACKAGE_PATH`, those packages will not be available from a straight `runghc`. By contrast, `stack exec -- runghc` _will_ have access because it sets the `GHC_PACKAGE_PATH` env var. One possibility to overcome this is to just modify your ~/.bashrc to say: export PATH=$(stack path --bin-path) export GHC_PACKAGE_PATH=$(stack path --ghc-package-path) This is probably a fairly safe move overall, but it's not well tested (or, at least, _I_ haven't tested it well). Then you'd be able to `stack build some-library` and have it available. Or, leave off GHC_PACKAGE_PATH, use a `cabal install some-library` without a sandbox, and get the same result. (Typical downsides of lack of sandboxes would apply of course.) > With regard to `stack exec`: If I modify my PATH to allow direct calls to > ghc(i) and then create a project with a stack.yaml, won't `stack exec` use > the local settings, etc., when I'm in a subdirectory of the project? At the > bottom of your email, it sounds like you're recommending not modifying my > PATH, instead always using `stack exec` for a better experience. But it > seems to me that modifying my path allows me to skip the `stack exec` > outside of projects while still retaining the nice behavior inside of > projects, a net win to my eyes. (Your opinion on this may differ, of > course.) Is there something I'm missing here? > > It's really a matter of what you consider best, thus my referral to established workflows. If you use the PATH modification trick, and have a global configuration targeting GHC 8.0.1, and then go inside a directory that using GHC 7.10.3: * `stack exec -- ghc` will use GHC 7.10.3 * `ghc` will use GHC 8.0.1 Honestly, this somewhat gets to a point of trying to read the user's mind about what the anticipated behavior is. Personally, I've come to expect and enjoy the behavior of respecting the local settings, though there are certainly times when it's _not_ what I want. So take my recommendation to stick with `stack exec --` with a large grain of salt; as long as you understand that `stack exec ghc` and `ghc` in a given directory may behave differently, the PATH trick can work. And especially for teaching purposes, I can imagine the situation of multiple GHC versions to be a much smaller concern. > (Sidenote: You used `stack build` where I expected `stack install` in your > gist. I understand that the latter copies executables somewhere and the > former does not, but then it seems that the binaries are available in > `stack path --bin-path`, so I'm a bit confused.) > > Every project has a .stack-work directory, and (somewhere) inside of that is a /bin/ directory, where `stack build` automatically copies executables to. (A similar directory exists for each snapshot.) When you use `stack exec`, it adds these /bin/ directories to your PATH, so that you can easily run locally built executables. This is useful in many cases, but perhaps the most important is when you have an executable (like intero or ghc-mod) which is built against a specific GHC version: you're guaranteed to get the appropriate binary instead of whatever the last one to be installed happens to be. `stack install` by contrast copies this binaries out of those /bin/ directories and into ~/.local/bin (and somewhere else on Windows, I don't remember where offhand). This is a semi-standard directory for installing user built tools. This makes a lot of sense for tools like pandoc, stylish-haskell, hindent, etc: tools you'd want to use regardless of GHC version, and possibly when not working on Haskell code at all. > Thanks again for your input here! > Richard > > Pleasure, thanks for starting the conversation :) Michael > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > On Sep 26, 2016, at 6:32 AM, Michael Snoyman wrote: > > I just realized that I had shared this answer on Twitter, but not on this > mailing list. > > For those wanting to have direct access to GHC and other such tools, > without needing to prefix calls with `stack exec -- `, the following added > to your ~/.bashrc (or equivalent) will do the trick: > > export PATH=`stack path --bin-path` > > This can go as far as providing a means of using cabal-install, for > example: > > https://gist.github.com/snoyberg/959a2ade4287de6129910eeabec1d9d2 > > For those without an established workflow, or open to experimenting with > new workflows, I'd still recommend sticking with `stack exec -- ` in > general, since it composes nicely with projects, letting you automatically > switch to different GHC versions and package sets. But this is certainly > another option to consider. > > On Tue, Sep 13, 2016 at 9:58 PM, Richard Eisenberg > wrote: > >> I’ve watched the recent back-and-forth about stack with quite a bit of >> interest (as many of us have). The discussion inspired me to take another >> look at stack. Here are the results of that foray. >> >> First, a disclosure: While I have appreciated the emergence of a new >> build tool for Haskell, I have never much liked stack. One of my chief >> goals in taking another look is to understand better why I do not like it. >> >> My task: Set up a Haskell environment on a new machine (a Mac). This >> machine has no Haskell infrastructure on it. >> >> My approach: >> >> 1. `brew install haskell-stack`. Success. >> >> At this point, I do not have a Haskell project I wish to build. Instead, >> I really just want the ability to run Haskell expressions in GHCi. So I >> skip `stack new` and go straight to >> >> 2. `stack setup`. This succeeds, but prints out some interesting messages >> along the way, including >> >> > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of >> 71c0a55d0a877954d9590e285c0eb861ace2d8cc >> > Right Nothing >> >> At the end, I am helpfully told >> >> > To use this GHC and packages outside of a project, consider using: >> > stack ghc, stack ghci, stack runghc, or stack exec >> > >> >> So I then >> >> 3. `stack ghci`. My computer’s first reaction is to say >> >> > Run from outside a project, using implicit global project config >> > Using resolver: lts-6.17 from implicit global project's config file: >> /home/rae/.stack/global-project/stack.yaml >> > Error parsing targets: The specified targets matched no packages. >> > Perhaps you need to run 'stack init'? >> > Warning: build failed, but optimistically launching GHCi anyway >> > >> >> which doesn’t make me feel all that comfortable, but then I am indeed >> delivered to the GHCi prompt, which works as expected. >> >> Done with GHCi, I quit. I then want to double-check which version of GHC >> I got, so I >> >> 4. `stack ghc --version`. This command reports >> >> > Invalid option `--version’ >> >> Grumble. It seems I can’t interact with GHC directly. >> >> ———— >> >> At this point, I am reminded why I dislike stack: >> >> **It’s optimized for a different workflow than I use.** >> >> And I think this fact (repeated by others’ experiences) is why a segment >> of our community has not celebrated stack as much as other segments have. >> We all have different workflows. >> >> From what I understand about it, stack is great for a project-based >> workflow. In this workflow, you are working on a Haskell project. You are >> happy to specify settings in .cabal and stack.yaml files. And you really >> want your build to work in the future and on other machines. >> >> In my experience, stack is not great with a compiler-based workflow. In >> this workflow, you aren’t quite as organized perhaps and do not have all >> your settings written. You also want the ability just to compile a file >> without changing any configurations. You want to be able to start GHCi with >> a nice set of libraries with which to experiment. >> >> I definitely like a compiler-based workflow. I’m sure that many of you >> prefer a project-based workflow. >> >> The great news here is that we have a choice: use stack for a >> project-based workflow, and don’t use it when you want a compiler-based >> workflow. No one needs to convince others about personal preferences. >> >> But there is one nagging issue: what do we suggest to newcomers? The >> downloads page right now is not serving us well. (I was legitimately >> scratching my head at first trying to figure out how to provision a new >> computer.) Sadly, I don’t see a good option presenting itself. Both >> potential approaches (The Haskell Toolchain vs. stack) have (in my opinion) >> serious shortcomings. >> >> A. The Haskell Toolchain (that is, what’s currently called the Haskell >> Platform Minimal) does appear to lack a “here’s what you do first” >> tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to >> discover — you have to choose the oft-maligned Haskell Platform link before >> you are told that there is a minimal variant. >> >> B. stack sets up GHC in a way that either 1) requires a project-based >> workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary >> warnings every time GHC is invoked outside of a project. Furthermore, stack >> prohibits direct interaction with GHC (as in `ghc --version`). >> >> There’s more good news here! Both of these problems are really easy to >> fix. >> >> To fix (A), someone just has to write the tutorial. >> >> To fix (B), stack just needs a new option so that `stack setup` installs >> a system GHC. Perhaps it would even be sufficient for `stack setup` to >> clearly tell the user where ghc is installed and what to add to their PATH. >> >> I also think, if readers agree with my conclusions about workflows, we >> should consider writing up criteria that potential users should consider >> when choosing what workflow to start with. We’ll need to have a tighter >> recommendation for those with no experience programming, but most >> developers should be able to recognize what workflow they prefer and choose >> accordingly. >> >> Of course, there’s a bit of bad news: If both (A) and (B) are fixed, then >> we’ll really be in a quandary about which installation procedure to put >> first. Perhaps we should incentivize fixing (A) and (B) by saying whichever >> one happens first gets to be featured first on the page? :) >> >> So: Does my characterization of workflows resonate? Have I perhaps >> identified part of the burning black heart of the reason behind the vitriol >> of late? Should we fix (A) and (B)? >> >> I’m looking forward to hearing your thoughts. >> >> Richard >> >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Sep 26 13:42:58 2016 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 26 Sep 2016 16:42:58 +0300 Subject: [Haskell-cafe] [Haskell-community] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: On Mon, Sep 26, 2016 at 4:36 PM, Sean Leather wrote: > Hi Michael, > > On Mon, Sep 26, 2016 at 12:32 PM, Michael Snoyman wrote: > >> For those wanting to have direct access to GHC and other such tools, >> without needing to prefix calls with `stack exec -- `, the following added >> to your ~/.bashrc (or equivalent) will do the trick: >> >> export PATH=`stack path --bin-path` > > > This is not the side-effect-free function I expected it to be. I just > tried it on a Mac after a new install of stack: > > $ stack path --bin-path > Run from outside a project, using implicit global project config > Using resolver: lts-7.0 from implicit global project's config file: > ~/.stack/global-project/stack.yaml > Fetched package index. > Populated index cache. > No compiler found, expected minor version match with ghc-8.0.1 > (x86_64) (based on resolver setting in /Users/leather/.stack/global- > project/stack.yaml). > Try running "stack setup" to install the correct GHC into > ~/.stack/programs/x86_64-osx/ > > The above took nearly 10 minutes and failed. I would not recommend doing > that in a ~/.bashrc. > > See https://github.com/commercialhaskell/stack/issues/2325 for the issue > I reported in July. > > Regards, > Sean > That's a fair point, but if the user first runs `stack setup` (which I'd recommend in any usage of this line), it does become side-effect-free. Regarding #2325: it might make sense to have `stack path` simply fail if no project file is found, but user intent is a bit unclear on that point. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Mon Sep 26 22:53:10 2016 From: amindfv at gmail.com (Tom Murphy) Date: Tue, 27 Sep 2016 07:53:10 +0900 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: This is not the right mailing list for this ( https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ Tom On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: > I would argue that the adventure that is GHC is a natural monopoly - an > example of collaboration trumping competition. Certainly the results speak > for themselves, and I personally find it the most satisfying, the only sane > way to practice the craft of coding. So, as an enthusiastic user of a > monopolistic service (the best power to weight ratio I could find to > misquote Kmett), I would like to suggest to the community that we have a > respectful discussion on the implications of natural monopolies. > > Monopolies have their problems. They create power imbalances that need > active management to control. A community should be particularly wary of > monopolies attempting to vertically integrate up the production chain into > areas where a monopoly makes less sense. I would call the whole cabal > versus stack drama a text-book case of over-reach. Everyone agrees stack > operates at a higher level of abstraction then cabal, on top of it is > accurate. Cabal shouldn't even be allowed to compete above it's current > abstraction point. > > Haddock is another example of being blessed by ghc. It hits a corner-case > of perfection for the "I'm a hackage library" monopoly. But the outside > world of documentation, editing, rendering and conversion is invisible to > this monopolistic use case. We are forced to learn and use haddock, and, > for those of us with documentation needs outside hackage, the resultant > workflow is cruel and unusual. > > GHC is a great compiler, but should actively be discouraged from > monopolizing the associated tooling and documentation chains. There is > evidence of healthy open-source competition and significant gains to be > had, and Haskell runs the risk of missing out. > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Tue Sep 27 00:03:32 2016 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 26 Sep 2016 17:03:32 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: > GHC is a great compiler, but should actively be discouraged from monopolizing the associated tooling and documentation chains. Are you saying you wish those chains could be used with other languages? I would certianly agree to that, if it didn't harm Haskell. Are you saying you wish Haskell documentation was available in more than one way? It's funny to distinguish monopoly from competition in this environment, because the "haskell monopoly" is exactly the result of a competition, one between languages in the minds of programmers. Monopolies (use force of law to) align against; (open-source) programmers align together. (Most of us, I think, rely on possession. I'm not saying it's a trait humanity quickly sheds -- but there is clearly more power in sharing, making one's work public for others to build on.) Haskell's not really a monopoly! Possession is not the biggest player in the programming world. Some tiny information is private, yes, but the giant awesome things are given away for free. There's some abstract sense in which the technical landscape rather than the people exhibits a monopoly -- there is an energy valley, some awesome states are much easiest gotten to by a certain path, like how there is only one Jerusalem. Indeed maybe a pilgrimage ethos is helpful. > collaboration trumping competition It does! Popular, widespread collaboration has more potential, because scale matters. On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote: > This is not the right mailing list for this (https://wiki.haskell.org/ > Mailing_lists) ; forwarding to haskell-cafe@ > > Tom > > On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: > >> I would argue that the adventure that is GHC is a natural monopoly - an >> example of collaboration trumping competition. Certainly the results speak >> for themselves, and I personally find it the most satisfying, the only sane >> way to practice the craft of coding. So, as an enthusiastic user of a >> monopolistic service (the best power to weight ratio I could find to >> misquote Kmett), I would like to suggest to the community that we have a >> respectful discussion on the implications of natural monopolies. >> >> Monopolies have their problems. They create power imbalances that need >> active management to control. A community should be particularly wary of >> monopolies attempting to vertically integrate up the production chain into >> areas where a monopoly makes less sense. I would call the whole cabal >> versus stack drama a text-book case of over-reach. Everyone agrees stack >> operates at a higher level of abstraction then cabal, on top of it is >> accurate. Cabal shouldn't even be allowed to compete above it's current >> abstraction point. >> >> Haddock is another example of being blessed by ghc. It hits a >> corner-case of perfection for the "I'm a hackage library" monopoly. But >> the outside world of documentation, editing, rendering and conversion is >> invisible to this monopolistic use case. We are forced to learn and use >> haddock, and, for those of us with documentation needs outside hackage, the >> resultant workflow is cruel and unusual. >> >> GHC is a great compiler, but should actively be discouraged from >> monopolizing the associated tooling and documentation chains. There is >> evidence of healthy open-source competition and significant gains to be >> had, and Haskell runs the risk of missing out. >> >> _______________________________________________ >> Haskell mailing list >> Haskell at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Jeff Brown | Jeffrey Benjamin Brown Website Facebook LinkedIn (InMail is unreliable) Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Tue Sep 27 00:25:34 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 17:25:34 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: Monopolies directed by benevolent dictators are highly efficient, and often yield results that are highly valuable. If we are running with this metaphor, I'd agree that GHC and stack could fall into such a category. For both of these, though, we do not have dictatorship, we just have spiritual leaders (SPJ!! To name one, Simon is certainly a leader, in spirit, for the community). A bit of a tangent to a tangential conversation, but I wish that Haskell could move towards the "batteries included" attitude of Python's standard library. That is an example of benevolent dictatorship / vertical monopoly going very very well. -Michael On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote: > This is not the right mailing list for this > (https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ > > Tom > > On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: >> >> I would argue that the adventure that is GHC is a natural monopoly - an >> example of collaboration trumping competition. Certainly the results speak >> for themselves, and I personally find it the most satisfying, the only sane >> way to practice the craft of coding. So, as an enthusiastic user of a >> monopolistic service (the best power to weight ratio I could find to >> misquote Kmett), I would like to suggest to the community that we have a >> respectful discussion on the implications of natural monopolies. >> >> Monopolies have their problems. They create power imbalances that need >> active management to control. A community should be particularly wary of >> monopolies attempting to vertically integrate up the production chain into >> areas where a monopoly makes less sense. I would call the whole cabal >> versus stack drama a text-book case of over-reach. Everyone agrees stack >> operates at a higher level of abstraction then cabal, on top of it is >> accurate. Cabal shouldn't even be allowed to compete above it's current >> abstraction point. >> >> Haddock is another example of being blessed by ghc. It hits a corner-case >> of perfection for the "I'm a hackage library" monopoly. But the outside >> world of documentation, editing, rendering and conversion is invisible to >> this monopolistic use case. We are forced to learn and use haddock, and, for >> those of us with documentation needs outside hackage, the resultant workflow >> is cruel and unusual. >> >> GHC is a great compiler, but should actively be discouraged from >> monopolizing the associated tooling and documentation chains. There is >> evidence of healthy open-source competition and significant gains to be had, >> and Haskell runs the risk of missing out. >> >> _______________________________________________ >> Haskell mailing list >> Haskell at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From 123.wizek at gmail.com Tue Sep 27 01:33:06 2016 From: 123.wizek at gmail.com (Wizek) Date: Tue, 27 Sep 2016 03:33:06 +0200 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: > > A bit of a tangent to a tangential conversation, but I wish that > Haskell could move towards the "batteries included" attitude of > Python's standard library. Although I am not sure a dictatorship would be required -- benevolent or otherwise -- but batteries would certainly be welcome in the standard libraries. On 27 September 2016 at 02:25, Michael Sloan wrote: > Monopolies directed by benevolent dictators are highly efficient, and > often yield results that are highly valuable. If we are running with > this metaphor, I'd agree that GHC and stack could fall into such a > category. For both of these, though, we do not have dictatorship, we > just have spiritual leaders (SPJ!! To name one, Simon is certainly a > leader, in spirit, for the community). > > A bit of a tangent to a tangential conversation, but I wish that > Haskell could move towards the "batteries included" attitude of > Python's standard library. That is an example of benevolent > dictatorship / vertical monopoly going very very well. > > -Michael > > On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote: > > This is not the right mailing list for this > > (https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ > > > > Tom > > > > On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: > >> > >> I would argue that the adventure that is GHC is a natural monopoly - an > >> example of collaboration trumping competition. Certainly the results > speak > >> for themselves, and I personally find it the most satisfying, the only > sane > >> way to practice the craft of coding. So, as an enthusiastic user of a > >> monopolistic service (the best power to weight ratio I could find to > >> misquote Kmett), I would like to suggest to the community that we have a > >> respectful discussion on the implications of natural monopolies. > >> > >> Monopolies have their problems. They create power imbalances that need > >> active management to control. A community should be particularly wary > of > >> monopolies attempting to vertically integrate up the production chain > into > >> areas where a monopoly makes less sense. I would call the whole cabal > >> versus stack drama a text-book case of over-reach. Everyone agrees stack > >> operates at a higher level of abstraction then cabal, on top of it is > >> accurate. Cabal shouldn't even be allowed to compete above it's current > >> abstraction point. > >> > >> Haddock is another example of being blessed by ghc. It hits a > corner-case > >> of perfection for the "I'm a hackage library" monopoly. But the outside > >> world of documentation, editing, rendering and conversion is invisible > to > >> this monopolistic use case. We are forced to learn and use haddock, > and, for > >> those of us with documentation needs outside hackage, the resultant > workflow > >> is cruel and unusual. > >> > >> GHC is a great compiler, but should actively be discouraged from > >> monopolizing the associated tooling and documentation chains. There is > >> evidence of healthy open-source competition and significant gains to be > had, > >> and Haskell runs the risk of missing out. > >> > >> _______________________________________________ > >> Haskell mailing list > >> Haskell at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 27 01:52:52 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 26 Sep 2016 21:52:52 -0400 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: On Mon, Sep 26, 2016 at 9:33 PM, Wizek <123.wizek at gmail.com> wrote: > Although I am not sure a dictatorship would be required -- benevolent or >> otherwise -- but batteries would certainly be welcome in the standard >> libraries. > > > On 27 September 2016 at 02:25, Michael Sloan wrote: > >> A bit of a tangent to a tangential conversation, but I wish that >> Haskell could move towards the "batteries included" attitude of >> Python's standard library. That is an example of benevolent >> dictatorship / vertical monopoly going very very well. >> > That was attempted. Everyone hated it and newcomers are loudly warned to never ever use 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 cma at bitemyapp.com Tue Sep 27 01:56:55 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Mon, 26 Sep 2016 20:56:55 -0500 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: I don't think that's a good idea, given how little agreement there is on how things should work. Streaming is a good example here. It's not "obvious" how to do many things in Haskell that are "obvious" in other languages. Partly because industry hasn't used languages like Haskell much, partly because the canvas we work with permits more structure. On Mon, Sep 26, 2016 at 8:33 PM, Wizek <123.wizek at gmail.com> wrote: >> A bit of a tangent to a tangential conversation, but I wish that >> Haskell could move towards the "batteries included" attitude of >> Python's standard library. > > Although I am not sure a dictatorship would be required -- benevolent or > otherwise -- but batteries would certainly be welcome in the standard > libraries. > > On 27 September 2016 at 02:25, Michael Sloan wrote: >> >> Monopolies directed by benevolent dictators are highly efficient, and >> often yield results that are highly valuable. If we are running with >> this metaphor, I'd agree that GHC and stack could fall into such a >> category. For both of these, though, we do not have dictatorship, we >> just have spiritual leaders (SPJ!! To name one, Simon is certainly a >> leader, in spirit, for the community). >> >> A bit of a tangent to a tangential conversation, but I wish that >> Haskell could move towards the "batteries included" attitude of >> Python's standard library. That is an example of benevolent >> dictatorship / vertical monopoly going very very well. >> >> -Michael >> >> On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote: >> > This is not the right mailing list for this >> > (https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ >> > >> > Tom >> > >> > On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: >> >> >> >> I would argue that the adventure that is GHC is a natural monopoly - an >> >> example of collaboration trumping competition. Certainly the results >> >> speak >> >> for themselves, and I personally find it the most satisfying, the only >> >> sane >> >> way to practice the craft of coding. So, as an enthusiastic user of a >> >> monopolistic service (the best power to weight ratio I could find to >> >> misquote Kmett), I would like to suggest to the community that we have >> >> a >> >> respectful discussion on the implications of natural monopolies. >> >> >> >> Monopolies have their problems. They create power imbalances that need >> >> active management to control. A community should be particularly wary >> >> of >> >> monopolies attempting to vertically integrate up the production chain >> >> into >> >> areas where a monopoly makes less sense. I would call the whole cabal >> >> versus stack drama a text-book case of over-reach. Everyone agrees >> >> stack >> >> operates at a higher level of abstraction then cabal, on top of it is >> >> accurate. Cabal shouldn't even be allowed to compete above it's >> >> current >> >> abstraction point. >> >> >> >> Haddock is another example of being blessed by ghc. It hits a >> >> corner-case >> >> of perfection for the "I'm a hackage library" monopoly. But the >> >> outside >> >> world of documentation, editing, rendering and conversion is invisible >> >> to >> >> this monopolistic use case. We are forced to learn and use haddock, >> >> and, for >> >> those of us with documentation needs outside hackage, the resultant >> >> workflow >> >> is cruel and unusual. >> >> >> >> GHC is a great compiler, but should actively be discouraged from >> >> monopolizing the associated tooling and documentation chains. There is >> >> evidence of healthy open-source competition and significant gains to be >> >> had, >> >> and Haskell runs the risk of missing out. >> >> >> >> _______________________________________________ >> >> Haskell mailing list >> >> Haskell at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> >> >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From tonyday567 at gmail.com Tue Sep 27 02:06:24 2016 From: tonyday567 at gmail.com (Tony Day) Date: Tue, 27 Sep 2016 12:06:24 +1000 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: Commercially (aka using Haskell to put food on the table), haskell puts you on the economic fringes - I've met a lot of smart haskellers but never a rich one. So, trust me that I'm not a bug-eyed, profit-maximizing entrepreneurial flag-waver. In my experience, as an open-source contributor within mostly a haskell context, it's not all holding hands and singing Kumbaya. The currency of transaction is different to other economic systems; things like respect, reputation, the ability to say no to PRs, and the power to bike-shed an idea to death. A haskeller who makes a living improving GHC, or teaching haskell, or writing papers survives quite well even if the tooling and documentation isn't up to scratch. But for the commercial haskell hacker, (if and when they find work), livelihood and future prospects depend on the very best tooling, the most productive documentation, and rates of adoption. In other words, commercial users need GHC to survive, but GHC looks pretty much the same without them. On Tue, Sep 27, 2016 at 10:03 AM, Jeffrey Brown wrote: > > GHC is a great compiler, but should actively be discouraged from > monopolizing the associated tooling and documentation chains. > > Are you saying you wish those chains could be used with other languages? I > would certianly agree to that, if it didn't harm Haskell. > > Are you saying you wish Haskell documentation was available in more than > one way? > > It's funny to distinguish monopoly from competition in this environment, > because the "haskell monopoly" is exactly the result of a competition, one > between languages in the minds of programmers. Monopolies (use force of law > to) align against; (open-source) programmers align together. > > (Most of us, I think, rely on possession. I'm not saying it's a trait > humanity quickly sheds -- but there is clearly more power in sharing, > making one's work public for others to build on.) > > Haskell's not really a monopoly! Possession is not the biggest player in > the programming world. Some tiny information is private, yes, but the giant > awesome things are given away for free. There's some abstract sense in > which the technical landscape rather than the people exhibits a monopoly -- > there is an energy valley, some awesome states are much easiest gotten to > by a certain path, like how there is only one Jerusalem. Indeed maybe a > pilgrimage ethos is helpful. > > > collaboration trumping competition > > It does! Popular, widespread collaboration has more potential, because > scale matters. > > > On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote: > >> This is not the right mailing list for this ( >> https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@ >> >> Tom >> >> On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote: >> >>> I would argue that the adventure that is GHC is a natural monopoly - an >>> example of collaboration trumping competition. Certainly the results speak >>> for themselves, and I personally find it the most satisfying, the only sane >>> way to practice the craft of coding. So, as an enthusiastic user of a >>> monopolistic service (the best power to weight ratio I could find to >>> misquote Kmett), I would like to suggest to the community that we have a >>> respectful discussion on the implications of natural monopolies. >>> >>> Monopolies have their problems. They create power imbalances that need >>> active management to control. A community should be particularly wary of >>> monopolies attempting to vertically integrate up the production chain into >>> areas where a monopoly makes less sense. I would call the whole cabal >>> versus stack drama a text-book case of over-reach. Everyone agrees stack >>> operates at a higher level of abstraction then cabal, on top of it is >>> accurate. Cabal shouldn't even be allowed to compete above it's current >>> abstraction point. >>> >>> Haddock is another example of being blessed by ghc. It hits a >>> corner-case of perfection for the "I'm a hackage library" monopoly. But >>> the outside world of documentation, editing, rendering and conversion is >>> invisible to this monopolistic use case. We are forced to learn and use >>> haddock, and, for those of us with documentation needs outside hackage, the >>> resultant workflow is cruel and unusual. >>> >>> GHC is a great compiler, but should actively be discouraged from >>> monopolizing the associated tooling and documentation chains. There is >>> evidence of healthy open-source competition and significant gains to be >>> had, and Haskell runs the risk of missing out. >>> >>> _______________________________________________ >>> Haskell mailing list >>> Haskell at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > Jeff Brown | Jeffrey Benjamin Brown > Website > Facebook > LinkedIn (InMail is > unreliable) > Github > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Tue Sep 27 02:49:57 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 19:49:57 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: Do you have a link? I am not psychic. On Mon, Sep 26, 2016 at 6:52 PM, Brandon Allbery wrote: > > > On Mon, Sep 26, 2016 at 9:33 PM, Wizek <123.wizek at gmail.com> wrote: >>> >>> Although I am not sure a dictatorship would be required -- benevolent or >>> otherwise -- but batteries would certainly be welcome in the standard >>> libraries. >> >> >> On 27 September 2016 at 02:25, Michael Sloan wrote: >>> >>> A bit of a tangent to a tangential conversation, but I wish that >>> Haskell could move towards the "batteries included" attitude of >>> Python's standard library. That is an example of benevolent >>> dictatorship / vertical monopoly going very very well. > > > That was attempted. Everyone hated it and newcomers are loudly warned to > never ever use 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 From fa-ml at ariis.it Tue Sep 27 02:55:53 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 27 Sep 2016 04:55:53 +0200 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: <20160927025553.GA18295@casa.casa> On Mon, Sep 26, 2016 at 07:49:57PM -0700, Michael Sloan wrote: > Do you have a link? I am not psychic. https://en.wikipedia.org/wiki/Haskell_Platform From jeffbrown.the at gmail.com Tue Sep 27 03:04:25 2016 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 26 Sep 2016 20:04:25 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: <20160927025553.GA18295@casa.casa> References: <20160927025553.GA18295@casa.casa> Message-ID: What is it to include batteries? What is a PRI? (I googled both for like ten minutes.) On Mon, Sep 26, 2016 at 7:55 PM, Francesco Ariis wrote: > On Mon, Sep 26, 2016 at 07:49:57PM -0700, Michael Sloan wrote: > > Do you have a link? I am not psychic. > > https://en.wikipedia.org/wiki/Haskell_Platform > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Jeff Brown | Jeffrey Benjamin Brown Website Facebook LinkedIn (InMail is unreliable) Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Tue Sep 27 03:11:28 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 20:11:28 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: <20160927025553.GA18295@casa.casa> References: <20160927025553.GA18295@casa.casa> Message-ID: LOL! Oh man, this guy must be pulling my leg... Haskell platform was never a batteries included plan. It was a plan for package bureaucracy, mixed in with a broken installation approach. Sorry, but that was not a good enough attempt at emulating python's "batteries included" . From https://www.python.org/dev/peps/pep-0206/ > The Python source distribution has long maintained the philosophy > of "batteries included" -- having a rich and versatile standard > library which is immediately available, without making the user > download separate packages. So in other words, the Python guys knew that an approach like Haskell Platform would never work well, and so they didn't do it. Instead they built one big excellent standard library. I was confused by Mr Allbery's statements, because I know what "batteries included" means, and I could never think of Haskell doing that and having it rejected by newbies. Newbies would love it. That is what we should do, but it seems like consensus is unfortunately difficult to find. Having a standard set of packages that ossify and find their place in the museum of Haskell history is absolutely _not_ what python did. I'm talking about having a good base library. Now, this topic has been rehashed time and time again. We should do new-base, a radically new base-5. It will take work, it will take consensus. Do we have what it takes? -Michael On Mon, Sep 26, 2016 at 7:55 PM, Francesco Ariis wrote: > On Mon, Sep 26, 2016 at 07:49:57PM -0700, Michael Sloan wrote: >> Do you have a link? I am not psychic. > > https://en.wikipedia.org/wiki/Haskell_Platform > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From amindfv at gmail.com Tue Sep 27 03:20:17 2016 From: amindfv at gmail.com (Tom Murphy) Date: Tue, 27 Sep 2016 12:20:17 +0900 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan wrote: > LOL! Oh man, this guy must be pulling my leg... Haskell platform was > never a batteries included plan. It was a plan for package > bureaucracy, mixed in with a broken installation approach. Sorry, but > that was not a good enough attempt at emulating python's "batteries > included" . From https://www.python.org/dev/peps/pep-0206/ > > The substance of your positions on packaging/HP aside, it has been 15 hours since SPJ's email about having more respectful discussion in our community. Please speak with civility. Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Sep 27 03:21:21 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 26 Sep 2016 23:21:21 -0400 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: On Mon, Sep 26, 2016 at 11:11 PM, Michael Sloan wrote: > LOL! Oh man, this guy must be pulling my leg... Haskell platform was > never a batteries included plan. It was a plan for package > bureaucracy, mixed in with a broken installation approach. Sorry, but > that was not a good enough attempt at emulating python's "batteries > included" . From https://www.python.org/dev/peps/pep-0206/ > Wrong. Its enemies did a very thorough hatchet job. But they did let on their real intent: "batteries included" meant they can't force people to install their new incompatible batteries whenever they decide. "Batteries included" was exactly what they did NOT want, and do not want, because it limits them; unless, of course, they are the only source of the batteries. So now we have a battery store run by a company, which also ships its own build tool that works primarily with that store, and requires you to specify which generation of batteries to use --- and still runs into conflicts when someone wants to mix different versions of things because they're building the tool with the parts they need instead of the ones authorized by the store. Granted, a largeish chunk of the problem is that putting anything into the "batteries included" package space (ghc global packages) makes using any other versions of those packages scary at best. This is still a problem for the packages that ghc itself uses, and are therefore difficult to upgrade without replacing ghc. -- 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 mgsloan at gmail.com Tue Sep 27 03:24:10 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 20:24:10 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: Fair point, my mistake, sorry. I will try to tone it down and be a more civil communicator. To me equating the Haskell Platform with python's batteries included approach is laughable, so I laughed. I find Brandon's opinions on things to often be diametrically opposed to my own, and this seems to be a cause of a great deal of contention. -Michael On Mon, Sep 26, 2016 at 8:20 PM, Tom Murphy wrote: > On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan wrote: >> >> LOL! Oh man, this guy must be pulling my leg... Haskell platform was >> never a batteries included plan. It was a plan for package >> bureaucracy, mixed in with a broken installation approach. Sorry, but >> that was not a good enough attempt at emulating python's "batteries >> included" . From https://www.python.org/dev/peps/pep-0206/ >> > > The substance of your positions on packaging/HP aside, it has been 15 hours > since SPJ's email about having more respectful discussion in our community. > Please speak with civility. > > Tom > > From amindfv at gmail.com Tue Sep 27 03:33:10 2016 From: amindfv at gmail.com (Tom Murphy) Date: Tue, 27 Sep 2016 12:33:10 +0900 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: Thanks for the graceful reply! So as not to think I'm singling anyone out, I should say the "hatchet job" comment above is also the kind of thing very few of us want to be part of our day-to-day conversation. Everyone makes mistakes, not a big thing! It's just important that, on average, when people come visit our corner of the internet the thing they see isn't people saying hurtful things to each other. When I started here I felt like I could ask a question and not be ridiculed for it. Others should have the same feeling when they come by. Thanks! Tom On Tue, Sep 27, 2016 at 12:24 PM, Michael Sloan wrote: > Fair point, my mistake, sorry. I will try to tone it down and be a > more civil communicator. To me equating the Haskell Platform with > python's batteries included approach is laughable, so I laughed. > > I find Brandon's opinions on things to often be diametrically opposed > to my own, and this seems to be a cause of a great deal of contention. > > -Michael > > On Mon, Sep 26, 2016 at 8:20 PM, Tom Murphy wrote: > > On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan > wrote: > >> > >> LOL! Oh man, this guy must be pulling my leg... Haskell platform was > >> never a batteries included plan. It was a plan for package > >> bureaucracy, mixed in with a broken installation approach. Sorry, but > >> that was not a good enough attempt at emulating python's "batteries > >> included" . From https://www.python.org/dev/peps/pep-0206/ > >> > > > > The substance of your positions on packaging/HP aside, it has been 15 > hours > > since SPJ's email about having more respectful discussion in our > community. > > Please speak with civility. > > > > Tom > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Tue Sep 27 03:36:25 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Mon, 26 Sep 2016 20:36:25 -0700 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: And thank you for being a graceful moderator, Tom! Much appreciated :) I am going to step out of this thread to avoid any further disgruntlement. When opinions are this diametrically opposed and emotions are running hot, it is best to spend some time away from the discussion, and contemplate from whence eachother's viewpoints might originate. Peace and love! -Michael On Mon, Sep 26, 2016 at 8:33 PM, Tom Murphy wrote: > Thanks for the graceful reply! So as not to think I'm singling anyone out, I > should say the "hatchet job" comment above is also the kind of thing very > few of us want to be part of our day-to-day conversation. > > Everyone makes mistakes, not a big thing! It's just important that, on > average, when people come visit our corner of the internet the thing they > see isn't people saying hurtful things to each other. When I started here I > felt like I could ask a question and not be ridiculed for it. Others should > have the same feeling when they come by. > > Thanks! > Tom > > > > On Tue, Sep 27, 2016 at 12:24 PM, Michael Sloan wrote: >> >> Fair point, my mistake, sorry. I will try to tone it down and be a >> more civil communicator. To me equating the Haskell Platform with >> python's batteries included approach is laughable, so I laughed. >> >> I find Brandon's opinions on things to often be diametrically opposed >> to my own, and this seems to be a cause of a great deal of contention. >> >> -Michael >> >> On Mon, Sep 26, 2016 at 8:20 PM, Tom Murphy wrote: >> > On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan >> > wrote: >> >> >> >> LOL! Oh man, this guy must be pulling my leg... Haskell platform was >> >> never a batteries included plan. It was a plan for package >> >> bureaucracy, mixed in with a broken installation approach. Sorry, but >> >> that was not a good enough attempt at emulating python's "batteries >> >> included" . From https://www.python.org/dev/peps/pep-0206/ >> >> >> > >> > The substance of your positions on packaging/HP aside, it has been 15 >> > hours >> > since SPJ's email about having more respectful discussion in our >> > community. >> > Please speak with civility. >> > >> > Tom >> > >> > > > From defigueiredo at ucdavis.edu Tue Sep 27 03:57:48 2016 From: defigueiredo at ucdavis.edu (Dimitri DeFigueiredo) Date: Mon, 26 Sep 2016 21:57:48 -0600 Subject: [Haskell-cafe] The meaning of categories constructed from HASK In-Reply-To: <102A341F-712E-4290-9782-ED42DC0B923A@aatal-apotheke.de> References: <102A341F-712E-4290-9782-ED42DC0B923A@aatal-apotheke.de> Message-ID: <185baea2-1274-e00b-a021-f23c4f9df9c7@ucdavis.edu> Hi Olaf, Thank you very much for the thorough reply! If I understood your answer: - it seem these two derived categories are not easy to express in haskell because the objects of the constructed categories are arrows in HASK. - And although specific instances of such constructions (such as the Eilenberg-Moore category you point out) are useful, this is not so clear for the general case. I hope I got that right. Cheers, Dimitri On 24/09/16 4:15 PM, Olaf Klinke wrote: > Dear Dimitri, > > I've never seen arrow or slice categories in a paper on functional programming. > Commutative squares are most frequently used in the definition of typeclasses, where the documentation usually reads: > Instances should satisfy: f.g = h.i > where f,g,h,i are some functions involved in the definition of the typeclass. Haskell can not stop you writing an instance violating the commutative square, however. > > Certain special arrow categories are useful, even in Haskell. For example the Eilenberg-Moore category of a monad m. Objects are arrows m a -> a and morphisms are commutative squares > > liftM f > m a ---------> m b > | | > | | > v v > a ----------> b > f > > Such an f is sometimes called "linear". For example, every instance of Data.Monoid comes with an arrow mconcat :: (Monoid a) => [a] -> a and commutative squares between two monoids are precisely the functions f where > f mempty = mempty > and > f (x `mappend` y) = (f x) `mappend` (f y) > > I'm sure you have looked at Control.Category in package base before asking this question. The Category typeclass defined there is not capable of expressing either of your examples, because: > > - The hom-set of a Category must be a HASK type (although not necessarily a function type) > - Each hom-set must be parametrised by two HASK types > > The arrow category is not expressible, because we can not forge a HASK type that somehow specifies exacltly one function. Moreover, the cummutativity of a square is not expressible, that is, there is no HASK type consisting of all functions making a certain square commute. > > The slice category is not expressible, for the same reason as above. > > There are, however, interesting instances of Control.Category where the hom-set elements are not functions. For example, one could have memoized functions between stream types. The following goes back to Dirk Pattinson and Ulrich Berger, AFAIK. Suppose i is a type of tokens such that an infinite stream of i's encodes an element of type x. Likewise, let o be a type of tokens such that an infinite stream of o's encodes an element of type y. Now consider the type Mem below. > > -- Run the following in ghci -XNoImplicitPrelude > import Control.Category > import Data.List (head,tail) > > -- A memoized function [i] -> [o], representing a function x -> y. > -- Either requesting an input token or yielding an output token. > data Mem i o = Read (i -> Mem i o) | Write o (Mem i o) > > instance Category Mem where > id = Read (\i -> Write i id) > f . g = case f of > Write p f' -> Write p (f' . g) > Read r -> case g of > Write o g' -> (r o) . g' > Read r' -> Read (\i -> f . (r' i)) > > -- run a memoized function. > -- This is a functor from Mem to HASK. > runMem :: Mem i o -> [i] -> [o] > runMem f input = case f of > Write o f' -> o : runMem f' input > Read r -> runMem (r (head input)) (tail input) > > If there are only finitely many possible input tokens i, then one can replace Read (i -> Mem i o) by Read (Map i (Mem i o)) in which case the entire memoized function really is a tree. > > Olaf -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F From tonyday567 at gmail.com Tue Sep 27 07:37:28 2016 From: tonyday567 at gmail.com (Tony Day) Date: Tue, 27 Sep 2016 17:37:28 +1000 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: > Its enemies did a very thorough hatchet job. Not thorough enough I say, as a sworn enemy. I actually have haskell platform installed with batteries included at work on windows (because that's how we set up python - I pleaded but got nowhere). I even have a current bug falling somewhere between the platform and stack - something crashed looking for the standard linux command line tools - was it the msys2 or mingw in platform, or was it stack? Where do I even turn for help? I'm not part of the 'they' straw-man you sketch out, and I'm asserting that the reality in the community is the opposite - commercial Haskell is the runt of the litter and shame on the community for not acknowledging this. At the very least, bashing commercial Haskell interests for being commercial is a weak argument, given the reality of how little commercial scope exists right now. Accusations of engagement in monopolistic intent is, quite frankly, pure projection. On Tue, Sep 27, 2016 at 1:21 PM, Brandon Allbery wrote: > > On Mon, Sep 26, 2016 at 11:11 PM, Michael Sloan wrote: > >> LOL! Oh man, this guy must be pulling my leg... Haskell platform was >> never a batteries included plan. It was a plan for package >> bureaucracy, mixed in with a broken installation approach. Sorry, but >> that was not a good enough attempt at emulating python's "batteries >> included" . From https://www.python.org/dev/peps/pep-0206/ >> > > Wrong. > > Its enemies did a very thorough hatchet job. But they did let on their > real intent: "batteries included" meant they can't force people to install > their new incompatible batteries whenever they decide. "Batteries included" > was exactly what they did NOT want, and do not want, because it limits > them; unless, of course, they are the only source of the batteries. > > So now we have a battery store run by a company, which also ships its own > build tool that works primarily with that store, and requires you to > specify which generation of batteries to use --- and still runs into > conflicts when someone wants to mix different versions of things because > they're building the tool with the parts they need instead of the ones > authorized by the store. > > Granted, a largeish chunk of the problem is that putting anything into the > "batteries included" package space (ghc global packages) makes using any > other versions of those packages scary at best. This is still a problem for > the packages that ghc itself uses, and are therefore difficult to upgrade > without replacing ghc. > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Tue Sep 27 07:47:29 2016 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Tue, 27 Sep 2016 09:47:29 +0200 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: <20160927074729.GA7592@octa> On Mon, Sep 26, 2016 at 05:25:34PM -0700, Michael Sloan wrote: > A bit of a tangent to a tangential conversation, but I wish that > Haskell could move towards the "batteries included" attitude of > Python's standard library. That is an example of benevolent > dictatorship / vertical monopoly going very very well. The problem with batteries included is, that the batteries might never be the best. I think that's already the case for some parts of the Python standard library, that other external libraries are preferred. Now you still have to educate Newbies which libraries they should use. From michael at snoyman.com Tue Sep 27 07:48:16 2016 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 27 Sep 2016 10:48:16 +0300 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: On Tue, Sep 27, 2016 at 10:37 AM, Tony Day wrote: > > Its enemies did a very thorough hatchet job. > > Not thorough enough I say, as a sworn enemy. I actually have haskell > platform installed with batteries included at work on windows (because > that's how we set up python - I pleaded but got nowhere). I even have a > current bug falling somewhere between the platform and stack - something > crashed looking for the standard linux command line tools - was it the > msys2 or mingw in platform, or was it stack? Where do I even turn for help? > > I'm not part of the 'they' straw-man you sketch out, and I'm asserting > that the reality in the community is the opposite - commercial Haskell is > the runt of the litter and shame on the community for not acknowledging > this. > > At the very least, bashing commercial Haskell interests for being > commercial is a weak argument, given the reality of how little commercial > scope exists right now. Accusations of engagement in monopolistic intent > is, quite frankly, pure projection. > > > On Tue, Sep 27, 2016 at 1:21 PM, Brandon Allbery > wrote: > >> >> On Mon, Sep 26, 2016 at 11:11 PM, Michael Sloan >> wrote: >> >>> LOL! Oh man, this guy must be pulling my leg... Haskell platform was >>> never a batteries included plan. It was a plan for package >>> bureaucracy, mixed in with a broken installation approach. Sorry, but >>> that was not a good enough attempt at emulating python's "batteries >>> included" . From https://www.python.org/dev/peps/pep-0206/ >>> >> >> Wrong. >> >> Its enemies did a very thorough hatchet job. But they did let on their >> real intent: "batteries included" meant they can't force people to install >> their new incompatible batteries whenever they decide. "Batteries included" >> was exactly what they did NOT want, and do not want, because it limits >> them; unless, of course, they are the only source of the batteries. >> >> So now we have a battery store run by a company, which also ships its own >> build tool that works primarily with that store, and requires you to >> specify which generation of batteries to use --- and still runs into >> conflicts when someone wants to mix different versions of things because >> they're building the tool with the parts they need instead of the ones >> authorized by the store. >> >> Granted, a largeish chunk of the problem is that putting anything into >> the "batteries included" package space (ghc global packages) makes using >> any other versions of those packages scary at best. This is still a problem >> for the packages that ghc itself uses, and are therefore difficult to >> upgrade without replacing ghc. >> >> The bug you're referring to is this: https://github.com/haskell/haskell-platform/issues/251 You can work around it by adding `system-ghc: false` to your config files. And yes, that basically means that everything shipped with the HP besides the Stack executable itself is being ignored. Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Tue Sep 27 07:50:36 2016 From: gershomb at gmail.com (Gershom B) Date: Tue, 27 Sep 2016 03:50:36 -0400 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: On September 27, 2016 at 3:37:40 AM, Tony Day (tonyday567 at gmail.com) wrote: > I even have a > current bug falling somewhere between the platform and stack - something > crashed looking for the standard linux command line tools - was it the > msys2 or mingw in platform, or was it stack? Where do I even turn for help? This patch should fix the issue if it is what I think it is. But the patch is not in a release yet :-/ https://github.com/commercialhaskell/stack/pull/2552 One workaround is suggested on an associated ticket: https://github.com/commercialhaskell/stack/issues/1714 Another workaround as I understand it is to just invoke stack always with --no-system-ghc for now. As to where to turn for help, I think the usual sources all would work — irc, slack, mailinglists (such as cafe — look, it worked!), stackoverflow, etc. Hope this helps, Gershom From tonyday567 at gmail.com Tue Sep 27 08:46:01 2016 From: tonyday567 at gmail.com (Tony Day) Date: Tue, 27 Sep 2016 08:46:01 +0000 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: Thanks to you both. > mailinglists (such as cafe — look, it worked!) I'm totally sold on this new-fangled mailing list thing. It's like slack for adults who like to shuffle at their own pace. > Not thorough enough I say, as a sworn enemy. I'm not really - I was kind of glad when they installed Haskell Platform with batteries so I could prove a point, if only to myself, that stack was the better choice, but it's been smooth sailing except for this one bug. I've been able to install everything I need, creating an isolated and sane oasis in this weird windows world. I think I unfairly identify HP with cabal hell, and then the flashbacks trigger. On Tue, Sep 27, 2016 at 5:50 PM, Gershom B wrote: > On September 27, 2016 at 3:37:40 AM, Tony Day (tonyday567 at gmail.com) > wrote: > > > I even have a > > current bug falling somewhere between the platform and stack - something > > crashed looking for the standard linux command line tools - was it the > > msys2 or mingw in platform, or was it stack? Where do I even turn for > help? > > This patch should fix the issue if it is what I think it is. But the patch > is not in a release yet :-/ > > https://github.com/commercialhaskell/stack/pull/2552 > > One workaround is suggested on an associated ticket: > https://github.com/commercialhaskell/stack/issues/1714 > > Another workaround as I understand it is to just invoke stack always > with --no-system-ghc for now. > > As to where to turn for help, I think the usual sources all would work — > irc, slack, mailinglists (such as cafe — look, it worked!), stackoverflow, > etc. > > Hope this helps, > Gershom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyday567 at gmail.com Tue Sep 27 09:03:49 2016 From: tonyday567 at gmail.com (Tony Day) Date: Tue, 27 Sep 2016 19:03:49 +1000 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: <20160927025553.GA18295@casa.casa> Message-ID: Thanks to you both. > mailinglists (such as cafe — look, it worked!) I'm totally sold on this new-fangled mailing list thing. It's like slack for adults who like to shuffle at their own pace. > Not thorough enough I say, as a sworn enemy. I'm not really - I was kind of glad when they installed Haskell Platform with batteries so I could prove a point, if only to myself, that stack was the better choice, but it's been smooth sailing except for this one bug. I've been able to install everything I need, how I need it. I imagine there's a system ghc out there somewhere, but it's benign to my workflow. I think I unfairly identify HP with cabal hell, and then the flashbacks trigger. On Tue, Sep 27, 2016 at 5:50 PM, Gershom B wrote: > On September 27, 2016 at 3:37:40 AM, Tony Day (tonyday567 at gmail.com) > wrote: > > > I even have a > > current bug falling somewhere between the platform and stack - something > > crashed looking for the standard linux command line tools - was it the > > msys2 or mingw in platform, or was it stack? Where do I even turn for > help? > > This patch should fix the issue if it is what I think it is. But the patch > is not in a release yet :-/ > > https://github.com/commercialhaskell/stack/pull/2552 > > One workaround is suggested on an associated ticket: https://github.com/ > commercialhaskell/stack/issues/1714 > > Another workaround as I understand it is to just invoke stack always > with --no-system-ghc for now. > > As to where to turn for help, I think the usual sources all would work — > irc, slack, mailinglists (such as cafe — look, it worked!), stackoverflow, > etc. > > Hope this helps, > Gershom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Tue Sep 27 15:02:54 2016 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 27 Sep 2016 11:02:54 -0400 Subject: [Haskell-cafe] technical thoughts on stack In-Reply-To: References: <9F3EB4FC-6650-4CF2-9D89-CBB5839876FD@cs.brynmawr.edu> Message-ID: <1474988574.1362325.738549905.47548AAE@webmail.messagingengine.com> On Tue, Sep 13, 2016, at 16:24, Sven Panne wrote: > > * On Windows under a MinGW bash you get a a warning for ghci: > > $ stack --resolver=nightly-2016-07-01 exec ghci -- --version > Run from outside a project, using implicit global project config > WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells > (cygwin-bash, in particular) > doesn't handle Ctrl-C well; use the 'ghcii.sh' shell > wrapper instead > The Glorious Glasgow Haskell Compilation System, version 8.0.1 > > But using ghcii.sh through stack doesn't work: > > $ stack --resolver=nightly-2016-07-01 exec ghcii.sh -- --version > Run from outside a project, using implicit global project config > > D:\Benutzer\Sven\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\bin\ghcii.sh: > createProcess: invalid argument (Exec format error) My guess is that `stack.exe` executes commands using the native Windows `CreateProcess`, which has no concept of Bash-like shell scripts (since they are a foreign thing introduced by MinGW). Perhaps try something like `stack exec sh ghcii.sh` instead? (Or `stack exec -- sh -c ` if you want to be agnostic to whether `` is a true executable or just a script.) From rae at cs.brynmawr.edu Tue Sep 27 15:28:28 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 27 Sep 2016 11:28:28 -0400 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: References: Message-ID: <5C93FBF3-45B3-49E1-9FDE-1F05765C603D@cs.brynmawr.edu> Hi Todd, My `singletons` library kludges dependent types into Haskell via much dirty Template Haskell hackery. But it works in your use case. I was able to write your reg2fsm function much as you desired. See attached. Note that my type signature for reg2fsm (`Sing (r :: RegExp) -> FSM (F r)`) is essentially a dependent type: you can view `Sing (r :: RegExp)` to be like an argument `(r : RegExp)` in a proper dependently-typed language. Alternatively, you can pronounce `Sing` as `Π`. Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: Regex.hs Type: application/octet-stream Size: 1842 bytes Desc: not available URL: -------------- next part -------------- -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 26, 2016, at 1:48 AM, Todd Wilson wrote: > > I haven't yet had the pleasure of exploring the subtleties of > dependently-typed programming in Haskell, but I'm finding myself in > need of a little bit of it in advance of that exploration and was > hoping for some suggestions. > > I have a type of regular expressions: > > data RegExp = Empty > | Letter Char > | Plus RegExp RegExp > | Cat RegExp RegExp > | Star RegExp > > and a type of (deterministic) finite state machines that is > polymorphic in the state type: > > data FSM a = FSM { > states :: [a], > start :: a, > finals :: [a], > delta :: [(a,Char,a)] > } > > I've fixed an alphabet sigma :: [Char], and I want to write the > function that converts a regular expression to its associated FSM. The > machines associated with Empty and Letter are given by > > data EmptyFSM = Etrap > emptyFSM :: FSM EmptyFSM > emptyFSM = FSM { > states = [Etrap], > start = Etrap, > finals = [], > delta = [(Etrap, c, Etrap) | c <- sigma] > } > > data LetterFSM = Lstart | Lfinal | Ltrap > letterFSM :: Char -> FSM LetterFSM > letterFSM c = FSM { > states = [Lstart, Lfinal, Ltrap], > start = Lstart, > finals = [Lfinal], > delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] ++ > [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] > } > > Suppose I can code the constructions of the union machine, > concatenation machine, and star machine so that they have the types > > unionFSM :: FSM a -> FSM b -> FSM (a,b) > catFSM :: FSM a -> FSM b -> FSM (a,[b]) > starFSM :: FSM a -> FSM [a] > > Now what I want to do is to put all of this together into a function > that takes a regular expression and returns the associated FSM. In > effect, my function should have a dependent type like > > reg2fsm :: {r : RegExp} -> FSM (f r) > > where f is the function > > f :: RegExp -> * > f Empty = EmptyFSM > f (Letter a) = LetterFSM > f (Plus r1 r2) = (f r1, f r2) > f (Cat r1 r2) = (f r1, [f r2]) > f (Star r) = [f r] > > and be given by > > reg2fsm Empty = emptyFSM > reg2fsm (Letter c) = letterFSM c > reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) > reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) > reg2fsm (Star r) = starFSM (reg2fsm r) > > What is the suggested approach to achieving this in Haskell? > > -- > Todd Wilson A smile is not an individual > Computer Science Department product; it is a co-product. > California State University, Fresno -- Thich Nhat Hanh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From olf at aatal-apotheke.de Tue Sep 27 21:25:45 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 27 Sep 2016 23:25:45 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) Message-ID: Can someone please define what exactly a "batteries included" standard library is? IMHO that Python-Haskell comparison is unfair. Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life. I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines. What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem. So please, developers: Write more batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries. Regards, Olaf From mgsloan at gmail.com Tue Sep 27 22:25:21 2016 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 27 Sep 2016 15:25:21 -0700 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: Hi Olaf! I believe I was the one to recently bring up the subject of "batteries included". I think wikipedia has a good treatment of it - https://en.wikipedia.org/wiki/Python_(programming_language)#Libraries > Python has a large standard library, commonly cited as one of Python's greatest strengths,[77] providing tools suited to many tasks. This is deliberate and has been described as a "batteries included"[29] Python philosophy. For Internet-facing applications, many standard formats and protocols (such as MIME and HTTP) are supported. Modules for creating graphical user interfaces, connecting to relational databases, pseudorandom number generators, arithmetic with arbitrary precision decimals,[78] manipulating regular expressions, and doing unit testing are also included. Happily, there are efforts underway to fix this problem for Haskell. In particular, I think the team of people working on the new foundation library has a very good chance on delivering on the promise of having batteries included for Haskell. I implore the community to give foundation a try and pitch in to make it happen. Want to make sure we don't screw up new-base? Help guide foundation's development. Here is the link: https://github.com/haskell-foundation/foundation/ Why is the Python <-> Haskell comparison unfair? We need to be realistic in our self analysis, and comparing to a very successful language can indicate what we need to do to make Haskell even more popular. Fairness does not matter. The world is not fair, it is made up of people who have a wide range of opinions and attitude. Many in the community would love to share Haskell with more people. Why? Because it is such a valuable thing to learn, and one of the best general purpose programming languages out there. Why identify Haskell as a research language, when it has so clearly grown far beyond that vision? Even if it is considered a research language, isn't it good for your research to reach the widest audience possible? This means that the fantastic ideas that make up Haskell / GHC can reach a wider audience. Some members of that audience are going to be designing future languages. Do we really want these future language designers to do that without learning Haskell? I would prefer that they learn it. I have recently had a discussion, which I find quite disturbing, where prominent community members are essentially saying that they are content with (avoiding success (at all costs)), rather than (avoiding (success at all costs)). Take a look: https://www.reddit.com/r/haskell/comments/54gm70/haskell_respect_spj/d83otar Frankly, these statements frighten and confuse me. It seems blatantly unreasonable to me, to make the statement that we should be apathetic towards marketing and lowering the barrier to entry for Haskell. Sincerely, Michael On Tue, Sep 27, 2016 at 2:25 PM, Olaf Klinke wrote: > Can someone please define what exactly a "batteries included" standard library is? IMHO that Python-Haskell comparison is unfair. Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life. > I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines. > > What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem. So please, developers: Write more batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries. > > Regards, > Olaf > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From allbery.b at gmail.com Tue Sep 27 22:32:40 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 27 Sep 2016 18:32:40 -0400 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: On Tue, Sep 27, 2016 at 5:25 PM, Olaf Klinke wrote: > Can someone please define what exactly a "batteries included" standard > library is? IMHO that Python-Haskell comparison is unfair. Although both > claim to be general-purpose languages, the focus in Haskell certainly has > been on language research for most of its life. It means that useful libraries that most projects use come with it: in a Haskell context, that would be things like text, unordered-containers, and split. It's also a bikeshed, though: for example, H-P insisted on adding OpenGL because it was felt to be important to include some kind of GUI, but the Haskell GUI story is so fragmented and messed up that it doesn't seem really worth it --- and OpenGL basically got the nod solely on being readily portable to Linux/Windows/macOS without having to hunt down extra native libraries, not because it was actually being used by itself. This led to endless discussion on the libraries list. The complications are: - libraries change quickly and dependents tend to start requiring the new versions just as quickly, rendering the batteries included obsolete almost immediately; - in the opposite direction, some libraries that come with the compiler because it uses them (notably, containers) are effectively frozen because ghc-api or TH or etc. will break. Additionally, and causing the above complications to often be fatal, ghc's own library story --- specifically cross-module inlining, which is essential for performance --- results in things which would be sensibly hidden internal details and therefore ABI-breakage-safe often leaking out into the .hi file for cross-module inlining, making the internals part of the public ABI. This is really the primary cause of ghc's library nightmares, and why other languages usually don't have these kinds of problems (but older C and C++ code sometimes did, by exposing internals in header file macros, again for speed; original mh (not nmh) and KDE 1/2 (but not 3.x or later) are examples). But you can't really generate code from Haskell with any reasonable performance unless you resort to either cross-module inlining (ghc) or whole-program compilation (jhc). :( Tools like cabal-install and stack have to do all sorts of otherwise "nonsensical extra work" to try to avoid running headlong into this. -- 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 jo at durchholz.org Tue Sep 27 23:14:15 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 28 Sep 2016 01:14:15 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: Am 27.09.2016 um 23:25 schrieb Olaf Klinke: > Can someone please define what exactly a "batteries included" > standard library is? Anything you'll typically need is already available. For some value of "typically need", so it's slightly squishy - here's a list of batteries I'd like included: - Reading/writing files - Reading over HTTP (reliably - HTTP is surprisingly complex) - Search&replace in test streams - Easy-to-use string->string maps - JSON parsing and printing (bonus points for YAML) - GUI stuff - Website stuff - Sending mails - Solid ecosystem: - build system, - library directory, - no-brainer automated testing support. (Complicated testing means more bugs in test code than in production code - this diverges.) > IMHO that Python-Haskell comparison is unfair. > Although both claim to be general-purpose languages, the focus in > Haskell certainly has been on language research for most of its life. I do not think that Python actually comes with all batteries included. And in some areas support is pretty bad. > I recently hacked together a web client in python, my first project > in that language. Documentation is excellent. Yet I am still > horrified I had to use a language that provides so few static > guarantees to control megawatt machines. That, and the idea that class and function declarations are executable statements. Circular dependencies are "handled" by passing partially-initialized objects around; the Python interpreter handles this with no problems, but programmers have fun because nobody assumes incomplete initialization. I.e. Python's language semantics is broken by design in pretty fundamental areas. That said, it's good for banging something together quickly. Been there, done that, got the t-shirt. Just don't do anything that you need a team for with it, the lack of guarantees will really start to hurt. > What puts me off Haskell nowadays is the direct result of Haskell's > roots in language research: Often when I come across a package that > does what I need, it uses the conduit, lens or another idiom, which > are like a language in a language to learn. In milder ways Python > seems to suffer the same problem. I think Python shares that problem with Lisp: it's so easy to add another meta-idiom that too many people actually do this, and most don't even think about composability or guarantees. > So please, developers: Write more > batteries, but make them expose a neat lambda calculus interface if > possible that can be combined freely with other batteries. I sense a conflict of objectives here. Having many batteries pushes you towards wide APIs. However, the wider an API, the harder it is to make it combinable. More surface that must be made to match. Making an API that's feature-complete *and* narrow is really hard and takes a huge amount of designer and programmer time, plus the willingness to lose most of your existing user base for an unproven idea of improvement. This road is a really hard one, and you need corporate backing or personal obsession to follow it. From cma at bitemyapp.com Tue Sep 27 23:21:37 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 27 Sep 2016 18:21:37 -0500 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: Batteries included is a bad idea when the community is this divided. Relative no-brainer topics in other communities like how text should be represented are highly contentious. I'd sooner see some basic test cases hammered out and integrated into base before a real attempt at this is launched. Something that would help the Cabal devs. On Tue, Sep 27, 2016 at 6:14 PM, Joachim Durchholz wrote: > Am 27.09.2016 um 23:25 schrieb Olaf Klinke: >> >> Can someone please define what exactly a "batteries included" >> standard library is? > > > Anything you'll typically need is already available. > For some value of "typically need", so it's slightly squishy - here's a list > of batteries I'd like included: > - Reading/writing files > - Reading over HTTP (reliably - HTTP is surprisingly complex) > - Search&replace in test streams > - Easy-to-use string->string maps > - JSON parsing and printing (bonus points for YAML) > - GUI stuff > - Website stuff > - Sending mails > - Solid ecosystem: > - build system, > - library directory, > - no-brainer automated testing support. > (Complicated testing means more bugs in test code than in > production code - this diverges.) > >> IMHO that Python-Haskell comparison is unfair. >> >> Although both claim to be general-purpose languages, the focus in >> Haskell certainly has been on language research for most of its life. > > > I do not think that Python actually comes with all batteries included. > And in some areas support is pretty bad. > >> I recently hacked together a web client in python, my first project >> in that language. Documentation is excellent. Yet I am still >> horrified I had to use a language that provides so few static >> guarantees to control megawatt machines. > > > That, and the idea that class and function declarations are executable > statements. > Circular dependencies are "handled" by passing partially-initialized objects > around; the Python interpreter handles this with no problems, but > programmers have fun because nobody assumes incomplete initialization. > > I.e. Python's language semantics is broken by design in pretty fundamental > areas. > > That said, it's good for banging something together quickly. Been there, > done that, got the t-shirt. > Just don't do anything that you need a team for with it, the lack of > guarantees will really start to hurt. > >> What puts me off Haskell nowadays is the direct result of Haskell's >> roots in language research: Often when I come across a package that >> does what I need, it uses the conduit, lens or another idiom, which >> are like a language in a language to learn. In milder ways Python >> seems to suffer the same problem. > > > I think Python shares that problem with Lisp: it's so easy to add another > meta-idiom that too many people actually do this, and most don't even think > about composability or guarantees. > >> So please, developers: Write more >> >> batteries, but make them expose a neat lambda calculus interface if >> possible that can be combined freely with other batteries. > > > I sense a conflict of objectives here. > Having many batteries pushes you towards wide APIs. > However, the wider an API, the harder it is to make it combinable. More > surface that must be made to match. > > Making an API that's feature-complete *and* narrow is really hard and takes > a huge amount of designer and programmer time, plus the willingness to lose > most of your existing user base for an unproven idea of improvement. This > road is a really hard one, and you need corporate backing or personal > obsession to follow it. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From johnw at newartisans.com Wed Sep 28 00:16:24 2016 From: johnw at newartisans.com (John Wiegley) Date: Tue, 27 Sep 2016 17:16:24 -0700 Subject: [Haskell-cafe] Batteries included In-Reply-To: (Christopher Allen's message of "Tue, 27 Sep 2016 18:21:37 -0500") References: Message-ID: >>>>> "CA" == Christopher Allen writes: CA> Batteries included is a bad idea when the community is this divided. CA> Relative no-brainer topics in other communities like how text should be CA> represented are highly contentious. Our community is not "divided", it simply has a large number of interests, meaning there is rarely a single standard library choice that benefits all groups equally: academic, pedagogic, hobbyist, commercial, etc. And exactly because we're not divided, we naturally avoid favoring the needs of one group over another. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From monkleyon at googlemail.com Wed Sep 28 05:47:20 2016 From: monkleyon at googlemail.com (MarLinn) Date: Wed, 28 Sep 2016 07:47:20 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: <32c20527-5447-afb0-f47d-de2cc5c7d1ca@gmail.com> On 2016-09-28 00:32, Brandon Allbery wrote: > > Can someone please define what exactly a "batteries included" > standard library is? > > > The complications are: > > - libraries change quickly and dependents tend to start requiring the > new versions just as quickly, rendering the batteries included > obsolete almost immediately; > - in the opposite direction, some libraries that come with the > compiler because it uses them (notably, containers) are effectively > frozen because ghc-api or TH or etc. will break. This makes me think the "batteries included" metaphor is the wrong line of thinking for Haskell. Our environment is more like "direct access to the power lines", thanks to hackage and cabal. The potential downside is that "powerlines at your fingertips" can lead to cases of "plug and fry (your brain)". But then why should the environment be dumbed down to low-voltage batteries when the high-voltage-network is part of what got it to where it is? MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Wed Sep 28 06:06:16 2016 From: imantc at gmail.com (Imants Cekusins) Date: Wed, 28 Sep 2016 08:06:16 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <32c20527-5447-afb0-f47d-de2cc5c7d1ca@gmail.com> References: <32c20527-5447-afb0-f47d-de2cc5c7d1ca@gmail.com> Message-ID: > why should the environment be dumbed down to low-voltage batteries well "Hello world" should be simple also for someone who never heard of Haskell before. So no harm in providing the batteries. Open the box, skip the instruction, turn it on. ​ On the other hand, it is reasonable to expect to be able to switch between the batteries and the mains. Replace power supply unit, even. I don't see why all these options should not be available or why they conflict. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Wed Sep 28 06:29:03 2016 From: tonymorris at gmail.com (Tony Morris) Date: Wed, 28 Sep 2016 16:29:03 +1000 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> There is nothing of merit in Python libraries to be learned. Please don't ruin Haskell to the point of Python. On 28/09/16 08:25, Michael Sloan wrote: > Hi Olaf! > > I believe I was the one to recently bring up the subject of "batteries > included". I think wikipedia has a good treatment of it - > https://en.wikipedia.org/wiki/Python_(programming_language)#Libraries > >> Python has a large standard library, commonly cited as one of Python's greatest strengths,[77] providing tools suited to many tasks. This is deliberate and has been described as a "batteries included"[29] Python philosophy. For Internet-facing applications, many standard formats and protocols (such as MIME and HTTP) are supported. Modules for creating graphical user interfaces, connecting to relational databases, pseudorandom number generators, arithmetic with arbitrary precision decimals,[78] manipulating regular expressions, and doing unit testing are also included. > Happily, there are efforts underway to fix this problem for Haskell. > In particular, I think the team of people working on the new > foundation library has a very good chance on delivering on the promise > of having batteries included for Haskell. I implore the community to > give foundation a try and pitch in to make it happen. Want to make > sure we don't screw up new-base? Help guide foundation's development. > Here is the link: > > https://github.com/haskell-foundation/foundation/ > > Why is the Python <-> Haskell comparison unfair? We need to be > realistic in our self analysis, and comparing to a very successful > language can indicate what we need to do to make Haskell even more > popular. > > Fairness does not matter. The world is not fair, it is made up of > people who have a wide range of opinions and attitude. Many in the > community would love to share Haskell with more people. Why? Because > it is such a valuable thing to learn, and one of the best general > purpose programming languages out there. > > Why identify Haskell as a research language, when it has so clearly > grown far beyond that vision? Even if it is considered a research > language, isn't it good for your research to reach the widest audience > possible? This means that the fantastic ideas that make up Haskell / > GHC can reach a wider audience. Some members of that audience are > going to be designing future languages. Do we really want these > future language designers to do that without learning Haskell? I > would prefer that they learn it. > > I have recently had a discussion, which I find quite disturbing, where > prominent community members are essentially saying that they are > content with (avoiding success (at all costs)), rather than (avoiding > (success at all costs)). Take a look: > https://www.reddit.com/r/haskell/comments/54gm70/haskell_respect_spj/d83otar > > Frankly, these statements frighten and confuse me. It seems blatantly > unreasonable to me, to make the statement that we should be apathetic > towards marketing and lowering the barrier to entry for Haskell. > > Sincerely, > Michael > > On Tue, Sep 27, 2016 at 2:25 PM, Olaf Klinke wrote: >> Can someone please define what exactly a "batteries included" standard library is? IMHO that Python-Haskell comparison is unfair. Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life. >> I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines. >> >> What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem. So please, developers: Write more batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries. >> >> Regards, >> Olaf >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From jo at durchholz.org Wed Sep 28 06:32:06 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 28 Sep 2016 08:32:06 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <32c20527-5447-afb0-f47d-de2cc5c7d1ca@gmail.com> References: <32c20527-5447-afb0-f47d-de2cc5c7d1ca@gmail.com> Message-ID: Am 28.09.2016 um 07:47 schrieb MarLinn via Haskell-Cafe: > The potential downside is > that "powerlines at your fingertips" can lead to cases of "plug and fry > (your brain)". But then why should the environment be dumbed down to > low-voltage batteries when the high-voltage-network is part of what got > it to where it is? You already said it: Because people will fry their brain. "Powerlines at your fingertips" doesn't apply to Haskell, that's C++ and (if you will) C as well. Haskell is more like household AC: All the power that you need on a day-to-day basis, but carefully shielded, safeguarded and geared towards useful work instead of fry-your-brain accidents. You can disable the safeguards (UnsafeIO) and you better know what you're doing, though it's still not a case of nasal demons. From twilson at csufresno.edu Wed Sep 28 06:40:40 2016 From: twilson at csufresno.edu (Todd Wilson) Date: Tue, 27 Sep 2016 23:40:40 -0700 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: <7876545b-8f72-6709-c603-cd4f6b5fc8e5@ens.fr> References: <7876545b-8f72-6709-c603-cd4f6b5fc8e5@ens.fr> Message-ID: I actually tried the approach of indexing the RegExp type before, but I didn't like it for the reason you indicated: I was also using RegExp for many other purposes that have nothing to do with FSMs and I didn't want to be forced to include the superfluous type indices in those situations. On the other hand, for the reg2fsm function, I wanted to use the extra type information to limit the space of solutions: the existence of my function f :: RegExp -> * was meant to guide the constructions that students might write. --Todd On Mon, Sep 26, 2016 at 1:51 AM, Li-yao Xia wrote: > Hello Todd, > > This seems like a neat place to use GADTs! > > Instead of trying to define f :: RegExp -> * by fully lifting RegExp to the > type level, you can use GADTs to reflect the structure of a RegExp in its > type: > > > data RegExp a where > -- a is the state type of the FSM associated with the regexp > Empty :: RegExp EmptyFSM > Letter :: RegExp LetterFSM > Plus :: RegExp a -> RegExp b -> RegExp (a, b) > Cat :: RegExp a -> RegExp b -> RegExp (a, [b]) > Star :: RegExp a -> RegExp [a] > > reg2fsm :: Eq a => RegExp a -> FSM a > -- ^ I assume you'll need an Eq constraint here to normalize > -- the "non-deterministic states". > > > It may be much less flexible than what you originally intended, because the > RegExp type is now tied to your FSM implementation. RegExps might also > become painful to pass around because of their too explicit type. If that > happens to be the case, you can clean up an API which uses this regexp with > an existential wrapper. > > > data SomeRegExp where > SomeRegExp :: Eq a => RegExp a -> SomeRegExp > > data SomeFSM where > SomeFSM :: Eq a => FSM a -> SomeFSM > > > Another simpler solution is to only use such a wrapper around FSM (i.e., > your output), keeping the RegExp type as you first wrote it. You'd have: > > > reg2fsm :: RegExp -> SomeFSM > > > Here you totally lose the relationship between the RegExp and the FSM, so it > seems to move away from what you were looking for. But if ultimately you > don't care about the actual type of the state of a FSM, this gets the job > done. > > Regards, > Li-yao > > > On 09/26/2016 06:48 AM, Todd Wilson wrote: >> >> I haven't yet had the pleasure of exploring the subtleties of >> dependently-typed programming in Haskell, but I'm finding myself in >> need of a little bit of it in advance of that exploration and was >> hoping for some suggestions. >> >> I have a type of regular expressions: >> >> data RegExp = Empty >> | Letter Char >> | Plus RegExp RegExp >> | Cat RegExp RegExp >> | Star RegExp >> >> and a type of (deterministic) finite state machines that is >> polymorphic in the state type: >> >> data FSM a = FSM { >> states :: [a], >> start :: a, >> finals :: [a], >> delta :: [(a,Char,a)] >> } >> >> I've fixed an alphabet sigma :: [Char], and I want to write the >> function that converts a regular expression to its associated FSM. The >> machines associated with Empty and Letter are given by >> >> data EmptyFSM = Etrap >> emptyFSM :: FSM EmptyFSM >> emptyFSM = FSM { >> states = [Etrap], >> start = Etrap, >> finals = [], >> delta = [(Etrap, c, Etrap) | c <- sigma] >> } >> >> data LetterFSM = Lstart | Lfinal | Ltrap >> letterFSM :: Char -> FSM LetterFSM >> letterFSM c = FSM { >> states = [Lstart, Lfinal, Ltrap], >> start = Lstart, >> finals = [Lfinal], >> delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] >> ++ >> [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] >> } >> >> Suppose I can code the constructions of the union machine, >> concatenation machine, and star machine so that they have the types >> >> unionFSM :: FSM a -> FSM b -> FSM (a,b) >> catFSM :: FSM a -> FSM b -> FSM (a,[b]) >> starFSM :: FSM a -> FSM [a] >> >> Now what I want to do is to put all of this together into a function >> that takes a regular expression and returns the associated FSM. In >> effect, my function should have a dependent type like >> >> reg2fsm :: {r : RegExp} -> FSM (f r) >> >> where f is the function >> >> f :: RegExp -> * >> f Empty = EmptyFSM >> f (Letter a) = LetterFSM >> f (Plus r1 r2) = (f r1, f r2) >> f (Cat r1 r2) = (f r1, [f r2]) >> f (Star r) = [f r] >> >> and be given by >> >> reg2fsm Empty = emptyFSM >> reg2fsm (Letter c) = letterFSM c >> reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) >> reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) >> reg2fsm (Star r) = starFSM (reg2fsm r) >> >> What is the suggested approach to achieving this in Haskell? >> >> -- >> Todd Wilson A smile is not an individual >> Computer Science Department product; it is a co-product. >> California State University, Fresno -- Thich Nhat Hanh >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > From twilson at csufresno.edu Wed Sep 28 06:49:33 2016 From: twilson at csufresno.edu (Todd Wilson) Date: Tue, 27 Sep 2016 23:49:33 -0700 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: <5C93FBF3-45B3-49E1-9FDE-1F05765C603D@cs.brynmawr.edu> References: <5C93FBF3-45B3-49E1-9FDE-1F05765C603D@cs.brynmawr.edu> Message-ID: Richard, Thanks for this suggestion. I wasn't aware of the singletons library; I'll have to take a look. To you and the other readers of this thread: are there other approaches that have not yet been suggested? Since I'm using this for a series of assignments for students that have seen Haskell before but are still relative beginners, I'm looking for something that will be relatively easy to explain, won't get in the way of them writing the constructions in the straightforward way, and yet will provide some additional type-checking to help catch their errors. --Todd On Tue, Sep 27, 2016 at 8:28 AM, Richard Eisenberg wrote: > Hi Todd, > > My `singletons` library kludges dependent types into Haskell via much dirty Template Haskell hackery. But it works in your use case. I was able to write your reg2fsm function much as you desired. > > See attached. > > Note that my type signature for reg2fsm (`Sing (r :: RegExp) -> FSM (F r)`) is essentially a dependent type: you can view `Sing (r :: RegExp)` to be like an argument `(r : RegExp)` in a proper dependently-typed language. Alternatively, you can pronounce `Sing` as `Π`. > > Richard > > > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > >> On Sep 26, 2016, at 1:48 AM, Todd Wilson wrote: >> >> I haven't yet had the pleasure of exploring the subtleties of >> dependently-typed programming in Haskell, but I'm finding myself in >> need of a little bit of it in advance of that exploration and was >> hoping for some suggestions. >> >> I have a type of regular expressions: >> >> data RegExp = Empty >> | Letter Char >> | Plus RegExp RegExp >> | Cat RegExp RegExp >> | Star RegExp >> >> and a type of (deterministic) finite state machines that is >> polymorphic in the state type: >> >> data FSM a = FSM { >> states :: [a], >> start :: a, >> finals :: [a], >> delta :: [(a,Char,a)] >> } >> >> I've fixed an alphabet sigma :: [Char], and I want to write the >> function that converts a regular expression to its associated FSM. The >> machines associated with Empty and Letter are given by >> >> data EmptyFSM = Etrap >> emptyFSM :: FSM EmptyFSM >> emptyFSM = FSM { >> states = [Etrap], >> start = Etrap, >> finals = [], >> delta = [(Etrap, c, Etrap) | c <- sigma] >> } >> >> data LetterFSM = Lstart | Lfinal | Ltrap >> letterFSM :: Char -> FSM LetterFSM >> letterFSM c = FSM { >> states = [Lstart, Lfinal, Ltrap], >> start = Lstart, >> finals = [Lfinal], >> delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] ++ >> [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] >> } >> >> Suppose I can code the constructions of the union machine, >> concatenation machine, and star machine so that they have the types >> >> unionFSM :: FSM a -> FSM b -> FSM (a,b) >> catFSM :: FSM a -> FSM b -> FSM (a,[b]) >> starFSM :: FSM a -> FSM [a] >> >> Now what I want to do is to put all of this together into a function >> that takes a regular expression and returns the associated FSM. In >> effect, my function should have a dependent type like >> >> reg2fsm :: {r : RegExp} -> FSM (f r) >> >> where f is the function >> >> f :: RegExp -> * >> f Empty = EmptyFSM >> f (Letter a) = LetterFSM >> f (Plus r1 r2) = (f r1, f r2) >> f (Cat r1 r2) = (f r1, [f r2]) >> f (Star r) = [f r] >> >> and be given by >> >> reg2fsm Empty = emptyFSM >> reg2fsm (Letter c) = letterFSM c >> reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) >> reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) >> reg2fsm (Star r) = starFSM (reg2fsm r) >> >> What is the suggested approach to achieving this in Haskell? >> >> -- >> Todd Wilson A smile is not an individual >> Computer Science Department product; it is a co-product. >> California State University, Fresno -- Thich Nhat Hanh >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > From twilson at csufresno.edu Wed Sep 28 07:05:09 2016 From: twilson at csufresno.edu (Todd Wilson) Date: Wed, 28 Sep 2016 00:05:09 -0700 Subject: [Haskell-cafe] Type of divMod Message-ID: Why is the type of divMod not (Integral a, Integral b) => a -> b -> (a,b)? It would seem to make sense that if b is a size-limited Integral type (like Int), then since the remainder of a division is always smaller than the divisor, it could be given the same size-limited type. I found myself wanting such instances of divMod when writing a function to convert an Integer to a list of digits in some base that is an Int: toBase :: Integer -> Int -> [Int] I can work around not having the appropriate instance of divMod by using fromIntegral to convert from an Integer to an Int, but this seems wrong. Todd Wilson A smile is not an individual Computer Science Department product; it is a co-product. California State University, Fresno -- Thich Nhat Hanh From jo at durchholz.org Wed Sep 28 07:06:58 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 28 Sep 2016 09:06:58 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> Message-ID: <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> Am 28.09.2016 um 08:29 schrieb Tony Morris: > There is nothing of merit in Python libraries to be learned. That's almost true, but not 100%. E.g. does Haskell have doctests? I.e. you can write example code in the API-level docs, and there is tooling that can extract them, run them, and report whether the examples still work. There's also the old motto of "nothing is completely useless, it can still serve as a bad example". > Please > don't ruin Haskell to the point of Python. The Python stdlib is a collection of things people needed. So if you want a list of batteries that Haskell might be missing, Python's stdlib is a good shopping list. You don't want to copy the library API structure, but that danger is negligible. Python is even more imperative than C++ or Java, it's dynamically typed, and with these concept differences, what's a good library design in Python that leverages all the things that Python is good at is almost automatically neither desirable nor even possible in Haskell. From tonymorris at gmail.com Wed Sep 28 07:09:14 2016 From: tonymorris at gmail.com (Tony Morris) Date: Wed, 28 Sep 2016 17:09:14 +1000 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> Message-ID: <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> On 28/09/16 17:06, Joachim Durchholz wrote: > Am 28.09.2016 um 08:29 schrieb Tony Morris: >> There is nothing of merit in Python libraries to be learned. > > That's almost true, but not 100%. > E.g. does Haskell have doctests? I.e. you can write example code in > the API-level docs, and there is tooling that can extract them, run > them, and report whether the examples still work. I've been doing that for years, with the exception that doing so in Haskell is far superior than in Python for reasons too long to list. https://hackage.haskell.org/package/doctest > > There's also the old motto of "nothing is completely useless, it can > still serve as a bad example". > > > Please >> don't ruin Haskell to the point of Python. > > The Python stdlib is a collection of things people needed. So if you > want a list of batteries that Haskell might be missing, Python's > stdlib is a good shopping list. Where is the useful bit? I have only heard of it, never actually seen it. > You don't want to copy the library API structure, but that danger is > negligible. Python is even more imperative than C++ or Java, it's > dynamically typed, and with these concept differences, what's a good > library design in Python that leverages all the things that Python is > good at is almost automatically neither desirable nor even possible in > Haskell. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From voldermort at hotmail.com Wed Sep 28 07:22:41 2016 From: voldermort at hotmail.com (Peter) Date: Wed, 28 Sep 2016 00:22:41 -0700 (MST) Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> Message-ID: <1475047361700-5843416.post@n5.nabble.com> What are the advantages of batteries included? 1) It's easier for newcomers to find the appropriate library for common tasks. 2) Consistency between different programs, as they will mostly use the same standard libraries for common tasks. Do these require the batteries to be installed with the compiler? Do they require the batteries to be installed as a monolithic unit at all? An "official" wiki page pointing to the recommended packages for common tasks would seem to achieve the purpose almost as well, but without the accompanying problems. As for sets of specific library versions that are known to work well together, Stackage has already solved that. -- View this message in context: http://haskell.1045720.n5.nabble.com/Re-Batteries-included-Was-GHC-is-a-monopoly-compiler-tp5843366p5843416.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From jo at durchholz.org Wed Sep 28 08:13:51 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 28 Sep 2016 10:13:51 +0200 Subject: [Haskell-cafe] Haskell doctest In-Reply-To: <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> Message-ID: Am 28.09.2016 um 09:09 schrieb Tony Morris: > > > On 28/09/16 17:06, Joachim Durchholz wrote: >> Am 28.09.2016 um 08:29 schrieb Tony Morris: >>> There is nothing of merit in Python libraries to be learned. >> >> That's almost true, but not 100%. >> E.g. does Haskell have doctests? I.e. you can write example code in >> the API-level docs, and there is tooling that can extract them, run >> them, and report whether the examples still work. > > I've been doing that for years, with the exception that doing so in > Haskell is far superior than in Python for reasons too long to list. > > https://hackage.haskell.org/package/doctest Ah, sweet. > for reasons too long to list. Can somebody with a similar long-time working experience in Haskell doctests provide such a list? It would be helpful in more than one way: It would help advocate Haskell, and to the kind of audience that is interested in high quality so it's a double win; and it would help other language communities improve their doctest ecosystem, and I think that's what most multi-language people would very much like to happen. Regards, Jo From fw at deneb.enyo.de Wed Sep 28 11:18:14 2016 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 28 Sep 2016 13:18:14 +0200 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: (Michael Sloan's message of "Mon, 26 Sep 2016 20:11:28 -0700") References: <20160927025553.GA18295@casa.casa> Message-ID: <87wphwi87d.fsf@mid.deneb.enyo.de> * Michael Sloan: > So in other words, the Python guys knew that an approach like Haskell > Platform would never work well, and so they didn't do it. Instead > they built one big excellent standard library. But this approach causes problems. There are quite a few example where Python got things wrong and did not fix them for a long time due to backwards compatibility concerns. Examples are HTTPS with host name validation, and email parsing. The trouble is that if you get it wrong, you still have to support it for a long time (perhaps eternally) because your users want to upgrade the platform without rewriting their software. In the Haskell context, an early batteries-included version of the standard library would likely have relied extensively on strings-as-lists and lazy I/O, and the latter is somewhat controversial these days (the former is rather inefficient). From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Sep 28 11:46:10 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 28 Sep 2016 12:46:10 +0100 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: References: Message-ID: <20160928114610.GH30717@weber> On Mon, Sep 26, 2016 at 08:56:55PM -0500, Christopher Allen wrote: > Streaming is a good example here. It's not "obvious" how to do many > things in Haskell that are "obvious" in other languages. Partly > because industry hasn't used languages like Haskell much, partly > because the canvas we work with permits more structure. Is it obvious how to do streaming in other languages? From carter.schonwald at gmail.com Wed Sep 28 11:59:53 2016 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 28 Sep 2016 07:59:53 -0400 Subject: [Haskell-cafe] [Haskell] GHC is a monopoly compiler In-Reply-To: <20160928114610.GH30717@weber> References: <20160928114610.GH30717@weber> Message-ID: Nope :) And I think we are still learning how to do stream. Have have streaming in a line down pat, but streaming with a DAG or general graphs wendontnhave yet ;) On Wednesday, September 28, 2016, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Mon, Sep 26, 2016 at 08:56:55PM -0500, Christopher Allen wrote: > > Streaming is a good example here. It's not "obvious" how to do many > > things in Haskell that are "obvious" in other languages. Partly > > because industry hasn't used languages like Haskell much, partly > > because the canvas we work with permits more structure. > > Is it obvious how to do streaming in other languages? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmoskvin at gmail.com Wed Sep 28 12:00:57 2016 From: dmoskvin at gmail.com (Denis Moskvin) Date: Wed, 28 Sep 2016 15:00:57 +0300 Subject: [Haskell-cafe] seq and lambda with patterns Message-ID: There is some subtle, but reasonable difference between \pat1 pat2 -> expr and \pat1 -> \pat2 -> expr: > seq ((\True y -> "DEFINED") undefined) 42 42 > seq ((\True -> \y -> "DEFINED") undefined) 42 *** Exception: Prelude.undefined The reason is the translation from Haskell Report 2010 (3.3) \ p1 . . . pn -> e = \ x1 . . . xn -> case (x1 , . . . , xn ) of (p1 , . . . , pn ) -> e Today I found (GHC 8.0.1) that > seq ((\True -> \y -> undefined) undefined) 42 42 Is the last result correct? -- Denis Moskvin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Wed Sep 28 12:18:34 2016 From: gurudev.devanla at gmail.com (Gurudev Devanla) Date: Wed, 28 Sep 2016 05:18:34 -0700 (PDT) Subject: [Haskell-cafe] Unable to register on hackage Message-ID: <1348fa5e-bb3d-4d0e-a406-96d0669d798a@googlegroups.com> Hello, This may be the wrong mailing list for this question, but I appreciate any pointers on whom to contact. I have been unable to register as a new user on https://hackage.haskell.org to upload a package. I have tried number of times, but have not received the activation email. I have also not found any "Contact" links on that page. Therefore, any pointers would be of great help. Regards Guru -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Sep 28 12:19:43 2016 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 28 Sep 2016 12:19:43 +0000 Subject: [Haskell-cafe] Batteries included In-Reply-To: References: Message-ID: | Our community is not "divided", it simply has a large number of | interests, meaning there is rarely a single standard library choice | that benefits all groups equally: academic, pedagogic, hobbyist, | commercial, etc. And exactly because we're not divided, we naturally | avoid favoring the needs of one group over another. Bravo John! You have re-framed the challenge (for challenge it is) as in a constructive way, one that acknowledges or even celebrates our differences, and encourages us to work together. Thank you. Simon | -----Original Message----- | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf | Of John Wiegley | Sent: 28 September 2016 01:16 | To: Christopher Allen | Cc: Haskell Cafe | Subject: Re: [Haskell-cafe] Batteries included | | >>>>> "CA" == Christopher Allen writes: | | CA> Batteries included is a bad idea when the community is this | divided. | CA> Relative no-brainer topics in other communities like how text | should | CA> be represented are highly contentious. | | Our community is not "divided", it simply has a large number of | interests, meaning there is rarely a single standard library choice | that benefits all groups equally: academic, pedagogic, hobbyist, | commercial, etc. And exactly because we're not divided, we naturally | avoid favoring the needs of one group over another. | | -- | John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B | B80F | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnewart | isans.com&data=01%7C01%7Csimonpj%40microsoft.com%7C9ca50ffb913e4bd8d85 | e08d3e734b644%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=1cmogRP206x | YBhVlCDmjtd9LWhASaSAVCVkYxEhYAak%3D&reserved=0 | 60E1 46C4 BD1A 7AC1 4BA2 | _______________________________________________ | Haskell-Cafe mailing list | To (un)subscribe, modify options or view archives go to: | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell- | cafe&data=01%7C01%7Csimonpj%40microsoft.com%7C9ca50ffb913e4bd8d85e08d3 | e734b644%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=r9Yrp3gngUbqhn0u | qgpfNaKEEhFwukLZBIeKcvDPrrc%3D&reserved=0 | Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed Sep 28 12:28:18 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 28 Sep 2016 13:28:18 +0100 Subject: [Haskell-cafe] seq and lambda with patterns In-Reply-To: References: Message-ID: <20160928122818.GJ30717@weber> On Wed, Sep 28, 2016 at 03:00:57PM +0300, Denis Moskvin wrote: > There is some subtle, but reasonable difference between \pat1 pat2 -> expr > and \pat1 -> \pat2 -> expr: > > > seq ((\True y -> "DEFINED") undefined) 42 > 42 > > seq ((\True -> \y -> "DEFINED") undefined) 42 > *** Exception: Prelude.undefined > > The reason is the translation from Haskell Report 2010 (3.3) > \ p1 . . . pn -> e = \ x1 . . . xn -> case (x1 , . . . , xn ) of (p1 , . . > . , pn ) -> e > > > Today I found (GHC 8.0.1) that > > > seq ((\True -> \y -> undefined) undefined) 42 > 42 > > Is the last result correct? According to the Haskell report this is seq ((\x -> case x of True -> (\y -> undefined)) undefined) 42 and evaluation proceeds to case undefined of True -> (\y -> undefined)) and thus to undefined So I agree with you that there's something fishy here. Tom From hesselink at gmail.com Wed Sep 28 13:08:18 2016 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 28 Sep 2016 15:08:18 +0200 Subject: [Haskell-cafe] Unable to register on hackage In-Reply-To: References: <1348fa5e-bb3d-4d0e-a406-96d0669d798a@googlegroups.com> Message-ID: For future reference, the right address here is admin at hackage.haskell.org, which I admit seems to be hard to find on hackage (although it's there on the homepage and Guru found it eventually). I'm looking into this. Erik > On 28 September 2016 at 14:18, Gurudev Devanla > wrote: > >> Hello, >> >> This may be the wrong mailing list for this question, but I appreciate >> any pointers on whom to contact. I have been unable to register as a new >> user on https://hackage.haskell.org to upload a package. I have tried >> number of times, but have not received the activation email. >> >> I have also not found any "Contact" links on that page. Therefore, any >> pointers would be of great help. >> >> Regards >> Guru >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.caught.air at gmail.com Wed Sep 28 13:53:16 2016 From: i.caught.air at gmail.com (Alex Belanger) Date: Wed, 28 Sep 2016 09:53:16 -0400 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> <1475047361700-5843416.post@n5.nabble.com> Message-ID: Just a reminder, I think Haskell (the language) is being conflated by `base` (the library). `base` has exactly the minimum required for GHC to bootstrap and compile itself. If you guys are interested in an `other-base`, then do it and list that as a dependency in your cabal file. You choose your dependencies by relevance, but it doesn't affect what Haskell is or capable of. The whole point of having even `base` be a library (and extensions) is what allow Haskell to be such a good research language. No need to discuss morals on a non-existant problem. Go ahead and make a different base. Companies do this all the time. Alex. On Sep 28, 2016 3:22 AM, "Peter" wrote: What are the advantages of batteries included? 1) It's easier for newcomers to find the appropriate library for common tasks. 2) Consistency between different programs, as they will mostly use the same standard libraries for common tasks. Do these require the batteries to be installed with the compiler? Do they require the batteries to be installed as a monolithic unit at all? An "official" wiki page pointing to the recommended packages for common tasks would seem to achieve the purpose almost as well, but without the accompanying problems. As for sets of specific library versions that are known to work well together, Stackage has already solved that. -- View this message in context: http://haskell.1045720.n5. nabble.com/Re-Batteries-included-Was-GHC-is-a-monopoly-compiler- tp5843366p5843416.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at vilem.net Wed Sep 28 14:06:01 2016 From: mail at vilem.net (Vilem-Benjamin Liepelt) Date: Wed, 28 Sep 2016 15:06:01 +0100 Subject: [Haskell-cafe] Batteries included In-Reply-To: References: Message-ID: I am new to this mailing list and this was the first conversation I took note of. I study computer science at university and have become very interested in Haskell privately, devoting a large portion of my free time to it. I dream of finding a job with Haskell for my industry placement next year or at least after I finish university. I also have hopes of some day working in a world where the ideas and knowledge incubated in Haskell break the shackles of current OOrthodoxy. While I am aware that I haven't contributed anything to the community yet, I still thought it might be helpful if I made you aware that the tone of some parts of this conversation were rather bewildering to me, because to date I have perceived the community around Haskell to be made up of mainly extremely devoted and respectful individuals. I believe many newcomers would feel similar. The style of this conversation honestly cast a temporary doubt over the noble notions that Haskell has been standing for in my mind, as I came under the impression that this must be the usual tone around here. I dearly hope that this is not the case. I am somewhat relieved with John Wiegley's and SPJ's words, as well as some other conversations on this mailing list that seem to be rather more respectful. This may seem like another good reason to “avoid success at all cost” — to keep away trolls from this amazing project; but please don't let bashers endanger Haskell's success. Haskell needs an open-minded and educated community, which I am striving to be part of. Vilem > On 28 Sep 2016, at 13:19, Simon Peyton Jones via Haskell-Cafe wrote: > > | Our community is not "divided", it simply has a large number of > | interests, meaning there is rarely a single standard library choice > | that benefits all groups equally: academic, pedagogic, hobbyist, > | commercial, etc. And exactly because we're not divided, we naturally > | avoid favoring the needs of one group over another. > > Bravo John! You have re-framed the challenge (for challenge it is) as in a constructive way, one that acknowledges or even celebrates our differences, and encourages us to work together. Thank you. > > Simon > > | -----Original Message----- > | From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf > | Of John Wiegley > | Sent: 28 September 2016 01:16 > | To: Christopher Allen > | Cc: Haskell Cafe > | Subject: Re: [Haskell-cafe] Batteries included > | > | >>>>> "CA" == Christopher Allen writes: > | > | CA> Batteries included is a bad idea when the community is this > | divided. > | CA> Relative no-brainer topics in other communities like how text > | should > | CA> be represented are highly contentious. > | > | Our community is not "divided", it simply has a large number of > | interests, meaning there is rarely a single standard library choice > | that benefits all groups equally: academic, pedagogic, hobbyist, > | commercial, etc. And exactly because we're not divided, we naturally > | avoid favoring the needs of one group over another. > | > | -- > | John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B > | B80F > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnewart > | isans.com&data=01%7C01%7Csimonpj%40microsoft.com%7C9ca50ffb913e4bd8d85 > | e08d3e734b644%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=1cmogRP206x > | YBhVlCDmjtd9LWhASaSAVCVkYxEhYAak%3D&reserved=0 > | 60E1 46C4 BD1A 7AC1 4BA2 > | _______________________________________________ > | Haskell-Cafe mailing list > | To (un)subscribe, modify options or view archives go to: > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h > | askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fhaskell- > | cafe&data=01%7C01%7Csimonpj%40microsoft.com%7C9ca50ffb913e4bd8d85e08d3 > | e734b644%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=r9Yrp3gngUbqhn0u > | qgpfNaKEEhFwukLZBIeKcvDPrrc%3D&reserved=0 > | Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From althainz at gmail.com Wed Sep 28 14:55:50 2016 From: althainz at gmail.com (Peter Althainz) Date: Wed, 28 Sep 2016 16:55:50 +0200 Subject: [Haskell-cafe] HGamer3D - website refresh - space invaders clone Message-ID: Dear All, the http://www.hgamer3d.org website now comes with some updates: slides from Haskell Leipzig 2016 link, more explanations, aio tool explained, space invaders game. regards Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Sep 28 14:59:00 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 28 Sep 2016 10:59:00 -0400 Subject: [Haskell-cafe] Batteries included In-Reply-To: References: Message-ID: <1475074740.2685.14.camel@joachim-breitner.de> Hi, Am Mittwoch, den 28.09.2016, 15:06 +0100 schrieb Vilem-Benjamin Liepelt: > The style of this conversation honestly cast a temporary doubt over > the noble notions that Haskell has been standing for in my mind, as I > came under the impression that this must be the usual tone around > here. > > I dearly hope that this is not the case. it is not. We are usually very helpful and friendly people. Occasionally thread like this pops up, but I guess many start ignoring it (if only due to the sheer size). A bit unfortunate that this is your first impression, but I’m confident that you’ll get better impressions as time passes on. Greetings and enjoy Haskell, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From mail at vilem.net Wed Sep 28 15:09:11 2016 From: mail at vilem.net (Vilem-Benjamin Liepelt) Date: Wed, 28 Sep 2016 16:09:11 +0100 Subject: [Haskell-cafe] Batteries included In-Reply-To: <1475074740.2685.14.camel@joachim-breitner.de> References: <1475074740.2685.14.camel@joachim-breitner.de> Message-ID: That's so great to hear, thanks, Joachim! Best wishes, Vilem > On 28 Sep 2016, at 15:59, Joachim Breitner wrote: > > Hi, > > Am Mittwoch, den 28.09.2016, 15:06 +0100 schrieb Vilem-Benjamin > Liepelt: >> The style of this conversation honestly cast a temporary doubt over >> the noble notions that Haskell has been standing for in my mind, as I >> came under the impression that this must be the usual tone around >> here. >> >> I dearly hope that this is not the case. > > it is not. We are usually very helpful and friendly people. > Occasionally thread like this pops up, but I guess many start ignoring > it (if only due to the sheer size). > > A bit unfortunate that this is your first impression, but I’m confident > that you’ll get better impressions as time passes on. > > Greetings and enjoy Haskell, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org_______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From mafagafogigante at gmail.com Wed Sep 28 15:28:24 2016 From: mafagafogigante at gmail.com (Bernardo Sulzbach) Date: Wed, 28 Sep 2016 12:28:24 -0300 Subject: [Haskell-cafe] Type of divMod In-Reply-To: References: Message-ID: On 09/28/2016 04:05 AM, Todd Wilson wrote: > Why is the type of divMod not > > (Integral a, Integral b) => a -> b -> (a,b)? > > It would seem to make sense that if b is a size-limited Integral type > (like Int), then since the remainder of a division is always smaller > than the divisor, it could be given the same size-limited type. > The absolute value of the remainder of a division is always smaller than the absolute value of the divisor, right? -- Similar reasoning could be transferred to mod. I don't know why it isn't as you suggested. However, I find the current way simpler and easier to understand. If someone knows why we have [divMod :: a -> a -> (a, a)], please comment on it. -- Bernardo Sulzbach http://www.mafagafogigante.org/ mafagafogigante at mafagafogigante.org From rae at cs.brynmawr.edu Wed Sep 28 16:39:06 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 28 Sep 2016 12:39:06 -0400 Subject: [Haskell-cafe] A question on dependent types in Haskell In-Reply-To: References: <5C93FBF3-45B3-49E1-9FDE-1F05765C603D@cs.brynmawr.edu> Message-ID: <9DA840DC-CA71-4FEA-A696-14251902A437@cs.brynmawr.edu> Hi Todd, I’m afraid dependent types in today’s Haskell are not for the faint-of-heart, or any but the most advanced students. Indeed, as I’ve been thinking about my new course on typed functional programming for the spring, I’ve debated on whether I should skip Haskell and go straight to Idris/Agda because of this. I won’t do that, I’ve decided, but this means I have to give up on some of the dependent-type material I’d like to cover. To be fair, *some* slices of dependently typed programming are accessible. Stephanie Weirich’s red-black tree GADT has much of the flavor of dependently typed programming without as much of the Haskell-induced awkwardness. There is a decent description of this example in https://themonadreader.files.wordpress.com/2013/08/issue221.pdf I hope this helps! Richard -=-=-=-=-=-=-=-=-=-=- Richard A. Eisenberg Asst. Prof. of Computer Science Bryn Mawr College Bryn Mawr, PA, USA cs.brynmawr.edu/~rae > On Sep 28, 2016, at 2:49 AM, Todd Wilson wrote: > > Richard, > > Thanks for this suggestion. I wasn't aware of the singletons library; > I'll have to take a look. > > To you and the other readers of this thread: are there other > approaches that have not yet been suggested? Since I'm using this for > a series of assignments for students that have seen Haskell before but > are still relative beginners, I'm looking for something that will be > relatively easy to explain, won't get in the way of them writing the > constructions in the straightforward way, and yet will provide some > additional type-checking to help catch their errors. > > --Todd > > On Tue, Sep 27, 2016 at 8:28 AM, Richard Eisenberg wrote: >> Hi Todd, >> >> My `singletons` library kludges dependent types into Haskell via much dirty Template Haskell hackery. But it works in your use case. I was able to write your reg2fsm function much as you desired. >> >> See attached. >> >> Note that my type signature for reg2fsm (`Sing (r :: RegExp) -> FSM (F r)`) is essentially a dependent type: you can view `Sing (r :: RegExp)` to be like an argument `(r : RegExp)` in a proper dependently-typed language. Alternatively, you can pronounce `Sing` as `Π`. >> >> Richard >> >> >> >> -=-=-=-=-=-=-=-=-=-=- >> Richard A. Eisenberg >> Asst. Prof. of Computer Science >> Bryn Mawr College >> Bryn Mawr, PA, USA >> cs.brynmawr.edu/~rae >> >>> On Sep 26, 2016, at 1:48 AM, Todd Wilson wrote: >>> >>> I haven't yet had the pleasure of exploring the subtleties of >>> dependently-typed programming in Haskell, but I'm finding myself in >>> need of a little bit of it in advance of that exploration and was >>> hoping for some suggestions. >>> >>> I have a type of regular expressions: >>> >>> data RegExp = Empty >>> | Letter Char >>> | Plus RegExp RegExp >>> | Cat RegExp RegExp >>> | Star RegExp >>> >>> and a type of (deterministic) finite state machines that is >>> polymorphic in the state type: >>> >>> data FSM a = FSM { >>> states :: [a], >>> start :: a, >>> finals :: [a], >>> delta :: [(a,Char,a)] >>> } >>> >>> I've fixed an alphabet sigma :: [Char], and I want to write the >>> function that converts a regular expression to its associated FSM. The >>> machines associated with Empty and Letter are given by >>> >>> data EmptyFSM = Etrap >>> emptyFSM :: FSM EmptyFSM >>> emptyFSM = FSM { >>> states = [Etrap], >>> start = Etrap, >>> finals = [], >>> delta = [(Etrap, c, Etrap) | c <- sigma] >>> } >>> >>> data LetterFSM = Lstart | Lfinal | Ltrap >>> letterFSM :: Char -> FSM LetterFSM >>> letterFSM c = FSM { >>> states = [Lstart, Lfinal, Ltrap], >>> start = Lstart, >>> finals = [Lfinal], >>> delta = [(Lstart, c', if c' == c then Lfinal else Ltrap) | c' <- sigma] ++ >>> [(q, c', Ltrap) | q <- [Lfinal, Ltrap], c' <- sigma] >>> } >>> >>> Suppose I can code the constructions of the union machine, >>> concatenation machine, and star machine so that they have the types >>> >>> unionFSM :: FSM a -> FSM b -> FSM (a,b) >>> catFSM :: FSM a -> FSM b -> FSM (a,[b]) >>> starFSM :: FSM a -> FSM [a] >>> >>> Now what I want to do is to put all of this together into a function >>> that takes a regular expression and returns the associated FSM. In >>> effect, my function should have a dependent type like >>> >>> reg2fsm :: {r : RegExp} -> FSM (f r) >>> >>> where f is the function >>> >>> f :: RegExp -> * >>> f Empty = EmptyFSM >>> f (Letter a) = LetterFSM >>> f (Plus r1 r2) = (f r1, f r2) >>> f (Cat r1 r2) = (f r1, [f r2]) >>> f (Star r) = [f r] >>> >>> and be given by >>> >>> reg2fsm Empty = emptyFSM >>> reg2fsm (Letter c) = letterFSM c >>> reg2fsm (Plus r1 r2) = unionFSM (reg2fsm r1) (reg2fsm r2) >>> reg2fsm (Cat r1 r2) = catFSM (reg2fsm r1) (reg2fsm r2) >>> reg2fsm (Star r) = starFSM (reg2fsm r) >>> >>> What is the suggested approach to achieving this in Haskell? >>> >>> -- >>> Todd Wilson A smile is not an individual >>> Computer Science Department product; it is a co-product. >>> California State University, Fresno -- Thich Nhat Hanh >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> From apfelmus at quantentunnel.de Wed Sep 28 18:07:20 2016 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Wed, 28 Sep 2016 20:07:20 +0200 Subject: [Haskell-cafe] HGamer3D - website refresh - space invaders clone In-Reply-To: References: Message-ID: > aio tool ... and using this tool, Peter managed to have the whole room install the library and foreign dependencies without a hitch in 5 minutes. That was very impressive! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Peter Althainz wrote: > Dear All, > > the http://www.hgamer3d.org website now comes with some updates: slides > from Haskell Leipzig 2016 link, more explanations, aio tool explained, > space invaders game. > > regards > Peter From tonyday567 at gmail.com Wed Sep 28 21:20:54 2016 From: tonyday567 at gmail.com (Tony Day) Date: Thu, 29 Sep 2016 07:20:54 +1000 Subject: [Haskell-cafe] [Haskell] Branch Streaming (was GHC is a monopoly compiler) Message-ID: I've actually looked down that particular rabbit hole. Here's a link to a monoid for pipes that represents a branch: https://github.com/tonyday567/pipes-extended/blob/master/src/Pipes/Monoid.hs#L81 For flavour, the computation involves hoisting and lifting back and forth over several layers, as the various meta-physical wires cross. That was years ago, but I haven't seen anything since. It looks like Pipes is the wrong abstraction point to stream with branching. I wonder what is? On Wed, Sep 28, 2016 at 9:59 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > Nope :) > > And I think we are still learning how to do stream. Have have streaming > in a line down pat, but streaming with a DAG or general graphs wendontnhave > yet ;) > > > On Wednesday, September 28, 2016, Tom Ellis jaguarpaw.co.uk> wrote: > >> On Mon, Sep 26, 2016 at 08:56:55PM -0500, Christopher Allen wrote: >> > Streaming is a good example here. It's not "obvious" how to do many >> > things in Haskell that are "obvious" in other languages. Partly >> > because industry hasn't used languages like Haskell much, partly >> > because the canvas we work with permits more structure. >> >> Is it obvious how to do streaming in other languages? >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Sep 28 21:23:16 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 28 Sep 2016 23:23:16 +0200 Subject: [Haskell-cafe] [Haskell] Branch Streaming (was GHC is a monopoly compiler) In-Reply-To: References: Message-ID: For flavour, the computation involves hoisting and lifting back and forth > over several layers, as the various meta-physical wires cross. That was > years ago, but I haven't seen anything since. It looks like Pipes is the > wrong abstraction point to stream with branching. I wonder what is? > > Machines? https://hackage.haskell.org/package/machines Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonyday567 at gmail.com Wed Sep 28 21:31:43 2016 From: tonyday567 at gmail.com (Tony Day) Date: Thu, 29 Sep 2016 07:31:43 +1000 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> <1475047361700-5843416.post@n5.nabble.com> Message-ID: I've asked for some summer interns and space to do some haskell dev. I'll have 4 bright python-trained coders, with maybe one FP subject, and 8 weeks to get something done. In this context, the powers that be gave me haskell with batteries included. I can't give them *those* batteries - I don't even know what some of them do. On Wed, Sep 28, 2016 at 11:53 PM, Alex Belanger wrote: > Just a reminder, I think Haskell (the language) is being conflated by > `base` (the library). > > `base` has exactly the minimum required for GHC to bootstrap and compile > itself. > > If you guys are interested in an `other-base`, then do it and list that as > a dependency in your cabal file. > > You choose your dependencies by relevance, but it doesn't affect what > Haskell is or capable of. The whole point of having even `base` be a > library (and extensions) is what allow Haskell to be such a good research > language. > > No need to discuss morals on a non-existant problem. Go ahead and make a > different base. Companies do this all the time. > > Alex. > > On Sep 28, 2016 3:22 AM, "Peter" wrote: > > What are the advantages of batteries included? > > 1) It's easier for newcomers to find the appropriate library for common > tasks. > 2) Consistency between different programs, as they will mostly use the same > standard libraries for common tasks. > > Do these require the batteries to be installed with the compiler? Do they > require the batteries to be installed as a monolithic unit at all? An > "official" wiki page pointing to the recommended packages for common tasks > would seem to achieve the purpose almost as well, but without the > accompanying problems. > > As for sets of specific library versions that are known to work well > together, Stackage has already solved that. > > > > -- > View this message in context: http://haskell.1045720.n5.nabb > le.com/Re-Batteries-included-Was-GHC-is-a-monopoly- > compiler-tp5843366p5843416.html > Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Sep 28 21:39:27 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 28 Sep 2016 23:39:27 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) Message-ID: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict. I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient. As to what kind of batteries should be included: * I feel that Haskell already has an excellent set of containers for all sorts of tasks. * It has excellent parsers. * The web stuff seems less uniform, and my complaints about idioms apply. * To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. * I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks. As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures. Olaf From allbery.b at gmail.com Wed Sep 28 21:45:59 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 28 Sep 2016 17:45:59 -0400 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: On Wed, Sep 28, 2016 at 5:39 PM, Olaf Klinke wrote: > * To compete with other recent teaching languages, a really simple GUI > library to use within ghci would be fine. (diagrams and GTK?) Quick Basic > included "line" and "circle" commands to play with, even though the rest of > the language did not prepare me for more advanced languages. > This turns out to be much easier if you assume that Windows and OS X are not worth supporting, or are happy with forcing users on those platforms to jump through annoying hoops (*especially* Windows; there are reasonable ways to get gtk on OS X, even though it doesn't come with the system, but Windows is still the Wild West as far as third party libraries are concerned --- Chocolatey notwithstanding). :/ > As to the versioning and backward compatibility issues of a standard > library: In my eyes the whole concept of version numbers is broken. > Dependencies should be stated in terms of type signatures. > And ghc in fact uses hashes generated from this. But this has to include the signatures of internals because they can leak out for inlining --- so you still have more problems than other languages do. -- 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 tonyday567 at gmail.com Wed Sep 28 22:09:42 2016 From: tonyday567 at gmail.com (Tony Day) Date: Thu, 29 Sep 2016 08:09:42 +1000 Subject: [Haskell-cafe] [Haskell] Branch Streaming (was GHC is a monopoly compiler) In-Reply-To: References: Message-ID: A lot of the Pipes trickery is making a branch without the abstraction of state. It's easy to remember the last stream value and send it elsewhere. If state is easy (doesn't stuff up streaming), then Moore and Mealy are good places to start tinkering. The whole machines abstraction (branch of DFA etc, not the kmett library) is a bit clunky but. A Mealy machine's output is independent of its input - it can fire anytime, not just when a new stream value arrives. If you have a linear pull request line, like pipes does so well, there is full coupling of the input and output - this is a Moore not a Mealy machine. The stream machine is created by linking up all the states of a Moore and making them fire every stream value. Contrary to much of the DFA narrative, we have a wire hanging out of state as well. The importance of distinguishing between a wire connected to state and what is an output wire that exists within state machines seems a touch artificial. On Thu, Sep 29, 2016 at 7:23 AM, Alan & Kim Zimmerman wrote: > > > > For flavour, the computation involves hoisting and lifting back and forth >> over several layers, as the various meta-physical wires cross. That was >> years ago, but I haven't seen anything since. It looks like Pipes is the >> wrong abstraction point to stream with branching. I wonder what is? >> >> Machines? https://hackage.haskell.org/package/machines > > Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Wed Sep 28 22:14:26 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 29 Sep 2016 11:14:26 +1300 Subject: [Haskell-cafe] doctest (Was: Batteries included (Was: GHC is a monopoly compiler)) In-Reply-To: <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> Message-ID: m% cabal install doctest cabal: /usr/bin/ar: permission denied m% file /usr/bin/ar; ls -l /usr/bin/ar /usr/bin/ar: Mach-O 64-bit executable x86_64 -rwxr-xr-x 1 root wheel 18160 14 Jan 2016 /usr/bin/ar What am I doing wrong? From allbery.b at gmail.com Wed Sep 28 22:20:32 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 28 Sep 2016 18:20:32 -0400 Subject: [Haskell-cafe] doctest (Was: Batteries included (Was: GHC is a monopoly compiler)) In-Reply-To: References: <3aa9b152-c9a4-f8ac-c194-266d52525752@gmail.com> <83dc947d-9d7f-4dab-afde-1b446acf3c03@durchholz.org> <9a306e5f-8ff2-6960-95f9-9faf97efd033@gmail.com> Message-ID: On Wed, Sep 28, 2016 at 6:14 PM, Richard A. O'Keefe wrote: > m% cabal install doctest > cabal: /usr/bin/ar: permission denied > https://github.com/haskell/cabal/issues/2653#issuecomment-121997407 You have a cabal-install built against an older version of the unix package, which was doing an access() call that runs afoul of System Integrity Protection. -- 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 tonyday567 at gmail.com Wed Sep 28 22:35:43 2016 From: tonyday567 at gmail.com (Tony Day) Date: Wed, 28 Sep 2016 22:35:43 +0000 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: My solution to the lack of graphics is ipython or a workflow that looks like it - a loop that renders charts, runs code and places results in a markdown file, then rendered in the browser. That's about as live as you can get mixing Windows and open source. On Thu, Sep 29, 2016 at 7:46 AM Brandon Allbery wrote: > On Wed, Sep 28, 2016 at 5:39 PM, Olaf Klinke > wrote: > >> * To compete with other recent teaching languages, a really simple GUI >> library to use within ghci would be fine. (diagrams and GTK?) Quick Basic >> included "line" and "circle" commands to play with, even though the rest of >> the language did not prepare me for more advanced languages. >> > > This turns out to be much easier if you assume that Windows and OS X are > not worth supporting, or are happy with forcing users on those platforms to > jump through annoying hoops (*especially* Windows; there are reasonable > ways to get gtk on OS X, even though it doesn't come with the system, but > Windows is still the Wild West as far as third party libraries are > concerned --- Chocolatey notwithstanding). :/ > > >> As to the versioning and backward compatibility issues of a standard >> library: In my eyes the whole concept of version numbers is broken. >> Dependencies should be stated in terms of type signatures. >> > > And ghc in fact uses hashes generated from this. But this has to include > the signatures of internals because they can leak out for inlining --- so > you still have more problems than other languages do. > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Wed Sep 28 22:47:21 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Wed, 28 Sep 2016 15:47:21 -0700 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: On Wed, Sep 28, 2016 at 2:45 PM, Brandon Allbery wrote: > This turns out to be much easier if you assume that Windows and OS X are > not worth supporting, or are happy with forcing users on those platforms to > jump through annoying hoops (*especially* Windows; there are reasonable > ways to get gtk on OS X, even though it doesn't come with the system, but > Windows is still the Wild West as far as third party libraries are > concerned --- Chocolatey notwithstanding). :/ > GTK on Windows is trivial at this point, with stack and LTS 7+. Try it yourself: stack exec -- pacman -S mingw-w64-x86_64-gtk3 stack install gtk2hs-buildtools stack install gtk3 --flag gtk3:build-demos gtk2hs-demo-carsim (I didn't start 100% clean but I don't *think* there are any other pacman packages required...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Wed Sep 28 23:00:58 2016 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 29 Sep 2016 01:00:58 +0200 Subject: [Haskell-cafe] Batteries included In-Reply-To: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: <947d9d69-060a-af18-eba9-9d014b2462ab@unicaen.fr> Le 28/09/2016 à 23:39, Olaf Klinke a écrit : > I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. Do you really need to issue religious statements on this forum? Please... It is as bad, or worse than such claims as "from XXX you cannot learn anything useful!" > /.../ it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. Are you sure? The same "basic" library for a 3*3 equation, and for some enormous radiosity computation, and for ill-conditioned matrices, and for equations with constraints, and for Moore-Penrose pseudoinverses, and ... etc. ? ... Libraries must, and will evolve and adapt/split, since new algorithms are constructed every week. And if you like cute citations, such as "doing one thing well" (of course, everybody knows the meaning of "well", which is universal and eternal, no?...), I'll give you my favourite: "There is one truth, which should be obvious to everybody: - *all* truth which is obvious to some, is far from being obvious to others". Jerzy Karczmarczuk From jo at durchholz.org Thu Sep 29 00:40:42 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 29 Sep 2016 02:40:42 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: <577770a3-a74d-01dd-c5bc-a7a49210b0c7@durchholz.org> Am 29.09.2016 um 00:35 schrieb Tony Day: > My solution to the lack of graphics is ipython or a workflow that looks > like it - a loop that renders charts, runs code and places results in a > markdown file, then rendered in the browser. > That's about as live as you can get mixing Windows and open source. There was a time when this was correct, but it has been gone for almost a decade now. Today, you can even choose the abstraction level: - GTK++ for GUI - SDL for multimedia - OpenGL for 3d Graphics From tonyday567 at gmail.com Thu Sep 29 00:46:57 2016 From: tonyday567 at gmail.com (Tony Day) Date: Thu, 29 Sep 2016 00:46:57 +0000 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <577770a3-a74d-01dd-c5bc-a7a49210b0c7@durchholz.org> References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> <577770a3-a74d-01dd-c5bc-a7a49210b0c7@durchholz.org> Message-ID: Ok, as live as you can get mixing native Haskell and windows, without the skills to DIY tooling. Are we that far behind? On Thu, Sep 29, 2016 at 10:40 AM Joachim Durchholz wrote: > Am 29.09.2016 um 00:35 schrieb Tony Day: > > My solution to the lack of graphics is ipython or a workflow that looks > > like it - a loop that renders charts, runs code and places results in a > > markdown file, then rendered in the browser. > > That's about as live as you can get mixing Windows and open source. > > There was a time when this was correct, but it has been gone for almost > a decade now. > Today, you can even choose the abstraction level: > - GTK++ for GUI > - SDL for multimedia > - OpenGL for 3d Graphics > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Thu Sep 29 01:18:07 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 29 Sep 2016 03:18:07 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> <577770a3-a74d-01dd-c5bc-a7a49210b0c7@durchholz.org> Message-ID: If there's DIY tooling involved, then yes that is pretty far behind. I don't think that's necessary; I dimly recall somebody mentioned that Haskell does have a call interface to C code. The main challenge is to find ways to "Haskellize" those strictly imperative APIs so they become useful for the application programmer; I'd categorize that as "incommensurable" rather than "behind". Am 29.09.2016 um 02:46 schrieb Tony Day: > Ok, as live as you can get mixing native Haskell and windows, without > the skills to DIY tooling. Are we that far behind? > On Thu, Sep 29, 2016 at 10:40 AM Joachim Durchholz > wrote: > > Am 29.09.2016 um 00:35 schrieb Tony Day: > > My solution to the lack of graphics is ipython or a workflow that > looks > > like it - a loop that renders charts, runs code and places results > in a > > markdown file, then rendered in the browser. > > That's about as live as you can get mixing Windows and open source. > > There was a time when this was correct, but it has been gone for almost > a decade now. > Today, you can even choose the abstraction level: > - GTK++ for GUI > - SDL for multimedia > - OpenGL for 3d Graphics > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From amit at amitlevy.com Thu Sep 29 01:47:49 2016 From: amit at amitlevy.com (Amit Levy) Date: Wed, 28 Sep 2016 21:47:49 -0400 Subject: [Haskell-cafe] Haskell opportunity at MemCachier Message-ID: <3a3800c2-31ef-de9f-af2c-8522cd51b60b@amitlevy.com> Hi friends! David and I are looking for a software engineer to join MemCachier and help work with us on our automation, analytics monitoring and dashboard, server management and core infrastructure. The work is mostly in Haskell, with the core infrastructure in Go as well as bits in pieces in whatever else is needed. There's lots of opportunity for open source contributions too! I've included the job description below (also at https://www.memcachier.com/job). If you're interested, send a resume and cover letter to jobs at memcachier.com or contact David or me. ============================================= MemCachier is the largest provider of memcache-as-service to PaaS applications. Our home-grown, fully distributed and multi-tenant implementation of memcache serves billions of requests each day, powering a range of applications from scrappy startups to fortune 500 companies. As the newest addition to our team, you’ll be working on improving fail over automation, analytics, monitoring, making MemCachier faster and more reliable, and well as contributing to the ecosystem of open source memcache clients in all languages. You’ll also share in on-call duties. Our design is failure resilient, so incidents are rare, but we do share in carrying around a pager. We use tools and languages we genuinely like, with a high skew towards type-safe languages. Our memcache implementation is built in Go and most of the rest of our infrastructure in Haskell. We value well designed software and compile-time guarantees. We are a small team and, like our service, we are distributed—residing on two coasts of the United States and in Europe (or elsewhere, depending on the season). While we are collaborative, this means the job requires being comfortable with a high-degree of independence. In return, you’ll be able to work wherever you are and won’t be bound to a particular schedule most of the time. We encourage functional programmers of all stripes, but we particularly encourage people from groups that are underrepresented in software. Finally, the qualifications below are not strict requirements, but rather guidelines for the kinds of skills we’re looking for. ## Qualifications * B.S. in Computer Science or equivalent experience. Advanced degrees encouraged (the current team either has, or is working on, PhDs), but we know there are plenty of other ways to come by the same knowledge. * Proficiency with distributed systems concepts. * Proficiency in either Go or Haskell, or a closely related language like ML, Rust or a desire and ability to learn. * Good English written communication skills—you don’t to be a native speaker, but you must be proficient. * Experience with web technologies (HTTP, web frameworks, etc). * Experience working independently or in remote teams. ## Responsibilities * Share in on-call duties. Our design is failure resilient, so incidents are rare, but we do share in carrying around a pager. * Contribute throughout the full stack, from provisioning services and core infrastructure, to the analytics dashboard and customer portal. * Participate in discussions about software and product design. ## Benefits * Self-Direction: You'll have a high-degree of autonomy to work on what you think is most interesting and valuable. * Open Source: We try to contribute as much of our work as possible to the open source ecosystem. * Full-Stack: We write software in many languages (Haskell, Go, Ruby, JavaScript) across the stack (front-end, middleware, distributed backends, monitoring). * Hard Problems: We have plenty of unsolved distributed systems problems and lots of data. * Flexible Hours: Work where and when is best for you. To apply, e-mail jobs at memcachier.com with a resume, cover letter and other supporting materials. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From handongwinter at didichuxing.com Thu Sep 29 05:34:34 2016 From: handongwinter at didichuxing.com (=?gb2312?B?uqu2rCi7+bShxr3MqLK/KQ==?=) Date: Thu, 29 Sep 2016 05:34:34 +0000 Subject: [Haskell-cafe] Take over word24 package on hackage In-Reply-To: <1475127125746.25778@didichuxing.com> References: <969CC52A-A37C-4E2B-9E4D-1D20E18972CE@didichuxing.com> , <467458F8-6105-4CAD-91B5-0DAB9CFD9448@didichuxing.com>, <1475127125746.25778@didichuxing.com> Message-ID: <1475127276416.60171@didichuxing.com> Dear hackage administrators: I'd like to take over the maintenance of word24 package on hackage, here is the conversation between me and current maintainer. My hackage account is winterland, currently my package mysql-haskell rely on word24. If there's anything you need to know, please contact me. Thanks! Winterland SEP 29/ 2016 ________________________________ From: 韩冬(基础平台部) Sent: Tuesday, August 30, 2016 5:10 PM To: John Lato Subject: Re: Query about word24 package on package How is the stackage thing going? I hesitate to add it myself because i’m not the maintainer. my hackage account is winterland, If you decide to leave the maintaince to me just drop me a message, thanks! Winter On Aug 27, 2016, at 03:57, John Lato > wrote: Hi sorry for the delay, for some reason I've had really inconsistent messages from GitHub. If you want to do maintenance that's awesome I'll see if I can get it set up today. On Thu, Aug 25, 2016, 10:46 PM 韩冬(基础平台部) > wrote: Hi, John Really really sorry to bother you by email, recently i’m writing a mysql driver in haskell, i use your word24 package to get a proper Word24 type, so i’d like to ask you to add it to stackage, i open a github issue here: https://github.com/JohnLato/word24/issues/1 , but since you didn’t reply, so i drop this email, hope you can reply ASAP. If you permit, i can do the version bump and package upload maintaince in future. Thanks for your code and time! Winter -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Sep 29 05:44:35 2016 From: gershomb at gmail.com (Gershom B) Date: Thu, 29 Sep 2016 01:44:35 -0400 Subject: [Haskell-cafe] Take over word24 package on hackage In-Reply-To: <1475127276416.60171@didichuxing.com> References: <969CC52A-A37C-4E2B-9E4D-1D20E18972CE@didichuxing.com> <467458F8-6105-4CAD-91B5-0DAB9CFD9448@didichuxing.com> <1475127125746.25778@didichuxing.com> <1475127276416.60171@didichuxing.com> Message-ID: There seems to be some confusion here. John seems to have offered to you the capabilities to do maintenance on his package. He can just add your hackage account as a co-maintainer on hackage without any intervention. The package takeover process is for reassigning orphaned packages from non-responsive/disappeared maintainers. Since you seem to have a correspondence with John, I think he can just add you as a maintainer with upload rights directly. At this point you can then feel more comfortable in adding the package to stackage. I hope that makes sense and I’m not missing anything. Best, Gershom On September 29, 2016 at 1:34:49 AM, 韩冬(基础平台部) (handongwinter at didichuxing.com) wrote: > Dear hackage administrators: > > > I'd like to take over the maintenance of word24 package on hackage, here is the conversation > between me and current maintainer. > > > My hackage account is winterland, currently my package mysql-haskell rely on word24. > If there's anything you need to know, please contact me. Thanks! > > > Winterland > > > SEP 29/ 2016 > > > ________________________________ > From: 韩冬(基础平台部) > Sent: Tuesday, August 30, 2016 5:10 PM > To: John Lato > Subject: Re: Query about word24 package on package > > How is the stackage thing going? I hesitate to add it myself because i’m not the maintainer. > my hackage account is winterland, If you decide to leave the maintaince to me just drop > me a message, thanks! > > Winter > > On Aug 27, 2016, at 03:57, John Lato > > wrote: > > > Hi sorry for the delay, for some reason I've had really inconsistent messages from GitHub. > If you want to do maintenance that's awesome I'll see if I can get it set up today. > > On Thu, Aug 25, 2016, 10:46 PM 韩冬(基础平台部) > > wrote: > Hi, John > > Really really sorry to bother you by email, recently i’m writing a mysql driver in haskell, > i use your word24 package to get a proper Word24 type, so i’d like to ask you to add it to stackage, > i open a github issue here: https://github.com/JohnLato/word24/issues/1 , but since > you didn’t reply, so i drop this email, hope you can reply ASAP. If you permit, i can do the > version bump and package upload maintaince in future. > > Thanks for your code and time! > > Winter > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From handongwinter at didichuxing.com Thu Sep 29 06:11:10 2016 From: handongwinter at didichuxing.com (=?gb2312?B?uqu2rCi7+bShxr3MqLK/KQ==?=) Date: Thu, 29 Sep 2016 06:11:10 +0000 Subject: [Haskell-cafe] Take over word24 package on hackage In-Reply-To: References: <969CC52A-A37C-4E2B-9E4D-1D20E18972CE@didichuxing.com> <467458F8-6105-4CAD-91B5-0DAB9CFD9448@didichuxing.com> <1475127125746.25778@didichuxing.com> <1475127276416.60171@didichuxing.com>, Message-ID: <1475129472295.86498@didichuxing.com> Sorry for the confusion, yes i meant to ask John to add me to the maintainers list on hackage, if he can do that i'd be more than happy. The problem is it's about one month since last time we contact, so i'm asking a taking over here. Let me clarify this: if John can hear this letter, please add me to word24's maintainers list, i'd be more than happy to help and a taking over is not necessary, but if somehow he still doesn't show up, hackage administrator please consider either adding me as a maintainer, or let me take over this package. Thanks! Winterland ________________________________________ From: Gershom B Sent: Thursday, September 29, 2016 1:44 PM To: haskell-cafe at haskell.org; 韩冬(基础平台部) Cc: admin at hackage.haskell.org; John Lato Subject: Re: [Haskell-cafe] Take over word24 package on hackage There seems to be some confusion here. John seems to have offered to you the capabilities to do maintenance on his package. He can just add your hackage account as a co-maintainer on hackage without any intervention. The package takeover process is for reassigning orphaned packages from non-responsive/disappeared maintainers. Since you seem to have a correspondence with John, I think he can just add you as a maintainer with upload rights directly. At this point you can then feel more comfortable in adding the package to stackage. I hope that makes sense and I’m not missing anything. Best, Gershom On September 29, 2016 at 1:34:49 AM, 韩冬(基础平台部) (handongwinter at didichuxing.com) wrote: > Dear hackage administrators: > > > I'd like to take over the maintenance of word24 package on hackage, here is the conversation > between me and current maintainer. > > > My hackage account is winterland, currently my package mysql-haskell rely on word24. > If there's anything you need to know, please contact me. Thanks! > > > Winterland > > > SEP 29/ 2016 > > > ________________________________ > From: 韩冬(基础平台部) > Sent: Tuesday, August 30, 2016 5:10 PM > To: John Lato > Subject: Re: Query about word24 package on package > > How is the stackage thing going? I hesitate to add it myself because i’m not the maintainer. > my hackage account is winterland, If you decide to leave the maintaince to me just drop > me a message, thanks! > > Winter > > On Aug 27, 2016, at 03:57, John Lato > > wrote: > > > Hi sorry for the delay, for some reason I've had really inconsistent messages from GitHub. > If you want to do maintenance that's awesome I'll see if I can get it set up today. > > On Thu, Aug 25, 2016, 10:46 PM 韩冬(基础平台部) > > wrote: > Hi, John > > Really really sorry to bother you by email, recently i’m writing a mysql driver in haskell, > i use your word24 package to get a proper Word24 type, so i’d like to ask you to add it to stackage, > i open a github issue here: https://github.com/JohnLato/word24/issues/1 , but since > you didn’t reply, so i drop this email, hope you can reply ASAP. If you permit, i can do the > version bump and package upload maintaince in future. > > Thanks for your code and time! > > Winter > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From apfelmus at quantentunnel.de Thu Sep 29 14:43:36 2016 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 29 Sep 2016 16:43:36 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: > Relative no-brainer topics in other communities like how text should > be represented are highly contentious. Actually, choosing a good representation for text / strings is not a no-brainer, and the difficulty can be traced to several features of the Haskell language that are simply not present in other languages. Some of these features are: 1) Pattern matching. We can extract the first character and subsequent characters of a `String` and distinguish cases while doing so: isPrefixOf [] _ = True isPrefixOf (x:xs) [] = False isPrefixOf (x:xs) (y:ys) = isPrefixOf xs ys This is not possible in, say, Python. 2) Parametric polymorphism. The `isPrefixOf` function above is actually polymorphic. It works not only for `String`, but for any kind of list. 3) Lazy data structures. We can represent text of *infinite* length! cycle "Haskell" :: String And we can use them in a streaming fashion interact (take 10 . lines) :: IO () See also https://wiki.haskell.org/Simple_Unix_tools You cannot do this with a standard Python string. Also, it's not like other languages all agree on their preferred method of representing strings: NULL-terminated (C) vs "length-byte-first" (Pascal) comes to mind. Best regard Heinrich Apfelmus -- http://apfelmus.nfshost.com Christopher Allen wrote: > Batteries included is a bad idea when the community is this divided. > Relative no-brainer topics in other communities like how text should > be represented are highly contentious. > > I'd sooner see some basic test cases hammered out and integrated into > base before a real attempt at this is launched. Something that would > help the Cabal devs. > > On Tue, Sep 27, 2016 at 6:14 PM, Joachim Durchholz wrote: >> Am 27.09.2016 um 23:25 schrieb Olaf Klinke: >>> Can someone please define what exactly a "batteries included" >>> standard library is? >> >> Anything you'll typically need is already available. >> For some value of "typically need", so it's slightly squishy - here's a list >> of batteries I'd like included: >> - Reading/writing files >> - Reading over HTTP (reliably - HTTP is surprisingly complex) >> - Search&replace in test streams >> - Easy-to-use string->string maps >> - JSON parsing and printing (bonus points for YAML) >> - GUI stuff >> - Website stuff >> - Sending mails >> - Solid ecosystem: >> - build system, >> - library directory, >> - no-brainer automated testing support. >> (Complicated testing means more bugs in test code than in >> production code - this diverges.) >> >>> IMHO that Python-Haskell comparison is unfair. >>> >>> Although both claim to be general-purpose languages, the focus in >>> Haskell certainly has been on language research for most of its life. >> >> I do not think that Python actually comes with all batteries included. >> And in some areas support is pretty bad. >> >>> I recently hacked together a web client in python, my first project >>> in that language. Documentation is excellent. Yet I am still >>> horrified I had to use a language that provides so few static >>> guarantees to control megawatt machines. >> >> That, and the idea that class and function declarations are executable >> statements. >> Circular dependencies are "handled" by passing partially-initialized objects >> around; the Python interpreter handles this with no problems, but >> programmers have fun because nobody assumes incomplete initialization. >> >> I.e. Python's language semantics is broken by design in pretty fundamental >> areas. >> >> That said, it's good for banging something together quickly. Been there, >> done that, got the t-shirt. >> Just don't do anything that you need a team for with it, the lack of >> guarantees will really start to hurt. >> >>> What puts me off Haskell nowadays is the direct result of Haskell's >>> roots in language research: Often when I come across a package that >>> does what I need, it uses the conduit, lens or another idiom, which >>> are like a language in a language to learn. In milder ways Python >>> seems to suffer the same problem. >> >> I think Python shares that problem with Lisp: it's so easy to add another >> meta-idiom that too many people actually do this, and most don't even think >> about composability or guarantees. >> >>> So please, developers: Write more >>> >>> batteries, but make them expose a neat lambda calculus interface if >>> possible that can be combined freely with other batteries. >> >> I sense a conflict of objectives here. >> Having many batteries pushes you towards wide APIs. >> However, the wider an API, the harder it is to make it combinable. More >> surface that must be made to match. >> >> Making an API that's feature-complete *and* narrow is really hard and takes >> a huge amount of designer and programmer time, plus the willingness to lose >> most of your existing user base for an unproven idea of improvement. This >> road is a really hard one, and you need corporate backing or personal >> obsession to follow it. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > From cma at bitemyapp.com Thu Sep 29 14:52:36 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 29 Sep 2016 09:52:36 -0500 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: When parametricity isn't an option, utf-8 is taken for granted, the language is ambiently strict, it's quite a bit more straight-forward what you want to do, even if the actual implementation is not trivial. I'm not saying the decision should be trivial for us, I'm saying that any attempt to unify the disparate things Haskell programmers want is going to be much harder than it would be with other languages and ecosystems. Also, I use this library for my work regularly: https://github.com/snoyberg/mono-traversable/blob/17eebcfa2e96e923270e1284675456a76e680119/mono-traversable/src/Data/Sequences.hs#L1236-L1237 With Text (Strict | Lazy) and ByteString (Strict | Lazy) This suits me fine, but I know people for whom mono-traversable is a hard-no. On Thu, Sep 29, 2016 at 9:43 AM, Heinrich Apfelmus wrote: >> Relative no-brainer topics in other communities like how text should >> be represented are highly contentious. > > > Actually, choosing a good representation for text / strings is not a > no-brainer, and the difficulty can be traced to several features of the > Haskell language that are simply not present in other languages. Some of > these features are: > > 1) Pattern matching. > > We can extract the first character and subsequent characters of a `String` > and distinguish cases while doing so: > > isPrefixOf [] _ = True > isPrefixOf (x:xs) [] = False > isPrefixOf (x:xs) (y:ys) = isPrefixOf xs ys > > This is not possible in, say, Python. > > 2) Parametric polymorphism. > > The `isPrefixOf` function above is actually polymorphic. It works not only > for `String`, but for any kind of list. > > 3) Lazy data structures. > > We can represent text of *infinite* length! > > cycle "Haskell" :: String > > And we can use them in a streaming fashion > > interact (take 10 . lines) :: IO () > > See also > > https://wiki.haskell.org/Simple_Unix_tools > > You cannot do this with a standard Python string. > > > Also, it's not like other languages all agree on their preferred method of > representing strings: NULL-terminated (C) vs "length-byte-first" (Pascal) > comes to mind. > > > Best regard > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > > Christopher Allen wrote: >> >> Batteries included is a bad idea when the community is this divided. >> Relative no-brainer topics in other communities like how text should >> be represented are highly contentious. >> >> I'd sooner see some basic test cases hammered out and integrated into >> base before a real attempt at this is launched. Something that would >> help the Cabal devs. >> >> On Tue, Sep 27, 2016 at 6:14 PM, Joachim Durchholz >> wrote: >>> >>> Am 27.09.2016 um 23:25 schrieb Olaf Klinke: >>>> >>>> Can someone please define what exactly a "batteries included" >>>> standard library is? >>> >>> >>> Anything you'll typically need is already available. >>> For some value of "typically need", so it's slightly squishy - here's a >>> list >>> of batteries I'd like included: >>> - Reading/writing files >>> - Reading over HTTP (reliably - HTTP is surprisingly complex) >>> - Search&replace in test streams >>> - Easy-to-use string->string maps >>> - JSON parsing and printing (bonus points for YAML) >>> - GUI stuff >>> - Website stuff >>> - Sending mails >>> - Solid ecosystem: >>> - build system, >>> - library directory, >>> - no-brainer automated testing support. >>> (Complicated testing means more bugs in test code than in >>> production code - this diverges.) >>> >>>> IMHO that Python-Haskell comparison is unfair. >>>> >>>> Although both claim to be general-purpose languages, the focus in >>>> Haskell certainly has been on language research for most of its life. >>> >>> >>> I do not think that Python actually comes with all batteries included. >>> And in some areas support is pretty bad. >>> >>>> I recently hacked together a web client in python, my first project >>>> in that language. Documentation is excellent. Yet I am still >>>> horrified I had to use a language that provides so few static >>>> guarantees to control megawatt machines. >>> >>> >>> That, and the idea that class and function declarations are executable >>> statements. >>> Circular dependencies are "handled" by passing partially-initialized >>> objects >>> around; the Python interpreter handles this with no problems, but >>> programmers have fun because nobody assumes incomplete initialization. >>> >>> I.e. Python's language semantics is broken by design in pretty >>> fundamental >>> areas. >>> >>> That said, it's good for banging something together quickly. Been there, >>> done that, got the t-shirt. >>> Just don't do anything that you need a team for with it, the lack of >>> guarantees will really start to hurt. >>> >>>> What puts me off Haskell nowadays is the direct result of Haskell's >>>> roots in language research: Often when I come across a package that >>>> does what I need, it uses the conduit, lens or another idiom, which >>>> are like a language in a language to learn. In milder ways Python >>>> seems to suffer the same problem. >>> >>> >>> I think Python shares that problem with Lisp: it's so easy to add another >>> meta-idiom that too many people actually do this, and most don't even >>> think >>> about composability or guarantees. >>> >>>> So please, developers: Write more >>>> >>>> batteries, but make them expose a neat lambda calculus interface if >>>> possible that can be combined freely with other batteries. >>> >>> >>> I sense a conflict of objectives here. >>> Having many batteries pushes you towards wide APIs. >>> However, the wider an API, the harder it is to make it combinable. More >>> surface that must be made to match. >>> >>> Making an API that's feature-complete *and* narrow is really hard and >>> takes >>> a huge amount of designer and programmer time, plus the willingness to >>> lose >>> most of your existing user base for an unproven idea of improvement. This >>> road is a really hard one, and you need corporate backing or personal >>> obsession to follow it. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From jo at durchholz.org Thu Sep 29 15:18:36 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 29 Sep 2016 17:18:36 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> Am 29.09.2016 um 16:43 schrieb Heinrich Apfelmus: > Also, it's not like other languages all agree on their preferred method > of representing strings: NULL-terminated (C) vs "length-byte-first" > (Pascal) comes to mind. Each language does define its preferred string representation. From apfelmus at quantentunnel.de Thu Sep 29 15:33:12 2016 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Thu, 29 Sep 2016 17:33:12 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: > * To compete with other recent teaching languages, a really simple > GUI library to use within ghci would be fine. (diagrams and GTK?) > Quick Basic included "line" and "circle" commands to play with, even > though the rest of the language did not prepare me for more advanced > languages. You mean, like this? http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png It's a project that I'm currently working on, called HyperHaskell - the strongly hyped Haskell interpreter - Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Olaf Klinke wrote: > I did not intend to start a Python-bashing thread. Most people on this list will agree on which language is superior. > > I did not intend to suggest that Haskell is still mainly a research language, nor that it should remain to be. I'd love to see more problems to be tackled with lenses, FRP or GADTs, just to show that it can be done this way. Maybe one day an idiom will prove superior to its competitors and take its place in whatever is the equivalent of base then. I am happy to have packages coexist that use either of String, Text, ByteString.Lazy or ByteString.Strict. > > I am a fan of the Unix philosophy: Do one thing, and do it well. There are modules in base that are very good examples of this: Data.Map provides just one data structure with a very easy interface, no newtypes, no typeclasses. The user needs no knowledge of how it is implemented, but the internals can be exposed if necessary. Control.DeepSeq provides one single typeclass to provide one single functionality. > In Unix the glue between programs are streams of bytes. I feel that the glue between Haskell libraries should be lambda calculus and algebraic datatypes. > So when you write a library that processes HTTP traffic as conduits: Provide a wrapper function whose type does not mention the conduit classes. When you write another efficient text library, provide fromString and toString functions, even if they are inefficient. > > As to what kind of batteries should be included: > > * I feel that Haskell already has an excellent set of containers for all sorts of tasks. > * It has excellent parsers. > * The web stuff seems less uniform, and my complaints about idioms apply. > * To compete with other recent teaching languages, a really simple GUI library to use within ghci would be fine. (diagrams and GTK?) Quick Basic included "line" and "circle" commands to play with, even though the rest of the language did not prepare me for more advanced languages. > * I know too little about the state of Haskell's number crunching libraries, but it seems that Vector is reasonably efficient nowadays. But what should I use to solve A*x = b? This is a problem so basic that is should be solved by a basic library. > > I like Peter's suggestion of an official wiki highlighting the state-of-the-art packages for common tasks. > > As to the versioning and backward compatibility issues of a standard library: In my eyes the whole concept of version numbers is broken. Dependencies should be stated in terms of type signatures. > > Olaf > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jorgemal1960 at gmail.com Thu Sep 29 18:09:10 2016 From: jorgemal1960 at gmail.com (jorgemal1960 at gmail.com) Date: Thu, 29 Sep 2016 11:09:10 -0700 (PDT) Subject: [Haskell-cafe] Writing insertionSort using foldr and a helper function Message-ID: I am posting the same question again because I had not subscribed to the list and I received a message saying it was automatically rejected. I have the following function that takes an element and a list and inserts the element into the list at the first position where it is less than or equal to the next element. So, if the list is sorted, then the list will remain sorted. myInsert :: Ord a => a -> [a] -> [a] myInsert x [] = [x] myInsert x (y:ys) = if x < y then x:y:ys else y:myInsert x ys Now, I have to use the above function myInsert and foldr to implement another function called insertionSort. I have been able to do it without using foldr as follows and it works just fine: insertionSort :: Ord a => [a] -> [a] insertionSort [] = [] insertionSort [x] = [x] insertionSort (x:xs) = myInsert x (insertionSort xs) I have worked for 2 days to use foldr without success, for example: insertionSort :: Ord a => [a] -> [a] insertionSort [] = [] insertionSort [x] = [x] insertionSort (x:xs) = foldr (myInsert) x (insertionSort xs) But it does not even compile, I get the following error which refers to last instruction at position "x" in "foldr (myInsert) x (insertionSort xs)": Couldn't match expected type ‘[a]’ with actual type ‘a’ I will very much appreciate your feedback in order to solve my issue. Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Thu Sep 29 19:49:47 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Thu, 29 Sep 2016 21:49:47 +0200 Subject: [Haskell-cafe] Fwd: Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: References: Message-ID: Hi guys, I'm playing with the mysterious "some" and "many" from Control.Applicative. If I try: many $ Just 1 It just loops, I understand why: http://stackoverflow.com/questions/18108608/what-are-alterna tives-some-and-many-useful-for It seems that some and many are normally used in a context where something is consumed, and can be depleted, so the loop ends. But why doesn't this terminates? take 3 $ many $ Just 1 It's a recursive call, but the construction of the result should be lazy... -- ===================================== Corentin Dupont CREATE-NET OpenIoT Research Area - Senior Researcher Via alla Cascata 56/D - 38123 Povo, Trento - Italy e-mail: corentin.dupont at create-net.org Skype: corentin.dupont1 www.create-net.org ====================================== -- ===================================== Corentin Dupont CREATE-NET OpenIoT Research Area - Senior Researcher Via alla Cascata 56/D - 38123 Povo, Trento - Italy e-mail: corentin.dupont at create-net.org Skype: corentin.dupont1 www.create-net.org ====================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Thu Sep 29 19:51:09 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Thu, 29 Sep 2016 21:51:09 +0200 Subject: [Haskell-cafe] Alternative: you can fool many people some time, and some people many time, but... Message-ID: Hi guys, I'm playing with the mysterious "some" and "many" from Control.Applicative. If I try: many $ Just 1 It just loops, I understand why: http://stackoverflow.com/questions/18108608/what-are-alterna tives-some-and-many-useful-for It seems that some and many are usually used in a context where something is consumed, and can be depleted, so the loop ends. But why doesn't this terminates? take 3 $ many $ Just 1 It's a recursive call, but the construction of the result should be lazy... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Thu Sep 29 19:58:31 2016 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Thu, 29 Sep 2016 21:58:31 +0200 Subject: [Haskell-cafe] Writing insertionSort using foldr and a helper function In-Reply-To: References: Message-ID: Le 29/09/2016 à 20:09, jorgemal1960 at gmail.com a écrit : > I have the following function that takes an element and a list and > inserts the element into the list at the first position where it is > less than or equal to the next element. > ** This is most probably some pedagogic assignment, and you should not expect from the community to solve your exercices. I suspect that you tried to solve the problem without trying to UNDERSTAND foldr... But let's see... > | > myInsert :: Ord a => a -> [a] -> [a] > myInsert x [] = [x] > myInsert x (y:ys) = if x < y then x:y:ys else y:myInsert x ys > | > > Now, I have to use the above function myInsert and foldr to implement > another function called insertionSort. I have been able to do it > without using foldr as follows and it works just fine: > ... OK. > I have worked for 2 days to use foldr without success, for example: > > | > insertionSort :: Ord a => [a] -> [a] > insertionSort [] = [] > insertionSort [x] = [x] > insertionSort (x:xs) = foldr (myInsert) x (insertionSort xs) > | > > But it does not even compile, I get the following error which refers > to last instruction at position "x" in "foldr (myInsert) x > (insertionSort xs)": > > Couldn't match expected type ‘[a]’ with actual type ‘a’ A. You should have learnt that the usage of generic functionals such as foldr is to avoid explicit recursion. Please, look up some examples of foldr, for example in https://wiki.haskell.org/Fold, or in the Standard Prelude, say: https://www.haskell.org/onlinereport/standard-prelude.html (e.g., the definition of concat). B. So, no need for pattern split x:xs in your main definition, define just insertionSort xs = ... C. Mind the type of foldr, : (a -> c -> c) -> c -> [a] -> c . The type of your function is ok (parentheses redundant), but the second argument is the initial container (list) while you have chosen "x", which is an element. Here the typechecker protests, but this is not your only mistake. The third element of foldr is the processed container (also list), just it, no recursion. And your first two clauses of insertionSort are useless. Jerzy Karczmarczuk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.waksbaum at gmail.com Thu Sep 29 20:12:13 2016 From: jake.waksbaum at gmail.com (Jake) Date: Thu, 29 Sep 2016 20:12:13 +0000 Subject: [Haskell-cafe] Writing insertionSort using foldr and a helper function In-Reply-To: References: Message-ID: >From an intuitive perspective, I think the first step is to look at the type of foldr and identify what the individual parts of that type mean: *foldr* :: (a -> b -> b) -> b -> [a] -> b foldr takes: - an function that combines the next value (a) and our accumulated value (b) to produce a new accumulated value (b) - an initial value for our accumulator (b) - a list of as to vold ([a]) In this case, our accumulated value is the new list, so the type signature can be rewritten like this: *foldr* :: (a -> [a] -> [a]) -> [a] -> [a] -> [a] Now we can see we need - a function that takes a new element and correctly inserts it into the list in order - an initial value for our output list - a list to sort >From this it should be a lot clearer what to pass to foldr. On Thu, Sep 29, 2016 at 3:58 PM Jerzy Karczmarczuk < jerzy.karczmarczuk at unicaen.fr> wrote: > Le 29/09/2016 à 20:09, jorgemal1960 at gmail.com a écrit : > > I have the following function that takes an element and a list and inserts > the element into the list at the first position where it is less than or > equal to the next element. > > ** This is most probably some pedagogic assignment, and you should not > expect from the community to solve your exercices. > I suspect that you tried to solve the problem without trying to UNDERSTAND > foldr... > But let's see... > > myInsert :: Ord a => a -> [a] -> [a] > myInsert x [] = [x] > myInsert x (y:ys) = if x < y then x:y:ys else y:myInsert x ys > > Now, I have to use the above function myInsert and foldr to implement > another function called insertionSort. I have been able to do it without > using foldr as follows and it works just fine: > > ... > > OK. > > > I have worked for 2 days to use foldr without success, for example: > > insertionSort :: Ord a => [a] -> [a] > insertionSort [] = [] > insertionSort [x] = [x] > insertionSort (x:xs) = foldr (myInsert) x (insertionSort xs) > > But it does not even compile, I get the following error which refers to > last instruction at position "x" in "foldr (myInsert) x (insertionSort > xs)": > > Couldn't match expected type ‘[a]’ with actual type ‘a’ > > > A. You should have learnt that the usage of generic functionals such as > foldr is to avoid explicit recursion. Please, look up some examples of > foldr, for example in https://wiki.haskell.org/Fold, or in the Standard > Prelude, say: https://www.haskell.org/onlinereport/standard-prelude.html > (e.g., the definition of concat). > > B. So, no need for pattern split x:xs in your main definition, define just > insertionSort xs = ... > > C. Mind the type of foldr, : (a -> c -> c) -> c -> [a] -> c . > The type of your function is ok (parentheses redundant), but the second > argument is the initial container (list) while you have chosen "x", which > is an element. Here the typechecker protests, but this is not your only > mistake. > The third element of foldr is the processed container (also list), just > it, no recursion. And your first two clauses of insertionSort are useless. > > > Jerzy Karczmarczuk > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.waksbaum at gmail.com Thu Sep 29 20:28:09 2016 From: jake.waksbaum at gmail.com (Jake) Date: Thu, 29 Sep 2016 20:28:09 +0000 Subject: [Haskell-cafe] Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: References: Message-ID: take 3 $ many $ Just 1 doesn't type check. Did you mean this? take 3 <$> (many $ Just 1) I think this may have something to do with the default definition of many in the definition of Alternative : many :: f a -> f [a ]many v = many_v where many_v = some_v <|> pure [] some_v = (fmap (:) v ) <*> many_v many_v and some_v are mutually recursive functions, and it may be that this prevents the thunks from being made available to take in some way. I'm really not sure though, this is just an idea about why this is not quite the same as (take $ repeat 1) On Thu, Sep 29, 2016 at 3:51 PM Corentin Dupont wrote: > Hi guys, > I'm playing with the mysterious "some" and "many" from Control.Applicative. > If I try: > > many $ Just 1 > > It just loops, I understand why: > > http://stackoverflow.com/questions/18108608/what-are-alternatives-some-and-many-useful-for > It seems that some and many are usually used in a context where something > is consumed, and can be depleted, so the loop ends. > > But why doesn't this terminates? > > take 3 $ many $ Just 1 > > It's a recursive call, but the construction of the result should be lazy... > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Thu Sep 29 21:14:53 2016 From: dave at zednenem.com (David Menendez) Date: Thu, 29 Sep 2016 17:14:53 -0400 Subject: [Haskell-cafe] Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: References: Message-ID: On Thu, Sep 29, 2016 at 4:28 PM, Jake wrote: > I think this may have something to do with the default definition of many in the definition of Alternative : > > many :: f a -> f [a ]many v = many_v where many_v = some_v <|> pure [] some_v = (fmap (:) v ) <*> many_v > > many_v and some_v are mutually recursive functions, and it may be that > this prevents the thunks from being made available to take in some way. I'm > really not sure though, this is just an idea about why this is not quite > the same as (take $ repeat 1) > The problem is that many is creating an infinite sum that’s nested to the left. So you’re trying to compute (((… <|> Just [1,1,1]) <|> Just [1,1]) <|> Just [1]) <|> Just 1 which will never terminate because Maybe is strict in the first argument to <|>. As a practical matter, the Alternative instance for Maybe should probably be changed to either call error or return Just (repeat v). Similarly, we should probably flip the order for many in the instance for []. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From doaitse.swierstra at gmail.com Thu Sep 29 21:15:52 2016 From: doaitse.swierstra at gmail.com (Doaitse Swierstra) Date: Thu, 29 Sep 2016 23:15:52 +0200 Subject: [Haskell-cafe] Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: References: Message-ID: <4984B781-A493-471E-A4A7-FF5F727068FF@gmail.com> The type of the last part of the expression is: many $ Just 1 :: Num a => Maybe [a] So in order to be able to return the “Just” constructor which inspected by the application of (take 3 <$>) we have somehow to know for sure that all the <*> executions will indeed see a “Just” in both of their arguments. This forces more and more evaluations. Doaitse > Op 29 sep. 2016, om 22:28 heeft Jake het volgende geschreven: > > take 3 $ many $ Just 1 > > doesn't type check. Did you mean this? > > take 3 <$> (many $ Just 1) > I think this may have something to do with the default definition of many in the definition of Alternative : > many :: f a -> f [a ] > many <>v = many_v > <> where > <> many_v = some_v <|> pure [] > <> some_v = (fmap (:) v ) <*> many_v > many_v and some_v are mutually recursive functions, and it may be that this prevents the thunks from being made available to take in some way. I'm really not sure though, this is just an idea about why this is not quite the same as (take $ repeat 1) > > On Thu, Sep 29, 2016 at 3:51 PM Corentin Dupont > wrote: > Hi guys, > I'm playing with the mysterious "some" and "many" from Control.Applicative. > If I try: > > many $ Just 1 > > It just loops, I understand why: > http://stackoverflow.com/questions/18108608/what-are-alternatives-some-and-many-useful-for > It seems that some and many are usually used in a context where something is consumed, and can be depleted, so the loop ends. > > But why doesn't this terminates? > > take 3 $ many $ Just 1 > > It's a recursive call, but the construction of the result should be lazy... > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Fri Sep 30 00:23:52 2016 From: monkleyon at googlemail.com (MarLinn) Date: Fri, 30 Sep 2016 02:23:52 +0200 Subject: [Haskell-cafe] Writing insertionSort using foldr and a helper function In-Reply-To: References: Message-ID: I can not add more from a teaching standpoint because I can not see what the underlying real problem is. But it seems there's a stack-overflow-question that is connected. http://stackoverflow.com/questions/39710307/how-do-i-write-insertionsort-using-foldr Please consider including links to existing discussions of a problem in the future. If that question is indeed connected, the down-votes seem to imply you should change your approach. That apparently hasn't happened in the last two days, so I advise trying that. Even if it doesn't help directly, it might bring up new questions that mentors can use as a pivot. Good luck. Cheers, MarLinn From ok at cs.otago.ac.nz Fri Sep 30 02:00:45 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 15:00:45 +1300 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: Message-ID: <38121307-e943-00c1-826c-09a34498ad43@cs.otago.ac.nz> On 30/09/16 3:43 AM, Heinrich Apfelmus wrote: > Also, it's not like other languages all agree on their preferred method > of representing strings: NULL-terminated (C) vs "length-byte-first" > (Pascal) comes to mind. Just in support of that claim, Java *changed* its implementation of strings. Originally, someString.substr(beginIndex, endIndex) took O(1) time and space whatever the values of someString, beginIndex, and endIndex. These days it takes O(endIndex - beginIndex) time and space. And yes, that DID mean that the performance characteristics of many Java programs changed without their authors knowing or intending it. From moritz.angermann at gmail.com Fri Sep 30 02:04:48 2016 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 30 Sep 2016 10:04:48 +0800 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: <2ED3FB49-A1E2-43F5-A0D6-53DE695EBF85@gmail.com> > http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png > > > It's a project that I'm currently working on, called > > HyperHaskell > - the strongly hyped Haskell interpreter - > > Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this. > Nifty! - How does this compare to jupyter (ipython) with the haskell kernel? - Is it on GitHub or somewhere? Cheers, Moritz From ok at cs.otago.ac.nz Fri Sep 30 02:16:21 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 15:16:21 +1300 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> References: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> Message-ID: On 30/09/16 4:18 AM, Joachim Durchholz wrote: > Each language does define its preferred string representation. Java again: it has *two* string representations baked into the language. The Smalltalk system I use most has - read-only strings (preferred) - unique read-only strings - mutable strings - substrings (positionable read-only slices) - extensible strings - streams over strings - lazy concatenations of strings - read-only byte arrays viewed as strings - mutable byte arrays viewed as strings Other Smalltalks typically have four or more concrete kinds of string plus streams over strings; the substring, extensible string, and lazy concatenation libraries I use could be ported to them. From ok at cs.otago.ac.nz Fri Sep 30 02:44:06 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 30 Sep 2016 15:44:06 +1300 Subject: [Haskell-cafe] Writing insertionSort using foldr and a helper function In-Reply-To: References: Message-ID: Just to add to what Jerzy Karczmarczuk wrote: myInsert :: Ord a => a -> [a] -> [a] I find it clearer to think in terms of "should I keep going" (rule 1) "or should I stop and insert now" (rule 2). myInsert x (y : ys) | x>= y = y : myInsert x ys -- continue myInsert x ys = x : ys -- insert now insertionSort :: Ord a => [a] -> [a] insertionSort xs = {- some combination of foldr and insert and xs and something else -} The types really only allow the pieces to be put together one way. Your assignment was almost certainly to use foldr *INSTEAD* of writing a recursive function, leaving foldr to worry about managing the recursion. Let's think about the data type. data [t] -- a list of t = [] -- is an empty list | (:) t [t] -- or a non-empty list with a first -- element that's a t and remaining -- elements forming a smaller list of t This leads to a general recursion pattern f [] = what to do for nil f (x : xs) = what to do for x and (f xs) or foldr :: (t -> r -> r) -> r -> [t] -> r -- cons_handler nil_handler list result foldr c n [] = n foldr c n (x:xs) = c x (foldr c n xs) If you have an instance of that general pattern I mentioned, you can turn it into f = foldr (what to do for x and fxs) (what to do for nil) insertionSort [] = [] insertionSort (x:xs) = insert x (insectionSort xs) is an instance of that general recursion pattern. From tobias.grosser at inf.ethz.ch Fri Sep 30 05:40:41 2016 From: tobias.grosser at inf.ethz.ch (Tobias Grosser) Date: Fri, 30 Sep 2016 07:40:41 +0200 Subject: [Haskell-cafe] PLDI 2017 - Call for Workshops and Tutorials Message-ID: <1475214041.3266369.741569441.393DCBA0@webmail.messagingengine.com> *Call for Workshops and Tutorials* ============================= 2017 ACM Conference on Programming Language Design and Implementation (PLDI) June 19-23, 2017 in Barcelona, Spain http://conf.researchr.org/home/pldi-2017 PLDI 2017 will host co-located workshops and tutorials for which it calls for proposals. This year, PLDI is a part of a large cluster of co-located conferences including ECOOP, Curry On, LCTES, ISMM, DEBS and others. Take your chance in addressing the diverse audience of the premier forum in programming language design and implementation by proposing your event. PLDI welcomes prominent events focusing on programming language design theory and practice, for which it can provide guidance in ublishing results in the ACM Digital Library. * Submission guidelines * ===================== http://conf.researchr.org/track/pldi-2017/pldi-2017-workshops-and-tutorials Please submit proposals in plain text to Workshops and Tutorials Chair Aaron Smith . A proposal should provide: * Name of the workshop/tutorial. * Duration of the workshop/tutorial. * Organizers: names, affiliation, contact information, brief (100 words) biography. * A short description (150-200 words) of the topic. * Event format: workshop/tutorial; type of submissions if any; review process; results dissemination; references to previous events. * Expected attendance and target audience within PLDI community. * Important dates * ================ Published Workshops proposals due 28 Nov 2016 Acceptance Notification 9 Dec 2016 Unpublished Workshops and Tutorials proposals due 30 Jan 2017 Workshop and Tutorials held (tentatively) 18, 22, 23 Jun 2017 *Organizing Committee* ==================== http://conf.researchr.org/committee/pldi-2017/pldi-2017-organizing-committee General Chair: Albert Cohen, INRIA, France Program Chair: Martin Vechev, ETH Zurich, Switzerland Workshops & Tutorials Chair: Aaron Smith, University of Edinburgh Organizing Chair: Fernando Orejas, Universitat Politècnica de Catalunya, Spain Publicity Chairs: Adrian Sampson, Cornell, USA Tobias Grosser, ETH Zurich, Switzerland Web Chair: Oleksandr Zinenko, INRIA, France Financial Chair: Louis-Noël Pouchet, Ohio State University, USA Student Travel Chair: Ronald Mak, San Jose State University, USA From jo at durchholz.org Fri Sep 30 06:17:38 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 30 Sep 2016 08:17:38 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> Message-ID: <930deee3-c1e3-98e0-49ba-b750abfdc449@durchholz.org> Am 30.09.2016 um 04:16 schrieb Richard A. O'Keefe: > > On 30/09/16 4:18 AM, Joachim Durchholz wrote: >> Each language does define its preferred string representation. > > Java again: it has *two* string representations baked into the > language. There is a single standard representation. I'm not even aware of a second one, and I've been programming Java for quite a while now. Unless you mean StringBuilder/StringBuffer (that would be three String types then). However, these classes are by no means "preferred" in practice: the vast majority of APIs demands and returns String objects. Even then, Java has its preferred string representation nailed down pretty strongly: a hidden array of 16-bit Unicode code points, referenced by a descriptor object (the actual String), immutable. > The Smalltalk system I use most has > - read-only strings (preferred) > - unique read-only strings > - mutable strings > - substrings (positionable read-only slices) > - extensible strings > - streams over strings > - lazy concatenations of strings > - read-only byte arrays viewed as strings > - mutable byte arrays viewed as strings Ah, Smalltalk. I haven't looked at that in ages. I'll give you that these classes all exist, but I am not sure whether a Smalltalk programmer would consider them all equivalent or not. From tdammers at gmail.com Fri Sep 30 06:44:12 2016 From: tdammers at gmail.com (Tobias Dammers) Date: Fri, 30 Sep 2016 08:44:12 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <930deee3-c1e3-98e0-49ba-b750abfdc449@durchholz.org> References: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> <930deee3-c1e3-98e0-49ba-b750abfdc449@durchholz.org> Message-ID: FWIW, C++ has: - char* and const char*, inherited from C - wchar_t*, const wchar_t* - the above, but with an explicit length passed along as a separate argument - std::string - std::wstring (is that what it's called?) - various string implementations, provided by platform APIs and frameworks (QString, LPTCHAR, and other nonsense) And they all suck - most are really just byte arrays, some try to implement Unicode but fall short, and the ones that do it mostly right are specific to a sub-ecosystem. It's a mess. And do I need to mention PHP? That one doesn't have a useful string type at all, and also lacks the language feature to build it yourself - you're stuck with broken semantics either way, best you can hope for is that they are only mildly broken and you can get away with it. C, by the way, shares C++'s problem, except that it doesn't even come with a string type that does bounds checking. And finally: while Haskell makes you choose between "byte array", "string", and "list of code points", this isn't really awfully different from languages like Java or C#, where you make a similar choice (string? StringBuilder? byte[]?), except that the default is saner (for historical reasons). Well, that, and that there are lazy flavors of the packed string amd bytestring types, which has nothing to do with string type choices and everything with defaulting to and leveraging non-strict semantics. On Sep 30, 2016 8:17 AM, "Joachim Durchholz" wrote: > Am 30.09.2016 um 04:16 schrieb Richard A. O'Keefe: > >> >> On 30/09/16 4:18 AM, Joachim Durchholz wrote: >> >>> Each language does define its preferred string representation. >>> >> >> Java again: it has *two* string representations baked into the >> language. >> > > There is a single standard representation. > I'm not even aware of a second one, and I've been programming Java for > quite a while now. > > Unless you mean StringBuilder/StringBuffer (that would be three String > types then). However, these classes are by no means "preferred" in > practice: the vast majority of APIs demands and returns String objects. > > Even then, Java has its preferred string representation nailed down pretty > strongly: a hidden array of 16-bit Unicode code points, referenced by a > descriptor object (the actual String), immutable. > > The Smalltalk system I use most has >> - read-only strings (preferred) >> - unique read-only strings >> - mutable strings >> - substrings (positionable read-only slices) >> - extensible strings >> - streams over strings >> - lazy concatenations of strings >> - read-only byte arrays viewed as strings >> - mutable byte arrays viewed as strings >> > > Ah, Smalltalk. I haven't looked at that in ages. > I'll give you that these classes all exist, but I am not sure whether a > Smalltalk programmer would consider them all equivalent or not. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Sep 30 07:54:43 2016 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 30 Sep 2016 09:54:43 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <5b804206-8afc-24cd-88aa-d26cab5a2617@durchholz.org> <930deee3-c1e3-98e0-49ba-b750abfdc449@durchholz.org> Message-ID: <71851e0f-074e-d29f-0197-acc8414293de@durchholz.org> Am 30.09.2016 um 08:44 schrieb Tobias Dammers: > FWIW, C++ has: > > - char* and const char*, inherited from C > - wchar_t*, const wchar_t* > - the above, but with an explicit length passed along as a separate argument > - std::string > - std::wstring (is that what it's called?) > - various string implementations, provided by platform APIs and > frameworks (QString, LPTCHAR, and other nonsense) > > And they all suck - most are really just byte arrays, some try to > implement Unicode but fall short, and the ones that do it mostly right > are specific to a sub-ecosystem. It's a mess. Yep - preferred type was the zero-terminated byte array, and after that things have diverged. > And do I need to mention PHP? That one doesn't have a useful string type > at all, It's still a string type :-) > And finally: while Haskell makes you choose between "byte array", > "string", and "list of code points", this isn't really awfully different > from languages like Java or C#, where you make a similar choice (string? > StringBuilder? byte[]?), At least in Java, you don't really choose, circumstances dictate. String are immutable. Nice semantics, O(N^2) for N concatenations. Vast majority of APIs uses this, most strongly preferred. StringBuilder is mutable. In practice, people use it as a scratchpad to construct Strings if they need a loop. Majority of cases is local variables, libraries with the purpose of constructing a large output string tend to have a collect-the-output buffer and pass that around internally but don't expose it to callers (maybe to callbacks, haven't seen that done though). byte[] for string manipulation is a really itchy hair shirt, you don't do that unless very strong reasons compel you to. I am aware of exactly two use cases: Password storage (to be able to wipe the data ASAP), and converting from and to external byte streams that carry text. So it's all straightforward, and String is really the preferred use case. There's a lot of things that Java doesn't get quite right, but string handling is not one of these :-) From corentin.dupont at gmail.com Fri Sep 30 08:02:42 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 30 Sep 2016 10:02:42 +0200 Subject: [Haskell-cafe] Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: <4984B781-A493-471E-A4A7-FF5F727068FF@gmail.com> References: <4984B781-A493-471E-A4A7-FF5F727068FF@gmail.com> Message-ID: Thanks for the replies... What I'm trying to do is a simple input system: query :: IO (Maybe String) query = do putStrLn "Enter text or press q:" r <- getLine return $ if r == "q" then Nothing else Just r This will ask an input to the user which is returned, unless "q" is pressed. I want to repeat this query "some" or "many" times: main = do qs <- some $ query -- qs <- many $ query putStrLn qs This should ask the query multiple times until "q" is pressed. The type of qs is Maybe [String]. The expected result is that with "some", returning zero results will not be permitted, while with "many" it is. Probably I should defined a newtype for IO Maybe: data IOMaybe a = IOMaybe {getIOMaybe :: IO (Maybe a)} And define all the instances. Or use Data.Fucntor.Compose: type IOMaybe = Compose IO Maybe On Thu, Sep 29, 2016 at 11:15 PM, Doaitse Swierstra < doaitse.swierstra at gmail.com> wrote: > The type of the last part of the expression is: > > many $ Just 1 :: Num a => Maybe [a] > > So in order to be able to return the “Just” constructor which inspected by > the application of (take 3 <$>) we have somehow to know for sure that all > the <*> executions will indeed see a “Just” in both of their arguments. > This forces more and more evaluations. > > Doaitse > > > Op 29 sep. 2016, om 22:28 heeft Jake het > volgende geschreven: > > take 3 $ many $ Just 1 > > doesn't type check. Did you mean this? > > take 3 <$> (many $ Just 1) > > I think this may have something to do with the default definition of many in the definition of Alternative : > > many :: f a -> f [a ]many v = many_v where many_v = some_v <|> pure [] some_v = (fmap (:) v ) <*> many_v > > many_v and some_v are mutually recursive functions, and it may be that > this prevents the thunks from being made available to take in some way. I'm > really not sure though, this is just an idea about why this is not quite > the same as (take $ repeat 1) > > On Thu, Sep 29, 2016 at 3:51 PM Corentin Dupont > wrote: > >> Hi guys, >> I'm playing with the mysterious "some" and "many" from >> Control.Applicative. >> If I try: >> >> many $ Just 1 >> >> It just loops, I understand why: >> http://stackoverflow.com/questions/18108608/what-are- >> alternatives-some-and-many-useful-for >> It seems that some and many are usually used in a context where something >> is consumed, and can be depleted, so the loop ends. >> >> But why doesn't this terminates? >> >> take 3 $ many $ Just 1 >> >> It's a recursive call, but the construction of the result should be >> lazy... >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apfelmus at quantentunnel.de Fri Sep 30 08:22:55 2016 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri, 30 Sep 2016 10:22:55 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: <2ED3FB49-A1E2-43F5-A0D6-53DE695EBF85@gmail.com> References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> <2ED3FB49-A1E2-43F5-A0D6-53DE695EBF85@gmail.com> Message-ID: >> HyperHaskell > > Nifty! > > - How does this compare to jupyter (ipython) with the haskell kernel? The overall goal is obviously very similar. To me, the main differences are * HyperHaskell should be easy to install (e.g. only cabal and a binary download) * HyperHaskell behaves more like a desktop application, e.g. worksheets are loaded from and saved to the local file system. The latter point is actually the main reason why I couldn't get into Jupyter at all: It insisted that I manage worksheets in some kind of database in the browser. Ugh! (There may be other front-ends nowadays, but last I checked, I didn't find anything official or popular, that's why I decided to write my own thing.) On the flip side, HyperHaskell is specialized to Haskell -- you can't use it with other languages. > - Is it on GitHub or somewhere? Not yet, it's still in the "hype" phase. ;-) Expect the following location https://github.com/HeinrichApfelmus/hyper-haskell to fill with code in a week or two. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Moritz Angermann wrote: >> http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png >> >> >> It's a project that I'm currently working on, called >> >> HyperHaskell >> - the strongly hyped Haskell interpreter - >> >> Well, it's supposed to be strongly hyped, but currently, only few people know about it. Could you give me a hand with, uh, hyping this? I'm not good at this. >> > > Nifty! > > - How does this compare to jupyter (ipython) with the haskell kernel? > - Is it on GitHub or somewhere? > > Cheers, > Moritz > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From toad3k at gmail.com Fri Sep 30 08:44:40 2016 From: toad3k at gmail.com (David McBride) Date: Fri, 30 Sep 2016 04:44:40 -0400 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> <2ED3FB49-A1E2-43F5-A0D6-53DE695EBF85@gmail.com> Message-ID: Consider me hyped. I could never get jupyter to work. On Fri, Sep 30, 2016 at 4:22 AM, Heinrich Apfelmus < apfelmus at quantentunnel.de> wrote: > HyperHaskell >>> >> >> Nifty! >> >> - How does this compare to jupyter (ipython) with the haskell kernel? >> > > The overall goal is obviously very similar. To me, the main differences are > > * HyperHaskell should be easy to install > (e.g. only cabal and a binary download) > > * HyperHaskell behaves more like a desktop application, e.g. worksheets > are loaded from and saved to the local file system. > > The latter point is actually the main reason why I couldn't get into > Jupyter at all: It insisted that I manage worksheets in some kind of > database in the browser. Ugh! (There may be other front-ends nowadays, but > last I checked, I didn't find anything official or popular, that's why I > decided to write my own thing.) > > On the flip side, HyperHaskell is specialized to Haskell -- you can't use > it with other languages. > > - Is it on GitHub or somewhere? >> > > Not yet, it's still in the "hype" phase. ;-) Expect the following location > > https://github.com/HeinrichApfelmus/hyper-haskell > > to fill with code in a week or two. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > Moritz Angermann wrote: > >> http://apfelmus.nfshost.com/temp/hyper-haskell-sneak-peek.png >>> >>> >>> It's a project that I'm currently working on, called >>> >>> HyperHaskell >>> - the strongly hyped Haskell interpreter - >>> >>> Well, it's supposed to be strongly hyped, but currently, only few people >>> know about it. Could you give me a hand with, uh, hyping this? I'm not good >>> at this. >>> >>> >> Nifty! >> >> - How does this compare to jupyter (ipython) with the haskell kernel? >> - Is it on GitHub or somewhere? >> >> Cheers, >> Moritz >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Fri Sep 30 13:06:18 2016 From: gurudev.devanla at gmail.com (Gurudev Devanla) Date: Fri, 30 Sep 2016 06:06:18 -0700 (PDT) Subject: [Haskell-cafe] Library pretty print values in Tabular format Message-ID: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> Hello All, I am happy to publish a new library on Hackage that lets one print values contained in lists, maps, vectors in a tabular format. This is motivated from the output I am used to seeing while using the Pandas library in Python. This is my first Haskell library and I look forward to feedback and suggestions on improving the library. https://hackage.haskell.org/package/pptable https://github.com/gdevanla/pptable#readme One thing, which I right away do not like about the library is the constraints where the values will have to derive from both Data.Data and GHC.Generic.Generics. Thank you and I look forward to some feedback. Regards Guru P.S: I spent a lot of time trying to make Hackage produce the haddock links. Any pointers to that would be helpful. And "stack sdist" does not package the documentation automatically. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Fri Sep 30 14:36:16 2016 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Fri, 30 Sep 2016 16:36:16 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: Hi, Theodore Lief Gannon wrote: > GTK on Windows is trivial at this point, with stack and LTS 7+. Try it > yourself: > > stack exec -- pacman -S mingw-w64-x86_64-gtk3 > stack install gtk2hs-buildtools > stack install gtk3 --flag gtk3:build-demos > gtk2hs-demo-carsim > > (I didn't start 100% clean but I don't *think* there are any other > pacman packages required...) I had to first work around a pacman issue: stack exec -- pacman -Sy stack exec -- pacman -S pacman-mirrors And then I had to install pkg-config: stack exec -- pacman -S mingw-w64-x86_64-pkg-config Then the installation commands you provided worked for me. However, I could not just run gtk2hs-demo-carsim but had to run the following to expose the GTK DLLs to the executable: stack exec -- gtk2hs-demo-carsim Not trivial, but certainly much better than it used to be. (Still too hard for beginners in some setups. For example, in Tübingen, we have an introductionary programming lecture with 500 students. We cannot provide installation support that scales to that number of students, so our programming environment has to install flawlessly on stock Windows laptops, preferably without having to use the command line at all. We want to spend the first lab session programming, not setting up.) Tillmann From ivan.miljenovic at gmail.com Fri Sep 30 14:50:32 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 30 Sep 2016 23:50:32 +0900 Subject: [Haskell-cafe] Library pretty print values in Tabular format In-Reply-To: References: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> Message-ID: Actually sending this to the list (no idea where the googlegroups bit came from). On 30 September 2016 at 23:49, Ivan Lazar Miljenovic wrote: > On 30 September 2016 at 22:06, Gurudev Devanla > wrote: >> Hello All, >> >> I am happy to publish a new library on Hackage that lets one print values >> contained in lists, maps, vectors in a tabular format. This is motivated >> from the output I am used to seeing while using the Pandas library in >> Python. This is my first Haskell library and I look forward to feedback and >> suggestions on improving the library. >> >> https://hackage.haskell.org/package/pptable >> https://github.com/gdevanla/pptable#readme >> >> One thing, which I right away do not like about the library is the >> constraints where the values will have to derive from both Data.Data and >> GHC.Generic.Generics. > > You could provide a type-class for values as well; this would also > help avoid the usage of get_type == "Bool" that you have. > >> Thank you and I look forward to some feedback. >> >> Regards >> Guru >> >> P.S: I spent a lot of time trying to make Hackage produce the haddock >> links. Any pointers to that would be helpful. And "stack sdist" does not >> package the documentation automatically. > > Hackage should automatically generate the documentation after a period > of time; they are generated server-side not client-side (hence why > "stack sdist" didn't generate them). > >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From trebla at vex.net Fri Sep 30 19:31:05 2016 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 30 Sep 2016 15:31:05 -0400 Subject: [Haskell-cafe] Fwd: Alternative: you can fool many people some time, and some people many time, but... In-Reply-To: References: Message-ID: <05751b1f-649b-51ce-caca-d905ae906021@vex.net> On 2016-09-29 03:49 PM, Corentin Dupont wrote: > But why doesn't this terminates? > > take 3 $ many $ Just 1 That looks like a type error rather than non-termination. From apfelmus at quantentunnel.de Fri Sep 30 20:17:44 2016 From: apfelmus at quantentunnel.de (Heinrich Apfelmus) Date: Fri, 30 Sep 2016 22:17:44 +0200 Subject: [Haskell-cafe] Library pretty print values in Tabular format In-Reply-To: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> References: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> Message-ID: I like it! One feature I would like to see: Have you considered aligning decimal points? I.e. an output along the lines of ticker price marketCap "YHOO" 42.2910101 0.40 e11 "GOOG" 774.210101 5.3209 e11 "AMZN" 799.161717 3.7886 e11 or something like that. In this format, it is easier to survey the order of magnitude of a quantity. Then again, exponents `e10` may be trickier to handle. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Gurudev Devanla wrote: > Hello All, > > I am happy to publish a new library on Hackage that lets one print values > contained in lists, maps, vectors in a tabular format. This is motivated > from the output I am used to seeing while using the Pandas library in > Python. This is my first Haskell library and I look forward to feedback and > suggestions on improving the library. > > https://hackage.haskell.org/package/pptable > https://github.com/gdevanla/pptable#readme > > One thing, which I right away do not like about the library is the > constraints where the values will have to derive from both Data.Data and > GHC.Generic.Generics. > > Thank you and I look forward to some feedback. > > Regards > Guru > > P.S: I spent a lot of time trying to make Hackage produce the haddock > links. Any pointers to that would be helpful. And "stack sdist" does not > package the documentation automatically. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tonyday567 at gmail.com Fri Sep 30 20:28:49 2016 From: tonyday567 at gmail.com (Tony Day) Date: Fri, 30 Sep 2016 20:28:49 +0000 Subject: [Haskell-cafe] Library pretty print values in Tabular format In-Reply-To: References: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> Message-ID: Would it be possible to go polymorphic on the container shape? Eg Rather than having toBoxVector etc, create a Traversable a => Boxable a class with a toBox method etc. If you go aligning decimals, the Formatting library would come in handy. On Sat, Oct 1, 2016 at 6:18 AM Heinrich Apfelmus wrote: > I like it! > > One feature I would like to see: Have you considered aligning decimal > points? I.e. an output along the lines of > > ticker price marketCap > "YHOO" 42.2910101 0.40 e11 > "GOOG" 774.210101 5.3209 e11 > "AMZN" 799.161717 3.7886 e11 > > or something like that. In this format, it is easier to survey the order > of magnitude of a quantity. Then again, exponents `e10` may be trickier > to handle. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > > Gurudev Devanla wrote: > > Hello All, > > > > I am happy to publish a new library on Hackage that lets one print values > > contained in lists, maps, vectors in a tabular format. This is motivated > > from the output I am used to seeing while using the Pandas library in > > Python. This is my first Haskell library and I look forward to feedback > and > > suggestions on improving the library. > > > > https://hackage.haskell.org/package/pptable > > https://github.com/gdevanla/pptable#readme > > > > One thing, which I right away do not like about the library is the > > constraints where the values will have to derive from both Data.Data and > > GHC.Generic.Generics. > > > > Thank you and I look forward to some feedback. > > > > Regards > > Guru > > > > P.S: I spent a lot of time trying to make Hackage produce the haddock > > links. Any pointers to that would be helpful. And "stack sdist" does not > > package the documentation automatically. > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Fri Sep 30 20:44:38 2016 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Fri, 30 Sep 2016 13:44:38 -0700 Subject: [Haskell-cafe] Library pretty print values in Tabular format In-Reply-To: References: <930df54b-e0bd-4cb3-896d-32f9388cbd24@googlegroups.com> Message-ID: Thanks for the feedback. @Heinrich Yes, that would be nice. I was hoping in the future, I could allow for the user to set some kind of precision value. That would make sure we have a fixed number of digits after the decimal. May be for now, I could "fix" that value and make it align. @Tony Yes, I do have a piece of code commented out where I attempted to make it generic but did not pursue that option. Your suggestion is very valid and I am hoping to get there. On Fri, Sep 30, 2016 at 1:28 PM, Tony Day wrote: > Would it be possible to go polymorphic on the container shape? Eg Rather > than having toBoxVector etc, create a Traversable a => Boxable a class with > a toBox method etc. > > If you go aligning decimals, the Formatting library would come in handy. > > On Sat, Oct 1, 2016 at 6:18 AM Heinrich Apfelmus < > apfelmus at quantentunnel.de> wrote: > >> I like it! >> >> One feature I would like to see: Have you considered aligning decimal >> points? I.e. an output along the lines of >> >> ticker price marketCap >> "YHOO" 42.2910101 0.40 e11 >> "GOOG" 774.210101 5.3209 e11 >> "AMZN" 799.161717 3.7886 e11 >> >> or something like that. In this format, it is easier to survey the order >> of magnitude of a quantity. Then again, exponents `e10` may be trickier >> to handle. >> >> >> Best regards, >> Heinrich Apfelmus >> >> -- >> http://apfelmus.nfshost.com >> >> >> Gurudev Devanla wrote: >> > Hello All, >> > >> > I am happy to publish a new library on Hackage that lets one print >> values >> > contained in lists, maps, vectors in a tabular format. This is motivated >> > from the output I am used to seeing while using the Pandas library in >> > Python. This is my first Haskell library and I look forward to feedback >> and >> > suggestions on improving the library. >> > >> > https://hackage.haskell.org/package/pptable >> > https://github.com/gdevanla/pptable#readme >> > >> > One thing, which I right away do not like about the library is the >> > constraints where the values will have to derive from both Data.Data and >> > GHC.Generic.Generics. >> > >> > Thank you and I look forward to some feedback. >> > >> > Regards >> > Guru >> > >> > P.S: I spent a lot of time trying to make Hackage produce the haddock >> > links. Any pointers to that would be helpful. And "stack sdist" does >> not >> > package the documentation automatically. >> > >> > >> > >> > >> > ------------------------------------------------------------ >> ------------ >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Fri Sep 30 20:48:29 2016 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Fri, 30 Sep 2016 13:48:29 -0700 Subject: [Haskell-cafe] Question regarding Candidate Package builds Message-ID: Is there any information on what kinds of checks happen on candidate packages that are uploaded. There was a cabal error on a published build. So, I have fixed that and have uploaded a candidate package. I was hoping the same build/checks happen on the candidate package, but I have not seen that happen. This link on the HOME page is very old and does not give any definitive information on what is currently working: https://github.com/haskell/hackage-server/issues/41#issuecomment-25005344 Thanks Guru -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Fri Sep 30 20:50:11 2016 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 30 Sep 2016 16:50:11 -0400 Subject: [Haskell-cafe] [Haskell] Branch Streaming (was GHC is a monopoly compiler) In-Reply-To: References: Message-ID: <23a0e68d-fac4-a3c8-91ad-f09927106ffa@stilo.com> On 2016-09-28 05:20 PM, Tony Day wrote: > I've actually looked down that particular rabbit hole. Here's a link to > a monoid for pipes that represents a branch: > > https://github.com/tonyday567/pipes-extended/blob/master/src/Pipes/Monoid.hs#L81 > > For flavour, the computation involves hoisting and lifting back and > forth over several layers, as the various meta-physical wires cross. > That was years ago, but I haven't seen anything since. It looks like > Pipes is the wrong abstraction point to stream with branching. I wonder > what is? I'm not working on it any longer, but that's what SCC [1] was set up to explore. [1] http://hackage.haskell.org/package/scc From tanuki at gmail.com Fri Sep 30 21:23:27 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Fri, 30 Sep 2016 14:23:27 -0700 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: D'oh, pkg-config of course. And I took an initial 'pacman -Syu' for granted but I suppose that's not documented anywhere specific to Stack... probably worth doing. Interesting that you had to invoke through stack exec, tho... do you have dynamic linking in your global config? AFAIK static is default on Windows, so the DLLs don't matter after linking. On Fri, Sep 30, 2016 at 7:36 AM, Tillmann Rendel < rendel at informatik.uni-tuebingen.de> wrote: > Hi, > > Theodore Lief Gannon wrote: > >> GTK on Windows is trivial at this point, with stack and LTS 7+. Try it >> yourself: >> >> stack exec -- pacman -S mingw-w64-x86_64-gtk3 >> stack install gtk2hs-buildtools >> stack install gtk3 --flag gtk3:build-demos >> gtk2hs-demo-carsim >> >> (I didn't start 100% clean but I don't *think* there are any other >> pacman packages required...) >> > > I had to first work around a pacman issue: > > stack exec -- pacman -Sy > stack exec -- pacman -S pacman-mirrors > > And then I had to install pkg-config: > > stack exec -- pacman -S mingw-w64-x86_64-pkg-config > > Then the installation commands you provided worked for me. > > However, I could not just run gtk2hs-demo-carsim but had to run the > following to expose the GTK DLLs to the executable: > > stack exec -- gtk2hs-demo-carsim > > Not trivial, but certainly much better than it used to be. > > (Still too hard for beginners in some setups. For example, in Tübingen, we > have an introductionary programming lecture with 500 students. We cannot > provide installation support that scales to that number of students, so our > programming environment has to install flawlessly on stock Windows laptops, > preferably without having to use the command line at all. We want to spend > the first lab session programming, not setting up.) > > Tillmann > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Fri Sep 30 22:35:29 2016 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Sat, 1 Oct 2016 00:35:29 +0200 Subject: [Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler) In-Reply-To: References: <3AB97729-78B8-41A2-AAEC-2B8E6EC02793@aatal-apotheke.de> Message-ID: <2a0307cf-245e-8eaa-532b-702d1c540886@informatik.uni-tuebingen.de> Hi, Theodore Lief Gannon wrote: > D'oh, pkg-config of course. And I took an initial 'pacman -Syu' for > granted but I suppose that's not documented anywhere specific to > Stack... probably worth doing. So installing gtk is trivial ... ... assuming you know how to operate pacman and setup pkg-config in a mingw environment? Almost there, almost. ;) > Interesting that you had to invoke through stack exec, tho... do you > have dynamic linking in your global config? AFAIK static is default on > Windows, so the DLLs don't matter after linking. I didn't change any global config options related to linking. Note that the issue is with the gtk DLLs, not ghc-produced DLLs. I guess gtk is always dynamically linked, and you didn't run into this when you tested because you have GTK installed system-wide, too. Tillmann