From codygman.consulting at gmail.com Wed Nov 1 06:43:46 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Wed, 1 Nov 2017 01:43:46 -0500 Subject: [Haskell-cafe] Amazonka: How to generate S3:// uri from Network.AWS.S3.Types.Object? Message-ID: Question: How can I generate an S3://absolute/url from an Object ( https://hackage.haskell.org/package/amazonka-s3-1.4.5/docs/Network-AWS-S3-Types.html#t:Object )? Context: I've been using turtle to call "aws s3 ls" and I'm trying to figure out how to replace that with amazonka. Absolute s3 urls were central to how my program worked. I KNow how to get objects now and filter them, but I don't know how to convert an object to an S3 url to integrate with my existing program. I came across the getFile function ( https://github.com/brendanhay/amazonka/blob/4fdd746346323aac7de6e82752b16609ef0bf212/examples/src/Example/S3.hs#L65) and tried downloading a file from s3. Perhaps I had something wrong, but it didn't seem like just the S3 Bucket and S3 Object key were enough to download a given file. If I'm wrong about that I need to double check my configuration. Thanks, Cody Goodman -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor at fausak.me Wed Nov 1 14:34:17 2017 From: taylor at fausak.me (Taylor Fausak) Date: Wed, 01 Nov 2017 09:34:17 -0500 Subject: [Haskell-cafe] First annual Haskell users survey Message-ID: <1509546857.3330814.1158127000.7742182E@webmail.messagingengine.com> https://haskellweekly.news/surveys/2017.html I am super excited to announce this survey! It is inspired by Rust’s recent surveys and Johan Tibell’s state of Haskell surveys from a few years ago. The goal of this survey is to better understand how Haskell users feel about the language, ecosystem, and community. So please, if you’re reading this: Take 10 minutes and fill out the survey. Thanks! From mark.fine at gmail.com Thu Nov 2 03:43:36 2017 From: mark.fine at gmail.com (Mark Fine) Date: Wed, 1 Nov 2017 20:43:36 -0700 Subject: [Haskell-cafe] Amazonka: How to generate S3:// uri from Network.AWS.S3.Types.Object? In-Reply-To: References: Message-ID: The *getFile* example downloads and object from S3 and "sinks" its contents to a file. To integrate with an existing program that's using S3 URIs, you can build it with the bucket and key: s3Uri :: BucketName -> ObjectKey -> Text s3Uri (BucketName bn) (ObjectKey ok) = "s3://" <> bn <> "/" <> ok There are also presigned S3 URLs (also in the examples file), but those are for HTTP requests, not aws cli requests. Using turtle with with aws cli is great - nice light way to get AWS functionality without going pulling in amazonka. Mark On Tue, Oct 31, 2017 at 11:43 PM, Cody Goodman < codygman.consulting at gmail.com> wrote: > > Question: How can I generate an S3://absolute/url from an Object ( > https://hackage.haskell.org/package/amazonka-s3-1.4.5/ > docs/Network-AWS-S3-Types.html#t:Object)? > > Context: I've been using turtle to call "aws s3 ls" and I'm trying to > figure out how to replace that with amazonka. Absolute s3 urls were central > to how my program worked. I KNow how to get objects now and filter them, > but I don't know how to convert an object to an S3 url to integrate with my > existing program. > > I came across the getFile function (https://github.com/ > brendanhay/amazonka/blob/4fdd746346323aac7de6e82752b166 > 09ef0bf212/examples/src/Example/S3.hs#L65) and tried downloading a file > from s3. > > Perhaps I had something wrong, but it didn't seem like just the S3 Bucket > and S3 Object key were enough to download a given file. If I'm wrong about > that I need to double check my configuration. > > Thanks, > > Cody Goodman > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 saul-mirone at qq.com Sat Nov 4 10:48:58 2017 From: saul-mirone at qq.com (=?ISO-8859-1?B?bWlyb25l?=) Date: Sat, 4 Nov 2017 18:48:58 +0800 Subject: [Haskell-cafe] Replace list item with list. Message-ID: Hello everyone! If I have a list A : ["x", "y", "z"] and a list B: ["f", "g"]. Here is my question: What's the simplest way to replace "z" in the list A by list B, and get ["x", "y", "f", "g"] ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From flyingsheep at qq.com Sat Nov 4 10:57:23 2017 From: flyingsheep at qq.com (=?gb18030?B?Rmx5aW5nU2hlZXA=?=) Date: Sat, 4 Nov 2017 18:57:23 +0800 Subject: [Haskell-cafe] =?gb18030?b?u9i4tKO6IFJlcGxhY2UgbGlzdCBpdGVtIHdp?= =?gb18030?q?th_list=2E?= In-Reply-To: References: Message-ID: (take 2 A) ++ B ------------------ 李 鹏 四川大学计算机学院 ------------------ 原始邮件 ------------------ 发件人: "mirone"; 发送时间: 2017年11月4日(星期六) 晚上6:48 收件人: "haskell-cafe"; 主题: [Haskell-cafe] Replace list item with list. Hello everyone! If I have a list A : ["x", "y", "z"] and a list B: ["f", "g"]. Here is my question: What's the simplest way to replace "z" in the list A by list B, and get ["x", "y", "f", "g"] ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jho.xray at gmail.com Sat Nov 4 11:05:51 2017 From: jho.xray at gmail.com (J Ho) Date: Sat, 4 Nov 2017 12:05:51 +0100 Subject: [Haskell-cafe] asking for feedback: "Magical Haskell" book in progress Message-ID: Dear Haskellers, I've systematized my notes from the last 3 years, bit the bullet and started working on the visual Haskell teaching book that had been my desire for a long time now :) The goal is to build it on the proper math foundation of type and category theory to structure concepts and functional patterns as they apply to real world problems neatly from the start, without relying on imperative language experience too much, but make it *visual*, easy to grasp, and not *math-technically* heavy. Basically, I was thinking *"how do I teach Haskell to my kids?"* and *"how would people who learned only functional programming from school, without any imperative exposure, think?"* (I don't think such people exist yet but I sure would like to speak to those if / when they appear :) - but the goal is to make it accessible to, hopefully, teens with some reasonable math and / or programming background, and also, in the later chapters, make it useful to adults who better grasp concepts visually (as I do) to have a neat and systematized Haskell concepts building in their brain. Here's the direct link to the first chapter: Wizards, Types and Functions Here's the book's page on leanpub that gets gradually updated as usual, and it will of course always stay free. Would very much appreciate your feedback, suggestions and thoughts! If you have another 7 minutes to spare and want more context, here's a more expanded rationale to this approach to teaching haskell - "Haskell Is Not Programming " - to which I received some very valuable feedback (and some understandable imperative camp critique :)) ) on reddit already, which helped me adjust the book itself. Thanks a lot! Best regards, - J. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nolane16 at gmail.com Sat Nov 4 11:50:49 2017 From: nolane16 at gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQnNC40YDQt9C+0LXQsg==?=) Date: Sat, 4 Nov 2017 14:50:49 +0300 Subject: [Haskell-cafe] =?utf-8?b?5Zue5aSN77yaIFJlcGxhY2UgbGlzdCBpdGVtIHdp?= =?utf-8?q?th_list=2E?= In-Reply-To: References: Message-ID: If you sure "z" is the last element of A you can use init A ++ B if it's somwhere in the middle consider cocat $ map f A where f x | x == "z" = B | otherwise = [x] On Sat, Nov 4, 2017 at 2:41 PM, Денис Мирзоев wrote: > If you sure "z" is the last element of A you can use > > init A ++ B > > if it's somwhere in the middle consider > > cocat $ map f A > where > f x > | x == "z" = B > | otherwise = [x] > > On Sat, Nov 4, 2017 at 1:57 PM, FlyingSheep wrote: > >> (take 2 A) ++ B >> >> ------------------ >> 李 鹏 >> 四川大学计算机学院 >> >> >> >> ------------------ 原始邮件 ------------------ >> *发件人:* "mirone"; >> *发送时间:* 2017年11月4日(星期六) 晚上6:48 >> *收件人:* "haskell-cafe"; >> *主题:* [Haskell-cafe] Replace list item with list. >> >> Hello everyone! >> If I have a list A : ["x", "y", "z"] >> and a list B: ["f", "g"]. >> Here is my question: >> What's the simplest way to replace "z" in the list A by list B, and get >> ["x", "y", "f", "g"] ? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 dvdalilue at gmail.com Sat Nov 4 12:47:03 2017 From: dvdalilue at gmail.com (David Lilue) Date: Sat, 4 Nov 2017 08:47:03 -0400 Subject: [Haskell-cafe] =?utf-8?b?5Zue5aSN77yaIFJlcGxhY2UgbGlzdCBpdGVtIHdp?= =?utf-8?q?th_list=2E?= Message-ID: There is a function "concatMap" to simplify "concat $ map". Furthermore, you could use inline notation as follow: concatMap (\x -> x == "z" then B else [x]) A On Sat, Nov 4, 2017 at 7:50 AM, Денис Мирзоев wrote: > If you sure "z" is the last element of A you can use > > init A ++ B > > if it's somwhere in the middle consider > > cocat $ map f A > where > f x > | x == "z" = B > | otherwise = [x] > > On Sat, Nov 4, 2017 at 2:41 PM, Денис Мирзоев wrote: > >> If you sure "z" is the last element of A you can use >> >> init A ++ B >> >> if it's somwhere in the middle consider >> >> cocat $ map f A >> where >> f x >> | x == "z" = B >> | otherwise = [x] >> >> On Sat, Nov 4, 2017 at 1:57 PM, FlyingSheep wrote: >> >>> (take 2 A) ++ B >>> >>> ------------------ >>> 李 鹏 >>> 四川大学计算机学院 >>> >>> >>> >>> ------------------ 原始邮件 ------------------ >>> *发件人:* "mirone"; >>> *发送时间:* 2017年11月4日(星期六) 晚上6:48 >>> *收件人:* "haskell-cafe"; >>> *主题:* [Haskell-cafe] Replace list item with list. >>> >>> Hello everyone! >>> If I have a list A : ["x", "y", "z"] >>> and a list B: ["f", "g"]. >>> Here is my question: >>> What's the simplest way to replace "z" in the list A by list B, and get >>> ["x", "y", "f", "g"] ? >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 seanmatthews1 at gmail.com Sat Nov 4 21:39:55 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Sat, 4 Nov 2017 22:39:55 +0100 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless Message-ID: I have just reinstalled everything. Newest release of emacs, Haskell-pakage and Haskell-mode and Haskell. I have tried to do this as cleanly as possible (via the customise and package install interfaces). Now when I try to edit haskell files, the system keeps freezing to report types. Nothing that I try (setting configuration variables, etc.) has any effect. I know that there is a problem with parsing the command line with the newest version of GHCi, but I think I can avoid that by using :load instead of C-c C-l. This freezing problem, however, is another level of problem. It renders my emacs basically useless for editing haskell. Anybody recognise the problem, and have a fix? Thanks, Sean Matthews -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sat Nov 4 22:00:17 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 4 Nov 2017 23:00:17 +0100 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: 2017-11-04 22:39 GMT+01:00 Sean Matthews : > I have just reinstalled everything. Newest release of emacs, > Haskell-pakage and Haskell-mode and Haskell. > I have tried to do this as cleanly as possible (via the customise and > package install interfaces). > Now when I try to edit haskell files, the system keeps freezing to report > types. [...] > I don't have a concrete solution for your problem, but instead of fighting with Emacs packages and customizations directly, I would *highly* recommend Spacemacs (http://spacemacs.org/).After using and customizing Emacs for several decades, I switched to Spacemacs some months ago and never looked back. Getting a coherent set of packages for a task, and getting those packages to actually work together requires a non-trivial amount of configuration fiddling. This is what Spacemacs does for you, plus an easy way to update. Having said that, Spacemacs' Haskell layer works perfectly for me, perhaps you can give it a try. Another hint: Use stack/stackage instead of fiddling around with GHC installations, Cabal, sandboxes etc. for yourself. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vl81 at kent.ac.uk Sat Nov 4 22:04:05 2017 From: vl81 at kent.ac.uk (Vilem-Benjamin Liepelt) Date: Sat, 4 Nov 2017 22:04:05 +0000 Subject: [Haskell-cafe] approxRatio and Ratio Word Message-ID: I have been experiencing curious behaviour with approxRatio: Prelude Data.Ratio> let a = 0 :: Word Prelude Data.Ratio> let b = 10 :: Word Prelude Data.Ratio> a%b 0 % 1 Prelude Data.Ratio> approxRational (a%b) 0.01 1 % 1 Prelude Data.Ratio> approxRational (0%1) 0.01 0 % 1 Is this expected? If so, why? From alex at kazik.de Sat Nov 4 23:06:22 2017 From: alex at kazik.de (ALeX Kazik) Date: Sun, 5 Nov 2017 00:06:22 +0100 Subject: [Haskell-cafe] approxRatio and Ratio Word In-Reply-To: References: Message-ID: > Is this expected? If so, why? Yes, that is expected. The approxRational calculation is based on x+eps and x-eps, which is 1%100 and 3689348814741910323%20 in your example, and the last one is due to the fact that there are no negative numbers in word and there is a silent underflow. (similar to: (0::Word)-1). And the simplest rational number between these two is 1. From mark.fine at gmail.com Sun Nov 5 00:04:02 2017 From: mark.fine at gmail.com (Mark Fine) Date: Sat, 4 Nov 2017 17:04:02 -0700 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: On Sat, Nov 4, 2017 at 3:00 PM, Sven Panne wrote: > 2017-11-04 22:39 GMT+01:00 Sean Matthews : > >> I have just reinstalled everything. Newest release of emacs, >> Haskell-pakage and Haskell-mode and Haskell. >> I have tried to do this as cleanly as possible (via the customise and >> package install interfaces). >> Now when I try to edit haskell files, the system keeps freezing to report >> types. [...] >> > > I don't have a concrete solution for your problem, but instead of fighting > with Emacs packages and customizations directly, I would *highly* recommend > Spacemacs (http://spacemacs.org/).After using and customizing Emacs for > several decades, I switched to Spacemacs some months ago and never looked > back. Getting a coherent set of packages for a task, and getting those > packages to actually work together requires a non-trivial amount of > configuration fiddling. This is what Spacemacs does for you, plus an easy > way to update. > +1 for Spacemacs! Have enjoyed using its default layers after years of managing crusty dotfiles. Beware of ghc 8.2 and haskell mode ( https://github.com/haskell/haskell-mode/issues/1553) Mark > Having said that, Spacemacs' Haskell layer works perfectly for me, perhaps > you can give it a try. Another hint: Use stack/stackage instead of fiddling > around with GHC installations, Cabal, sandboxes etc. for yourself. > > Cheers, > S. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 bbnjmeh at gmail.com Sun Nov 5 01:18:37 2017 From: bbnjmeh at gmail.com (Jose Echenique) Date: Sat, 4 Nov 2017 21:18:37 -0400 Subject: [Haskell-cafe] asking for feedback: "Magical Haskell" book in progress In-Reply-To: References: Message-ID: Surely my twin sons of 12 years of age understand the theory of this first chapter. Great, thanks. 2017-11-04 7:05 GMT-04:00 J Ho : > Dear Haskellers, > > I've systematized my notes from the last 3 years, bit the bullet and > started working on the visual Haskell teaching book that had been my desire > for a long time now :) The goal is to build it on the proper math > foundation of type and category theory to structure concepts and functional > patterns as they apply to real world problems neatly from the start, > without relying on imperative language experience too much, but make it > *visual*, easy to grasp, and not *math-technically* heavy. > > Basically, I was thinking *"how do I teach Haskell to my kids?"* and *"how > would people who learned only functional programming from school, without > any imperative exposure, think?"* (I don't think such people exist yet > but I sure would like to speak to those if / when they appear :) - but the > goal is to make it accessible to, hopefully, teens with some reasonable > math and / or programming background, and also, in the later chapters, make > it useful to adults who better grasp concepts visually (as I do) to have a > neat and systematized Haskell concepts building in their brain. > > Here's the direct link to the first chapter: Wizards, Types and Functions > > Here's the book's page on leanpub that > gets gradually updated as usual, and it will of course always stay free. > > Would very much appreciate your feedback, suggestions and thoughts! If you > have another 7 minutes to spare and want more context, here's a more > expanded rationale to this approach to teaching haskell - "Haskell Is Not > Programming > " - to > which I received some very valuable feedback (and some understandable > imperative camp critique :)) ) on reddit already, which helped me adjust > the book itself. > > Thanks a lot! > > Best regards, > > - J. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- ________________________ José Echenique email: bbnjmeh at gmail.com twitter: @*jechenbbn* -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Sun Nov 5 02:52:30 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Sun, 5 Nov 2017 08:22:30 +0530 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: Now when I try to edit haskell files, the system keeps freezing to report types. I don't think spacemacs is going to solve your problem. I'm using it, and it freezes/crashes at least 5 times a day for me. What exactly do you mean by "system keeps freezing to report types"? Does emacs become non-responsive or your entire system? For how long? After which keystroke - c-c c-t or c-c c-i? How big is your Haskell project? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.sorokin at gmail.com Sun Nov 5 06:43:47 2017 From: david.sorokin at gmail.com (David Sorokin) Date: Sun, 5 Nov 2017 09:43:47 +0300 Subject: [Haskell-cafe] [ANN] Book About Simulation Message-ID: <23AF5A07-ED70-41C2-B1AA-85CF4146DF23@gmail.com> Hi Cafe, I am delightful to inform that I wrote a book about simulation, Haskell and my Aivika libraries. http://aivikasoft.com/downloads/aivika/aivika.pdf It depends on point of view how to concern with this book. It can be a book about discrete event simulation per se. Also it can be considered as Aivika User’s Manual, or as a book about that how we can apply Haskell for simulation. I would be very grateful if someone could review my book, especially the English text as I’m a Russian native speaker. Best regards, David Sorokin From seanmatthews1 at gmail.com Sun Nov 5 09:07:21 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Sun, 5 Nov 2017 10:07:21 +0100 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: Good questions. Should have said more in my original email. 1. Exact behavior is that Emacs freezes for about a minute and displays (in bold) in the type of the word I'm over. Thus, I was trying to edit a small a-list with dummy 0.000s in the range. Every third keystroke, emacs stopped to tell me that my cursor was over 0.000::Double and I have to wait an indeterminate time (at least tens of seconds, sometimes a minute or more) to get control back. 2. This is in Windows (8) 3. No the rest of the system does not freeze, thus allowing me to bring up the process monitor and kill emacs. 4. I can't identify a combination of keys that does this. It seems to be entirely random when I am moving the cursor around. 5. Turning off doc mode (etc.), which I first guessed might be the problem, does not help. On Sun, Nov 5, 2017 at 3:52 AM, Saurabh Nanda wrote: > > Now when I try to edit haskell files, the system keeps freezing to report > types. > > > > I don't think spacemacs is going to solve your problem. I'm using it, and > it freezes/crashes at least 5 times a day for me. > > > What exactly do you mean by "system keeps freezing to report types"? Does > emacs become non-responsive or your entire system? For how long? After > which keystroke - c-c c-t or c-c c-i? How big is your Haskell project? > > -- Saurabh. > -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Sun Nov 5 09:46:26 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Sun, 5 Nov 2017 15:16:26 +0530 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: > > > 1. Exact behavior is that Emacs freezes for about a minute and displays > (in bold) in the type of the word I'm over. > Thus, I was trying to edit a small a-list with dummy 0.000s in the > range. Every third keystroke, emacs stopped to tell me that > my cursor was over 0.000::Double and I have to wait an indeterminate > time (at least tens of seconds, sometimes a minute or more) > to get control back. > So, the underlying mechanism to determine type at current cursor position isn't very fast. In spacemacs+intero C-c C-t (or C-c C-i) takes anywhere between 1 to 10 sec for me. Something in your setup has made this lookup automatic. It's trying to determine the type as your browse around your source code. Do you have any idea what could have caused that? You could try one more thing. Try delivering a SIGUSR2 to the Emacs process when it's stuck. It will stop doing whatever is holding it up and drop you into some sort of a debugger. That can give you some clues about what is causing this behaviour in your setup. -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Nov 5 12:56:53 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 5 Nov 2017 13:56:53 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> Message-ID: This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode due to some ad hoc changes like https://phabricator.haskell.org/D3651. Related GitHub issues: https://github.com/haskell/haskell-mode/issues/1553 https://github.com/haskell/haskell-mode/issues/1496 It should be noted that the output of GHC(i) is actually part of GHC's interface, so in this light, there have been some breaking changes, probably unintended, but nevertheless. So my question is: Is there a chance to revert some of these ad hoc changes and/or add some flags to get the old behavior back? I guess that Emacs + haskell-mode is one of the most important IDEs, so it would be a pity to worsen the situation there. I'm quite aware that it is very late in the release cycle, but it would be extremely nice if there was something which can be done. In the future it might make sense to co-operate with the haskell-mode team a bit more, perhaps adding some tests regarding the required output format etc. to GHC's test suite. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpaugh at gmx.com Sun Nov 5 14:37:48 2017 From: jpaugh at gmx.com (jpaugh at gmx.com) Date: Sun, 05 Nov 2017 08:37:48 -0600 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> Message-ID: <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> A better approach might be to develop a "machine-readable" output format which then is kept stable, and can be enabled with a flag. Git has a similar solution. It would be a shame to avoid changes which make the user experience better simply because other projects cannot sync their development cycle, especially if those projects are not universally used or required. Thanks, Jonathan On November 5, 2017 6:56:53 AM CST, Sven Panne wrote: >This is not an issue about 8.2.2 per se, but 8.2 changes in general: >Recent >discussions on Haskell Cafe showed serious problems with Emacs' >haskell-mode due to some ad hoc changes like >https://phabricator.haskell.org/D3651. Related GitHub issues: > > https://github.com/haskell/haskell-mode/issues/1553 > https://github.com/haskell/haskell-mode/issues/1496 > >It should be noted that the output of GHC(i) is actually part of GHC's >interface, so in this light, there have been some breaking changes, >probably unintended, but nevertheless. So my question is: Is there a >chance >to revert some of these ad hoc changes and/or add some flags to get the >old >behavior back? I guess that Emacs + haskell-mode is one of the most >important IDEs, so it would be a pity to worsen the situation there. > >I'm quite aware that it is very late in the release cycle, but it would >be >extremely nice if there was something which can be done. In the future >it >might make sense to co-operate with the haskell-mode team a bit more, >perhaps adding some tests regarding the required output format etc. to >GHC's test suite. > >Cheers, > S. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Nov 5 18:29:38 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 5 Nov 2017 13:29:38 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> Message-ID: <75AF50B6-3038-4E5A-9801-4FDA16330073@dukhovni.org> > On Nov 5, 2017, at 9:37 AM, jpaugh at gmx.com wrote: > > A better approach might be to develop a "machine-readable" output format which then is kept stable, and can be enabled with a flag. Git has a similar solution. > > It would be a shame to avoid changes which make the user experience better simply because other projects cannot sync their development cycle, especially if those projects are not universally used or required. Amen to that. I find the diagnostic output of 8.2 substantially improved (more useful in locating the reported bugs) over previous versions. So reverting to previous behaviour would not be a good idea. It should not take too long for the relevant emacs modules to be updated. And they should be made more forgiving of small changes in the output format (use less precise regular expressions). -- Viktor. From seanmatthews1 at gmail.com Sun Nov 5 19:24:03 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Sun, 5 Nov 2017 20:24:03 +0100 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: Problem fixed. Not an interesting problem, either. Turns out that I had not quite completely cleaned out my emacs before reinstallation. Many thanks, Sean On Sun, Nov 5, 2017 at 10:46 AM, Saurabh Nanda wrote: > >> 1. Exact behavior is that Emacs freezes for about a minute and displays >> (in bold) in the type of the word I'm over. >> Thus, I was trying to edit a small a-list with dummy 0.000s in the >> range. Every third keystroke, emacs stopped to tell me that >> my cursor was over 0.000::Double and I have to wait an indeterminate >> time (at least tens of seconds, sometimes a minute or more) >> to get control back. >> > > > So, the underlying mechanism to determine type at current cursor position > isn't very fast. In spacemacs+intero C-c C-t (or C-c C-i) takes anywhere > between 1 to 10 sec for me. Something in your setup has made this lookup > automatic. It's trying to determine the type as your browse around your > source code. Do you have any idea what could have caused that? > > You could try one more thing. Try delivering a SIGUSR2 to the Emacs > process when it's stuck. It will stop doing whatever is holding it up and > drop you into some sort of a debugger. That can give you some clues about > what is causing this behaviour in your setup. > > -- Saurabh. > -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Nov 5 20:52:11 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 5 Nov 2017 21:52:11 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> Message-ID: 2017-11-05 15:37 GMT+01:00 : > A better approach might be to develop a "machine-readable" output format > which then is kept stable, and can be enabled with a flag. Git has a > similar solution. > Without doubt, this is definitely the better approach, but this is hardly what can be achieved for 8.2.2. Adding some flag to get the old behavior back when wanted *is* achievable. > It would be a shame to avoid changes which make the user experience better > simply because other projects cannot sync their development cycle, > Don't get me wrong: I'm all for improving user experience, but making ad hoc changes without enough thought or even a chance to get the old behavior back is probably not the right way to proceed. All SW lives in some kind of ecosystem, so it should behave well in that. And for Emacs users, the user experience has been made much worse. > especially if those projects are not universally used or required. > This is highly a matter of personal taste: No project is "universally used", so this is tautological statement. The question is: Is a minor cosmetic change really worth breaking things in one of the major IDEs? Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Nov 5 20:56:14 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 5 Nov 2017 21:56:14 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: <75AF50B6-3038-4E5A-9801-4FDA16330073@dukhovni.org> References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> <75AF50B6-3038-4E5A-9801-4FDA16330073@dukhovni.org> Message-ID: 2017-11-05 19:29 GMT+01:00 Viktor Dukhovni : > Amen to that. I find the diagnostic output of 8.2 substantially improved > (more useful in locating the reported bugs) over previous versions. So > reverting to previous behaviour would not be a good idea. > I didn't propose that, just a way to *optionally* get the old behavior back until we blissfully live in a world with a stable machine-readable interface. > It should not take too long for the relevant emacs modules to be updated. > And they should be made more forgiving of small changes in the output > format (use less precise regular expressions). > If I understand the tickets correctly, there is a loss of information, so this might not be possible. OTOH, I don't fully understand how haskell-mode works under the hood... Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Sun Nov 5 21:12:39 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 5 Nov 2017 13:12:39 -0800 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> Message-ID: On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne wrote: > This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent > discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode > due to some ad hoc changes like https://phabricator.haskell.org/D3651. I've long used ghci -v0 to achieve the same effect. When you have a couple hundred modules the "loaded X Y Z" is worse than useless. But it's better to just add -v0, and maybe add more flags for finer control, than change the default and break tools. From ok at cs.otago.ac.nz Sun Nov 5 23:05:23 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 6 Nov 2017 12:05:23 +1300 Subject: [Haskell-cafe] [ANN] Book About Simulation In-Reply-To: <23AF5A07-ED70-41C2-B1AA-85CF4146DF23@gmail.com> References: <23AF5A07-ED70-41C2-B1AA-85CF4146DF23@gmail.com> Message-ID: On 5/11/17 7:43 PM, David Sorokin wrote: > Hi Cafe, > > I am delightful to inform that I wrote a book about simulation, Haskell and my Aivika libraries. > > http://aivikasoft.com/downloads/aivika/aivika.pdf This sounded interesting, but when I clicked on the link, I got a solid green page with these words in black: The domain aivikasoft.com is no longer parked by GoDaddy. At https://github.com/dsorokin/aivika/wiki the "Aivika Tutorial for Beginners" link points to aivikasoft.com, which again gets a GoDaddy page. The link to the Aivika manual PDF works, but I take it that the book you are telling us about is something else. From ok at cs.otago.ac.nz Sun Nov 5 23:20:43 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 6 Nov 2017 12:20:43 +1300 Subject: [Haskell-cafe] Replace list item with list. In-Reply-To: References: Message-ID: <132426d5-2bb8-99ea-a3f5-88de963f4477@cs.otago.ac.nz> On 4/11/17 11:48 PM, mirone wrote: > Hello everyone! > If I have a list A : ["x", "y", "z"] > and a list B: ["f", "g"]. > Here is my question: > What's the simplest way to replace "z" in the list A by list B, and get > ["x", "y", "f", "g"] ? f _ _ = ["x","y","f","g"] That's a joke, but it really isn't clear what the question means. One possibility is f a b = init a ++ b f [1,2,3,4,5] [9,8,7] => [1,2,3,4,9,8,7] If you mean that you want to replace "z" by ... wherever it occurs, something like -- (f needle straws haystack) replaces each occurrence of needle as -- an element of haystack with the elements of straws. f :: Eq t => t -> [t] -> ([t] -> [t]) f needle straws = concatMap (\straw -> if straw == needle then straws else [straw]) f "z" ["f","g"] ["x","z","y","z"] => ["x","f","g","y","f","g"] Your question admits of too many generalisations for us to be really helpful. From ok at cs.otago.ac.nz Sun Nov 5 23:36:12 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 6 Nov 2017 12:36:12 +1300 Subject: [Haskell-cafe] Replace list item with list. In-Reply-To: <132426d5-2bb8-99ea-a3f5-88de963f4477@cs.otago.ac.nz> References: <132426d5-2bb8-99ea-a3f5-88de963f4477@cs.otago.ac.nz> Message-ID: On 6/11/17 12:20 PM, Richard A. O'Keefe wrote: > On 4/11/17 11:48 PM, mirone wrote: >> Hello everyone! >> If I have a list A : ["x", "y", "z"] >> and a list B: ["f", "g"]. >> Here is my question: >> What's the simplest way to replace "z" in the list A by list B, and get >> ["x", "y", "f", "g"] ? > Your question admits of too many generalisations for us to be really > helpful. Here are some questions that might help. Let's suppose for the sake of argument that you want a function f needle straws {-B-} haystack {-A-} such that f "z" ["f","g"] ["x","y","z"] => ["x","y","f","g"] What should f n s h do when n does not occur in h? What should f n s h do when n is the first element of h? What should f n s h do when n occurs more than once in h? What should f n s h do when n occurs in s? What should f n s h do when h has 0, 1, 2, 4 or more elements? May f assume that h is in sorted order? May f use compare at all? May f use ==? What if we want to match more than one element; should we be looking for an *element* equal to "z" or a *prefix* equal to ["z"] in this case but possibly longer in others? With different answers to these questions, you might get f' :: Eq t => [t] -> [t] -> [t] -> [t] f' needles straws haystack | needles `isPrefixOf` haystack = straws ++ (length needles `drop` haystack) f' needles straws [] = [] f' needles straws (item:items) = item : f' needles straws items f' ["z"] ["f","g"] ["x","y","z","z"] => ["x","y","f","g","z"] From david.sorokin at gmail.com Mon Nov 6 06:22:39 2017 From: david.sorokin at gmail.com (David Sorokin) Date: Mon, 6 Nov 2017 09:22:39 +0300 Subject: [Haskell-cafe] [ANN] Book About Simulation In-Reply-To: References: <23AF5A07-ED70-41C2-B1AA-85CF4146DF23@gmail.com> Message-ID: <81F7A341-815F-4CCA-9112-78A8F3A0D81D@gmail.com> Richard, Thanks for pointing to the issue. The link should refer to https://github.com/dsorokin/dsorokin.github.io/blob/master/downloads/aivika/aivika.pdf It contains the material in three parts about sequential simulation, parallel and distributed simulation as well as nested simulation. Only the text is described from the point of that how it is implemented in Aivika, i.e. the text is not neutral. My text is biased by definition. The link on Wiki is indeed very old. It points to a small prototype of the new book. The new book has graphical illustrations such as charts, histograms and small diagrams. Best regards, David Sorokin > 6 нояб. 2017 г., в 2:05, Richard A. O'Keefe написал(а): > > > > On 5/11/17 7:43 PM, David Sorokin wrote: >> Hi Cafe, >> >> I am delightful to inform that I wrote a book about simulation, Haskell and my Aivika libraries. >> >> http://aivikasoft.com/downloads/aivika/aivika.pdf > > This sounded interesting, but when I clicked on the link, > I got a solid green page with these words in black: > The domain aivikasoft.com is no longer parked by GoDaddy. > > At https://github.com/dsorokin/aivika/wiki > the "Aivika Tutorial for Beginners" link points to > aivikasoft.com, which again gets a GoDaddy page. > > The link to the Aivika manual PDF works, but I take it > that the book you are telling us about is something else. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 francesco.mazzoli at digitalasset.com Mon Nov 6 10:08:39 2017 From: francesco.mazzoli at digitalasset.com (Francesco Mazzoli) Date: Mon, 6 Nov 2017 11:08:39 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> Message-ID: As the author of that diff, I agree that making it optional is the right thing to do here -- and in fact I think my first version had that behavior under a flag. It shouldn't be hard to introduce such a flag, but I don't know if I have time to do it before 8.2.2 is released... I'd be happy to help other volunteers, you can ping me on #ghc, I'm bitonic. Francesco On Sun, Nov 5, 2017 at 10:12 PM, Evan Laforge wrote: > On Sun, Nov 5, 2017 at 4:56 AM, Sven Panne wrote: >> This is not an issue about 8.2.2 per se, but 8.2 changes in general: Recent >> discussions on Haskell Cafe showed serious problems with Emacs' haskell-mode >> due to some ad hoc changes like https://phabricator.haskell.org/D3651. > > I've long used ghci -v0 to achieve the same effect. When you have a > couple hundred modules the "loaded X Y Z" is worse than useless. But > it's better to just add -v0, and maybe add more flags for finer > control, than change the default and break tools. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Francesco Mazzoli Senior Software Engineer -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message. From markus.l2ll at gmail.com Mon Nov 6 10:24:36 2017 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Mon, 6 Nov 2017 11:24:36 +0100 Subject: [Haskell-cafe] Replace list item with list. In-Reply-To: <132426d5-2bb8-99ea-a3f5-88de963f4477@cs.otago.ac.nz> References: <132426d5-2bb8-99ea-a3f5-88de963f4477@cs.otago.ac.nz> Message-ID: Yeah, the question is so open that it's hard to answer. Was thinking recommending to inline the desired list all together, but thought it too impolite :). But the `concatMap` is the simplest one (to replace all "z"s that is), and if the OP is interested, then for lists >>= is defined as concatMap, so: a = ["x", "y", "z"] b = ["f", "g"] f :: String -> [String] f str = case str of "z" -> b _ -> [str] answer = a >>= f (Didn't run this through the compiler) On Mon, Nov 6, 2017 at 12:20 AM, Richard A. O'Keefe wrote: > > > On 4/11/17 11:48 PM, mirone wrote: > >> Hello everyone! >> If I have a list A : ["x", "y", "z"] >> and a list B: ["f", "g"]. >> Here is my question: >> What's the simplest way to replace "z" in the list A by list B, and get >> ["x", "y", "f", "g"] ? >> > > f _ _ = ["x","y","f","g"] > > That's a joke, but it really isn't clear what the question means. > One possibility is > > f a b = init a ++ b > > f [1,2,3,4,5] [9,8,7] => [1,2,3,4,9,8,7] > > If you mean that you want to replace "z" by ... wherever it occurs, > something like > -- (f needle straws haystack) replaces each occurrence of needle as > -- an element of haystack with the elements of straws. > f :: Eq t => t -> [t] -> ([t] -> [t]) > f needle straws = > concatMap (\straw -> if straw == needle then straws else [straw]) > > f "z" ["f","g"] ["x","z","y","z"] => ["x","f","g","y","f","g"] > > Your question admits of too many generalisations for us to be really > helpful. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 6 16:54:37 2017 From: ben at well-typed.com (Ben Gamari) Date: Mon, 06 Nov 2017 11:54:37 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> Message-ID: <87y3njl54i.fsf@ben-laptop.smart-cactus.org> Next time something like this arises please do open a ticket. Sven Panne writes: > 2017-11-05 15:37 GMT+01:00 : > >> A better approach might be to develop a "machine-readable" output format >> which then is kept stable, and can be enabled with a flag. Git has a >> similar solution. >> > > Without doubt, this is definitely the better approach, but this is hardly > what can be achieved for 8.2.2. Adding some flag to get the old behavior > back when wanted *is* achievable. > Yes, I have opened a differential adding such a flag. See D4164 [1]. Please bikeshed to taste. In general I would really prefer that we *not* consider GHCi's REPL to be a stable programmatic interface. If haskell-mode needs access to some bit of information from GHC, then please let's discuss how to provide it in a more robust manner. This shouldn't be hard; we just need to have feedback on what the interfaces required should look like. [1] https://phabricator.haskell.org/D4164 > >> It would be a shame to avoid changes which make the user experience better >> simply because other projects cannot sync their development cycle, >> > > Don't get me wrong: I'm all for improving user experience, but making ad > hoc changes without enough thought or even a chance to get the old behavior > back is probably not the right way to proceed. All SW lives in some kind of > ecosystem, so it should behave well in that. And for Emacs users, the user > experience has been made much worse. > The trouble is that GHC has an extremely large surface area, any bit of which might have mechanical consumers. Those who reviewed the patch indeed considered making this change behind a flag (as Francesco's original patch did) but we concluded that this would be pointless as it didn't seem likely that anyone relied on this behavior. It seems that in this case we were wrong That being said, we cannot always preemptively add complexity to the project out of fear that a given change might break a hypothetical mechanical consumer. GHCi is first-and-foremost a REPL for users. When evaluating a change, if we feel it is likely that we will break a mechanical user then we will likely guard the change with a flag. However, if not, we won't. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From svenpanne at gmail.com Mon Nov 6 17:46:24 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 6 Nov 2017 18:46:24 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: <87y3njl54i.fsf@ben-laptop.smart-cactus.org> References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> <87y3njl54i.fsf@ben-laptop.smart-cactus.org> Message-ID: 2017-11-06 17:54 GMT+01:00 Ben Gamari : > Next time something like this arises please do open a ticket. > Yep, will do... > Yes, I have opened a differential adding such a flag. See D4164 [1]. > Please bikeshed to taste. > Thanks for the quick fix! > In general I would really prefer that we *not* consider GHCi's REPL to be > a stable programmatic interface. I fully understand that, and that's definitely the way to go. Nevertheless, parsing tool/compiler output is still one of the most used hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). Not every project is as open to suggestions and changes as GHC is, so this is often the only way out. > That being said, we cannot always preemptively add complexity to the > project out of fear that a given change might break a hypothetical > mechanical consumer. That's of course not what was proposed. :-) > GHCi is first-and-foremost a REPL for users. > When evaluating a change, if we feel it is likely that we will break a > mechanical user then we will likely guard the change with a flag. > However, if not, we won't. > I think the main problem here was communication. I can't speak for the haskell-mode maintainers, but for my part I didn't notice the problems because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This is definitely part of the whole problem.). I tried the 8.2 series only sparingly and only via the command line, so this is perhaps what others did, too, so the interaction bug went unnoticed for such a long time. Cheers, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Nov 6 19:04:49 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 6 Nov 2017 21:04:49 +0200 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2 In-Reply-To: References: <877evbuqtf.fsf@ben-laptop.smart-cactus.org> <83961DD2-1115-44A0-9E34-B553526B2CE2@gmx.com> <87y3njl54i.fsf@ben-laptop.smart-cactus.org> Message-ID: To me this is just further evidence that we need a first class API for tool makers. Which is a (slow) work in progress. Alan On 6 November 2017 at 19:46, Sven Panne wrote: > 2017-11-06 17:54 GMT+01:00 Ben Gamari : > >> Next time something like this arises please do open a ticket. >> > > Yep, will do... > > >> Yes, I have opened a differential adding such a flag. See D4164 [1]. >> Please bikeshed to taste. >> > > Thanks for the quick fix! > > >> In general I would really prefer that we *not* consider GHCi's REPL to be >> a stable programmatic interface. > > > I fully understand that, and that's definitely the way to go. > Nevertheless, parsing tool/compiler output is still one of the most used > hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs). > Not every project is as open to suggestions and changes as GHC is, so this > is often the only way out. > > >> That being said, we cannot always preemptively add complexity to the >> project out of fear that a given change might break a hypothetical >> mechanical consumer. > > > That's of course not what was proposed. :-) > > >> GHCi is first-and-foremost a REPL for users. >> When evaluating a change, if we feel it is likely that we will break a >> mechanical user then we will likely guard the change with a flag. >> However, if not, we won't. >> > > I think the main problem here was communication. I can't speak for the > haskell-mode maintainers, but for my part I didn't notice the problems > because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This > is definitely part of the whole problem.). I tried the 8.2 series only > sparingly and only via the command line, so this is perhaps what others > did, too, so the interaction bug went unnoticed for such a long time. > > Cheers, > Sven > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 taylor at fausak.me Tue Nov 7 14:42:32 2017 From: taylor at fausak.me (Taylor Fausak) Date: Tue, 07 Nov 2017 08:42:32 -0600 Subject: [Haskell-cafe] First annual Haskell users survey Message-ID: <1510065752.961652.1164484216.674F01C6@webmail.messagingengine.com> Today is the last day to fill out the survey! To the over 1,200 of you have already filled it out: thank you! For those of you that haven't, please take 10 minutes today to fill it out. Thanks! https://haskellweekly.news/surveys/2017.html From saurabhnanda at gmail.com Wed Nov 8 09:06:07 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Wed, 8 Nov 2017 14:36:07 +0530 Subject: [Haskell-cafe] ANN: nice-html, an all-around "nice" html templating library, similar but different to lucid, blaze, type-of-html, etc. In-Reply-To: References: Message-ID: > > >Do you mind explaining the invalid monad instance of Lucid and how it > would impact a library user? > To my knowledge lucid uses a monad instance that follow the monad laws > (what I meant by "valid") fine. > Sorry for causing the confusion. I misread that statement in your README. > >Also, I'm assuming one shouldn't call the `compile` function each time a > page needs to be rendered, right? Should one put the results of the > `compile` function in a top-level Map and use those to get the speed gains? > The idea is to only compile a template once, ever. If you need to compile > a template every time a page is rendered (though I can't actually think of > a case where you would), you should probably just skip the middle-man, and > use lucid (or blaze). It's not horribly slow, but you'd miss out on the > benefits of nice-html by doing this. > So, I guess my question was, how does one compile a template exactly once with `nice-html` ? If some content inside the template is conditional based on input values, will it work properly, as expected? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Wed Nov 8 09:29:57 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 08 Nov 2017 22:29:57 +1300 Subject: [Haskell-cafe] Proposal: Instance apartness guards Message-ID: <5a02ce95.397.384.19041@clear.net.nz> Surprisinlgy little comment on this proposal. Perhaps it landed when yous were busy elsewhere. I'd like to push it to the committee soon; this is an invitation for more feedback. Richard E wrote a nice brief summary https://github.com/ghc-proposals/ghc-proposals/pull/56#issuecomment-311421457 Thank you AntC ----- Original Message Follows ----- > After years of pondering this idea (in various forms), > and several rounds of discussion on several forums, > I've written it up. > > "This proposal tackles the thorny topic of Overlapping > instances, > for both type classes and Type Families/Associated types, > by annotating instance heads with type-level apartness > Guards. > Type-level disequality predicates appear in Sulzmann & > Stuckey 2002; > in the type-level ‘case selection’ in HList 2004; > and in various guises in Haskell cafe discussions in > following years. > This proposal builds on the apartness testing implemented > as part of the Closed Type Families work." > > All feedback welcome. > > https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/0000-instance-apartness-guards.rst > > AntC From nathan at myrtlesoftware.com Wed Nov 8 10:04:43 2017 From: nathan at myrtlesoftware.com (Nathan van Doorn) Date: Wed, 8 Nov 2017 10:04:43 +0000 Subject: [Haskell-cafe] Functional programming job opportunity Message-ID: Myrtle is looking for skilled developers to join our growing development team and assist with the development of our core compiler technology. Ideally candidates would have an interest in either efficient hardware design and/ or machine learning models and frameworks. We use the functional language, Haskell, for every aspect of our work and developers will get the chance to be involved in every part of the project. Familiarity and interest with hardware design would be viewed positively but is not essential. Applicants should be familiar with Unix based systems as all our development is done on Ubuntu or NixOS. More information at https://www.myrtlesoftware.com/vacancies/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at centromere.net Wed Nov 8 13:21:24 2017 From: alex at centromere.net (Alex) Date: Wed, 8 Nov 2017 08:21:24 -0500 Subject: [Haskell-cafe] Project idea, seeking feedback Message-ID: <20171108082124.71b447b4@centromere.net> Hi all, I'm seeking feedback for a project I'd like to start. I have a bit of experience developing large scale systems containing many microservices, databases, message queues, and caches over many VMs. Time and time again I find myself confronted with the same problems: 1. It is difficult to trace events through the system: Consider an HTTP request made by a customer to a public API. Which microservices were impacted by that request? What SQL queries were run as a result of that request? What 3rd party APIs were consulted during the request's fulfillment? Answers to these questions are essential to fixing bugs quickly, and yet they are so difficult to answer (at least in my experience). 2. Problems are difficult to reproduce: When Customer Success walks in and says, "I have an angry customer on the phone. They want to know why [FOO] wasn't properly [BAR]" it is often impossible to give an answer without interactive troubleshooting and hours of grepping through unstructured log files. Troubleshooting may incur additional expenses too, since (for instance) you may hit your API request limit for a 3rd party service. 3. Business and non-business logic are not well encapsulated: Often I see code related to (for example) RabbitMQ interwoven with core business logic when calls need to be made to other microservices. The fact that RabbitMQ facilitates communication between microservices is an implementation detail that I shouldn't have to think about. 4. Resource consumption is non-uniform: Some microservices are more demanding than others in terms of CPU, memory, and disk usage. Achieving optimal "packing" is difficult. In other words, some VMs will have a high load and others will remain idle. Auto scaling groups can help with this in theory, but I don't think they can achieve the kind of density I would like to see. Moreover, what constitutes a "resource"? If a 3rd party service rate limits requests by IP address, couldn't each request be considered a resource unit which needs to be properly load balanced, just as you would with CPU? Given these motivations, I would like to flesh out some ideas for a framework/platform which addresses these issues. These ideas are half-baked and may not tie in well with one another. I envision a distributed system as follows: 1. One kind of VM: DevOps people have a saying: "Treat your VMs like cattle, not pets". In practice, "cattle" becomes "cows, chickens, pigs, and lobster". VMs typically have an assigned role, and they become part of a group which may or may not be auto-scaling. For a given instantiation of this hypothetical platform, I would like to see a single kind of VM. That is, every VM is identical to every other VM, and they all run the same Haskell application. 2. Strict separation of business and non-business logic: The framework should handle all aspects of communication between nodes (like Cloud Haskell does) in a pluggable and transparent way, but that's not all. The framework should have first class support for other integrations (such as PagerDuty alerting, performance monitoring, etc) which are described below. 3. Pool coordination via DSL: The entire pool of VMs is orchestrated/coordinated by one ore more "scripts" written in a DSL, which is implemented as a Free Monad. Every single "operation" or "primitive" in your AST data type is Serializable, and when the framework interprets the DSL, it serializes the instruction and sends it over the network to a node for execution. The particular node on which the instruction gets executed is chosen by the platform, not the developer. 4. Smart resource consumption: Each node brings with it a set of resources. It is *not* my intention to create a system which views CPU, memory, etc as a contiguous unit. Rather, each primitive instruction in the AST is viewed as a "black box" which can only consume as much CPU and memory as the node has available to it. The framework is responsible for profiling each instruction and scheduling future instructions to a node for which resources are predicted to be available. The developer should be able to define new resources such as 3rd party API calls, bandwidth, database connections, etc, all of which are profiled just as CPU and memory would. 5. Browser based control panel: Engineers should have a GUI at their disposal which allows them to watch -- in real time -- the execution flow of the DSL script. 6. Structured logs with advanced filtering: All log output should be structured with first class support for shipping the data to Logstash/ElasticSearch. The aforementioned GUI should be able to selectively filter output based on certain pre-defined predicates and display them to the developer. For example, if you're building an email virus scanning system (which may see millions of emails per day), you may want to limit the real-time debugging output to only a specific customer. 7. First class integration with modern tools and services: The system should integrate with Consul, PagerDuty, statsd, RabbitMQ, memcache, DataDog, Logstash, and Slack, with new integrations being easy to add. This is vital for clean separation of business and non-business logic. For example, the developer should be able to cache certain bits of data at will, without having to worry about opening and managing a TCP connection to memcache. This is my vision, and I want to build it completely in Haskell. What do you all think? -- Alex From markus.l2ll at gmail.com Wed Nov 8 21:10:53 2017 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Wed, 8 Nov 2017 22:10:53 +0100 Subject: [Haskell-cafe] Project idea, seeking feedback In-Reply-To: <20171108082124.71b447b4@centromere.net> References: <20171108082124.71b447b4@centromere.net> Message-ID: Hi Alex, this is obviously highly ambitious if you want to get this right. If you actually plan to start on this, then since there are plenty of DSL's that eventually run on one machine, then where I would start is the distributed part. I.e make something that passes around an Int, and have it deploy to any number of machines. Then add gradually add complexity, like distributed queues and workers, ways to enforce ordering on when results of works are to be submitted/accepted. Implementing precedence graphs would be interesting. Then there is limiting congestion and probably many more kinds of limits you want to add to different points in the graph. Just some random ideas. But start and deploy something very simple at first. On Wed, Nov 8, 2017 at 2:21 PM, Alex wrote: > Hi all, > > I'm seeking feedback for a project I'd like to start. I have a bit of > experience developing large scale systems containing many > microservices, databases, message queues, and caches over many VMs. Time > and time again I find myself confronted with the same problems: > > 1. It is difficult to trace events through the system: Consider an HTTP > request made by a customer to a public API. Which microservices were > impacted by that request? What SQL queries were run as a result of that > request? What 3rd party APIs were consulted during the request's > fulfillment? Answers to these questions are essential to fixing bugs > quickly, and yet they are so difficult to answer (at least in my > experience). > > 2. Problems are difficult to reproduce: When Customer Success walks in > and says, "I have an angry customer on the phone. They want to know why > [FOO] wasn't properly [BAR]" it is often impossible to give an answer > without interactive troubleshooting and hours of grepping through > unstructured log files. Troubleshooting may incur additional expenses > too, since (for instance) you may hit your API request limit for a 3rd > party service. > > 3. Business and non-business logic are not well encapsulated: Often I > see code related to (for example) RabbitMQ interwoven with core business > logic when calls need to be made to other microservices. The fact that > RabbitMQ facilitates communication between microservices is an > implementation detail that I shouldn't have to think about. > > 4. Resource consumption is non-uniform: Some microservices are more > demanding than others in terms of CPU, memory, and disk usage. > Achieving optimal "packing" is difficult. In other words, some VMs > will have a high load and others will remain idle. Auto scaling groups > can help with this in theory, but I don't think they can achieve the > kind of density I would like to see. > Moreover, what constitutes a "resource"? If a 3rd party service > rate limits requests by IP address, couldn't each request be considered > a resource unit which needs to be properly load balanced, just as you > would with CPU? > > Given these motivations, I would like to flesh out some ideas for a > framework/platform which addresses these issues. These ideas are > half-baked and may not tie in well with one another. > > I envision a distributed system as follows: > > 1. One kind of VM: > DevOps people have a saying: "Treat your VMs like cattle, not > pets". In practice, "cattle" becomes "cows, chickens, pigs, and > lobster". VMs typically have an assigned role, and they become part of > a group which may or may not be auto-scaling. For a given instantiation > of this hypothetical platform, I would like to see a single kind of VM. > That is, every VM is identical to every other VM, and they all run the > same Haskell application. > > 2. Strict separation of business and non-business logic: The framework > should handle all aspects of communication between nodes (like Cloud > Haskell does) in a pluggable and transparent way, but that's not all. > The framework should have first class support for other integrations > (such as PagerDuty alerting, performance monitoring, etc) which are > described below. > > 3. Pool coordination via DSL: The entire pool of VMs is > orchestrated/coordinated by one ore more "scripts" written in a DSL, > which is implemented as a Free Monad. Every single "operation" or > "primitive" in your AST data type is Serializable, and when the > framework interprets the DSL, it serializes the instruction and sends > it over the network to a node for execution. The particular node on > which the instruction gets executed is chosen by the platform, not the > developer. > > 4. Smart resource consumption: Each node brings with it a set of > resources. It is *not* my intention to create a system which views CPU, > memory, etc as a contiguous unit. Rather, each primitive instruction in > the AST is viewed as a "black box" which can only consume as much CPU > and memory as the node has available to it. The framework is > responsible for profiling each instruction and scheduling future > instructions to a node for which resources are predicted to be > available. > The developer should be able to define new resources such as 3rd > party API calls, bandwidth, database connections, etc, all of which are > profiled just as CPU and memory would. > > 5. Browser based control panel: Engineers should have a GUI at their > disposal which allows them to watch -- in real time -- the execution > flow of the DSL script. > > 6. Structured logs with advanced filtering: All log output should be > structured with first class support for shipping the data to > Logstash/ElasticSearch. The aforementioned GUI should be able to > selectively filter output based on certain pre-defined predicates and > display them to the developer. For example, if you're building an email > virus scanning system (which may see millions of emails per day), you > may want to limit the real-time debugging output to only a specific > customer. > > 7. First class integration with modern tools and services: The system > should integrate with Consul, PagerDuty, statsd, RabbitMQ, memcache, > DataDog, Logstash, and Slack, with new integrations being easy to add. > This is vital for clean separation of business and non-business logic. > For example, the developer should be able to cache certain bits of data > at will, without having to worry about opening and managing a TCP > connection to memcache. > > This is my vision, and I want to build it completely in Haskell. What > do you all think? > > -- > Alex > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Markus Läll -------------- next part -------------- An HTML attachment was scrubbed... URL: From olshanskydr at gmail.com Thu Nov 9 09:08:22 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Thu, 9 Nov 2017 12:08:22 +0300 Subject: [Haskell-cafe] Proposal: Instance apartness guards In-Reply-To: <5a02ce95.397.384.19041@clear.net.nz> References: <5a02ce95.397.384.19041@clear.net.nz> Message-ID: Dear Anthony C & Richard E! >From my side (as GHC-user) it definitely looks like the much more natural way than OverlappedInstances (say, +1). Unfortunately I am not an expert and can only ask with you for feedback from experts. Dmitry 2017-11-08 12:29 GMT+03:00 Anthony Clayden : > Surprisinlgy little comment on this proposal. > Perhaps it landed when yous were busy elsewhere. > I'd like to push it to the committee soon; > this is an invitation for more feedback. > > Richard E wrote a nice brief summary > https://github.com/ghc-proposals/ghc-proposals/pull/ > 56#issuecomment-311421457 > > Thank you > AntC > > > ----- Original Message Follows ----- > > After years of pondering this idea (in various forms), > > and several rounds of discussion on several forums, > > I've written it up. > > > > "This proposal tackles the thorny topic of Overlapping > > instances, > > for both type classes and Type Families/Associated types, > > by annotating instance heads with type-level apartness > > Guards. > > Type-level disequality predicates appear in Sulzmann & > > Stuckey 2002; > > in the type-level ‘case selection’ in HList 2004; > > and in various guises in Haskell cafe discussions in > > following years. > > This proposal builds on the apartness testing implemented > > as part of the Closed Type Families work." > > > > All feedback welcome. > > > > > https://github.com/AntC2/ghc-proposals/blob/instance- > apartness-guards/proposals/0000-instance-apartness-guards.rst > > > > AntC > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 chriswarbo at googlemail.com Fri Nov 10 00:12:02 2017 From: chriswarbo at googlemail.com (Chris Warburton) Date: Fri, 10 Nov 2017 00:12:02 +0000 Subject: [Haskell-cafe] [ANN] Haskell Theory Exploration scripts Message-ID: <877euzhu0d.fsf@gmail.com> Hello all, I thought I'd make a public announcement about some scripts I've built up over the last few years for "exploring" Haskell code. They can be found at: http://chriswarbo.net/git/haskell-te With mirrors at /ipns/QmWv958VzBJQchGjYKiSaxLC9ugrjvXkqMpVrmjp9AonXq and https://github.com/Warbo/haskell-te These use the excellent QuickSpec library from: https://hackage.haskell.org/package/quickspec This empirically (through brute force and QuickCheck testing) conjectures equations about given Haskell function definitions. I think it's a very under-utilised library, perhaps due to a couple of reasons: - It requires hand-holding from the user, e.g. installing packages, importing modules, naming functions, monomorphising types, picking an arity, etc. - It can be very resource-intensive! I know there's some work to address the efficiency concerns in a newer version, but that's not made its way to Hackage, Nixpkgs, etc. yet: https://github.com/nick8325/quickspec My scripts try to address the usability issues. More details are in the README, but basically we can run: quickspec myHaskellDir | renderEqs This will (hopefully) output conjectures found by QuickSpec about the functions defined in myHaskellDir. This automatically finds all function definitions, looks up their types, arities, etc. and invokes QuickSpec in a subprocess (with optional timeouts and memory limits). If we leave off the 'renderEqs', we get an easily-parsed JSON format, which we can feed into other tools. Note that I make *heavy* use of the Nix language, and it's quite hit-or-miss whether a package will work. My hope is that more widespread knowledge of these tools will alleviate some of the existing pain points. In particular, many packages define `Arbitrary` instances for their types, but they do so in their test suites rather than their libraries, so nobody else can make use of them (I assume this is to keep down library dependencies?) Suggestions and contributions are welcome! -- Thanks, Chris Warburton From hjgtuyl at chello.nl Sat Nov 11 14:57:34 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 11 Nov 2017 15:57:34 +0100 Subject: [Haskell-cafe] [ANN] Book About Simulation In-Reply-To: References: <23AF5A07-ED70-41C2-B1AA-85CF4146DF23@gmail.com> Message-ID: I got the same when I tried to read the PDF via the TOR network. When I went via a VPN, I saw the PDF immediately. Regards, Henk-Jan van Tuyl On Mon, 06 Nov 2017 00:05:23 +0100, Richard A. O'Keefe wrote: > On 5/11/17 7:43 PM, David Sorokin wrote: >> Hi Cafe, >> >> I am delightful to inform that I wrote a book about simulation, Haskell >> and my Aivika libraries. >> >> http://aivikasoft.com/downloads/aivika/aivika.pdf > > This sounded interesting, but when I clicked on the link, > I got a solid green page with these words in black: > The domain aivikasoft.com is no longer parked by GoDaddy. > > At https://github.com/dsorokin/aivika/wiki > the "Aivika Tutorial for Beginners" link points to > aivikasoft.com, which again gets a GoDaddy page. > > The link to the Aivika manual PDF works, but I take it > that the book you are telling us about is something else. -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From qdunkan at gmail.com Mon Nov 13 03:53:40 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 12 Nov 2017 19:53:40 -0800 Subject: [Haskell-cafe] uninstalling libraries Message-ID: For a very long time, I've used a local script to uninstall libraries. Initially it was very simple: use ghc-pkg field to find and remove library-dirs, import-dirs, and haddock-html, and call ghc-pkg unregister. It served well for a long time, but eventually I got tired of copy paste games and extended it to be able to recursively delete dependents too. Unfortunately now it's no longer so simple. The main problem is that the only way I know to find dependents is to ghc-pkg unregister, and see what the error message complains about. That's obviously pretty bad, since by that time you've already unregistered, so it's too late to back out. The non-atomic nature of unregister+rm has always caused problems anyway, since if unregister succeeds, but the remove fails, we are stuck with a partial install. Recursive delete is too error prone, so I reverted that. And then I discovered that hmatrix helpfully includes /opt/local/lib and /usr/local/lib in its library-dirs, so clearly just deleting whatever the package tells me is not very safe. All this has led me to believe uninstalling packages is not so simple, and maybe there should be an actual real way to do it, not everyone hacking up their own dangerous shell scripts. So... is there? Should there be one? Is there interest in one? How do other people uninstall libraries? Is there a better interface to the pkg db than ghc-pkg? Is there a better way to find dependents than ghc-pkg unregister? From allbery.b at gmail.com Mon Nov 13 04:14:59 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 12 Nov 2017 23:14:59 -0500 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: The problem is that the package db contains only what ghc needs to be able to use the library; not the additional information needed to safely remove it. (There are other package systems with this problem, notably Apple's. Apple decided that instead of solving it, they would only support applications that are complete bundles in and of themselves.) And arguably it doesn't actually belong in ghc-pkg insofar as it's not intended to do anything but store the information needed for ghc to link against packages. This is something of a nasty problem, considering that storing uninstall information separately is not particularly robust. Perhaps ghc-pkg should, if it doesn't already, support extension fields that e.g. cabal can use to store uninstall information. (But even that potentially has problems, given that people are known to copy package registration information between package databases. If there is uninstall information in there, what happens if someone uninstalls via one or the other copy?) On Sun, Nov 12, 2017 at 10:53 PM, Evan Laforge wrote: > For a very long time, I've used a local script to uninstall libraries. > Initially it was very simple: use ghc-pkg field to find and remove > library-dirs, import-dirs, and haddock-html, and call ghc-pkg > unregister. > > It served well for a long time, but eventually I got tired of copy > paste games and extended it to be able to recursively delete > dependents too. Unfortunately now it's no longer so simple. The main > problem is that the only way I know to find dependents is to ghc-pkg > unregister, and see what the error message complains about. That's > obviously pretty bad, since by that time you've already unregistered, > so it's too late to back out. The non-atomic nature of unregister+rm > has always caused problems anyway, since if unregister succeeds, but > the remove fails, we are stuck with a partial install. Recursive > delete is too error prone, so I reverted that. > > And then I discovered that hmatrix helpfully includes /opt/local/lib > and /usr/local/lib in its library-dirs, so clearly just deleting > whatever the package tells me is not very safe. All this has led me > to believe uninstalling packages is not so simple, and maybe there > should be an actual real way to do it, not everyone hacking up their > own dangerous shell scripts. > > So... is there? Should there be one? Is there interest in one? How > do other people uninstall libraries? Is there a better interface to > the pkg db than ghc-pkg? Is there a better way to find dependents > than ghc-pkg unregister? > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- 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 qdunkan at gmail.com Mon Nov 13 04:45:19 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Sun, 12 Nov 2017 20:45:19 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery wrote: > This is something of a nasty problem, considering that storing uninstall > information separately is not particularly robust. Perhaps ghc-pkg should, > if it doesn't already, support extension fields that e.g. cabal can use to > store uninstall information. (But even that potentially has problems, given > that people are known to copy package registration information between > package databases. If there is uninstall information in there, what happens > if someone uninstalls via one or the other copy?) Aren't packages only allowed to install a restricted set of things into a restricted set of places? We have the code (.hi, .a, .so, etc., in import-dirs / library-dirs), possibly library-specific data (I assume that's data-dir), and haddock (haddock-html and haddock-interfaces, awkwardly in separate places). One problem is that I don't fully understand what those fields mean, is there documentation somewhere? And then the fact that these are all plural so presumably you could have a lot of them, what is that for? I'm guessing library-dirs means something like "put this on your -L line" so it's clearly a mistake to interpret that as "here's where I put the library", and you'll have things like /usr/local/lib if you need to link external libraries. Is there any more complicated install plan than put *.a, *.so, *.hi in $root/lib/$ghc/$package-$id, put haddock in $root/share/doc/$ghc/$package, put ad-hoc junk in $root/share/$ghc/$package? I assume there must be, but who's doing that and why? If it's OS packages, then they have their own uninstall mechanisms, presumably not ghc's problem. From allbery.b at gmail.com Mon Nov 13 04:51:17 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 12 Nov 2017 23:51:17 -0500 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: cabal and stack, and in the case of stack, cabal new-build, and possibly cabal sandboxes, you probably shouldn't be trying to uninstall. And yes, the data lines are telling ghc what to compile / link with, not files but command line inclusions. And this will be especially messy on OS X because of the need to group .dylibs together to avoid making the link commands section too large with multiple RPATH entries. (Which will also complicate uninstallation there.) On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge wrote: > On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery > wrote: > > This is something of a nasty problem, considering that storing uninstall > > information separately is not particularly robust. Perhaps ghc-pkg > should, > > if it doesn't already, support extension fields that e.g. cabal can use > to > > store uninstall information. (But even that potentially has problems, > given > > that people are known to copy package registration information between > > package databases. If there is uninstall information in there, what > happens > > if someone uninstalls via one or the other copy?) > > Aren't packages only allowed to install a restricted set of things > into a restricted set of places? We have the code (.hi, .a, .so, > etc., in import-dirs / library-dirs), possibly library-specific data > (I assume that's data-dir), and haddock (haddock-html and > haddock-interfaces, awkwardly in separate places). > > One problem is that I don't fully understand what those fields mean, > is there documentation somewhere? And then the fact that these are > all plural so presumably you could have a lot of them, what is that > for? > > I'm guessing library-dirs means something like "put this on your -L > line" so it's clearly a mistake to interpret that as "here's where I > put the library", and you'll have things like /usr/local/lib if you > need to link external libraries. > > Is there any more complicated install plan than put *.a, *.so, *.hi in > $root/lib/$ghc/$package-$id, put haddock in > $root/share/doc/$ghc/$package, put ad-hoc junk in > $root/share/$ghc/$package? I assume there must be, but who's doing > that and why? If it's OS packages, then they have their own uninstall > mechanisms, presumably not ghc's problem. > -- 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 michael at orlitzky.com Mon Nov 13 15:30:39 2017 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 13 Nov 2017 10:30:39 -0500 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: On 11/12/2017 10:53 PM, Evan Laforge wrote: > > All this has led me to believe uninstalling packages is not so > simple, and maybe there should be an actual real way to do it, not > everyone hacking up their own dangerous shell scripts. > > So... is there? Should there be one? Is there interest in one? > How do other people uninstall libraries? The thing you want is called a package manager. From danburton.email at gmail.com Mon Nov 13 20:27:07 2017 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 13 Nov 2017 12:27:07 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: I also lean towards the "you shouldn't be trying to uninstall" mentality. But it's worth discussing. What is the motive for uninstalling? Is it to upgrade to a new version? To narrow hoogle search results? For these, our sandbox tooling should allow for upgrades or selective querying without having to manually uninstall. If it's just because you want the hard drive space back, then I don't really have anything for that. On Nov 12, 2017 20:55, "Brandon Allbery" wrote: cabal and stack, and in the case of stack, cabal new-build, and possibly cabal sandboxes, you probably shouldn't be trying to uninstall. And yes, the data lines are telling ghc what to compile / link with, not files but command line inclusions. And this will be especially messy on OS X because of the need to group .dylibs together to avoid making the link commands section too large with multiple RPATH entries. (Which will also complicate uninstallation there.) On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge wrote: > On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery > wrote: > > This is something of a nasty problem, considering that storing uninstall > > information separately is not particularly robust. Perhaps ghc-pkg > should, > > if it doesn't already, support extension fields that e.g. cabal can use > to > > store uninstall information. (But even that potentially has problems, > given > > that people are known to copy package registration information between > > package databases. If there is uninstall information in there, what > happens > > if someone uninstalls via one or the other copy?) > > Aren't packages only allowed to install a restricted set of things > into a restricted set of places? We have the code (.hi, .a, .so, > etc., in import-dirs / library-dirs), possibly library-specific data > (I assume that's data-dir), and haddock (haddock-html and > haddock-interfaces, awkwardly in separate places). > > One problem is that I don't fully understand what those fields mean, > is there documentation somewhere? And then the fact that these are > all plural so presumably you could have a lot of them, what is that > for? > > I'm guessing library-dirs means something like "put this on your -L > line" so it's clearly a mistake to interpret that as "here's where I > put the library", and you'll have things like /usr/local/lib if you > need to link external libraries. > > Is there any more complicated install plan than put *.a, *.so, *.hi in > $root/lib/$ghc/$package-$id, put haddock in > $root/share/doc/$ghc/$package, put ad-hoc junk in > $root/share/$ghc/$package? I assume there must be, but who's doing > that and why? If it's OS packages, then they have their own uninstall > mechanisms, presumably not ghc's problem. > -- 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 qdunkan at gmail.com Mon Nov 13 22:45:33 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 13 Nov 2017 14:45:33 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton wrote: > I also lean towards the "you shouldn't be trying to uninstall" mentality. > But it's worth discussing. > > What is the motive for uninstalling? Is it to upgrade to a new version? To > narrow hoogle search results? For these, our sandbox tooling should allow > for upgrades or selective querying without having to manually uninstall. If > it's just because you want the hard drive space back, then I don't really > have anything for that. I'm usually backing out of a version so I can install something else. I always keep just one version of each library installed. It's less clutter, and I never have any question about what package is linked to what version of what other package. Maybe it's not the official way to do things, but it's probably the reason I've never encountered cabal hell. Back in the day, of course, it was the only option. Nowadays we have cabal sandbox, but global packages are still simpler and more convenient. Maybe the new cabal install will improve on the situation, but it seems hard to beat the convenience, and doesn't provide the guarantee that there's no version skew anywhere. But, I'm not the only one with a single version policy, Google does too. Anyway, if there's no interest in robust uninstallation, I'll just continue using my script, with a few extra hacks to avoid deleting /usr/local/lib. Except that one hiccup it's actually worked fine for the last 15 years or so. For me, making a better API to the package db than ghc-pkg would probably do well enough. From neil_mayhew at users.sourceforge.net Mon Nov 13 23:33:36 2017 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Mon, 13 Nov 2017 16:33:36 -0700 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: <81578193-09f2-f4e2-4cf7-6b6ed53ea19e@users.sourceforge.net> On 2017-11-13 08:30 AM, Michael Orlitzky wrote: > The thing you want is called a package manager. Evan, have you considered using Nix? It's a package manager that sits on top of the OS, and works on Linux and Mac OS. My Haskell development has been much happier since I switched to using Nix. Pros of Nix versus using cabal sandboxes: 1. Nix shares built libraries between projects, so doesn't chew up gobs of disk space for each project 2. You don't have to build huge numbers of libraries from source for each project, due to sharing. In fact, due to Nix's binary caching, you rarely have to build libraries from source at all. Cons: 1. If you want to use a newer version of a Hackage library than the one in in Nix, it's more work (although the packages track Hackage fairly closely). 2. Occasionally the version in Nix is broken. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Tue Nov 14 00:56:33 2017 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 13 Nov 2017 16:56:33 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: The point at which I find a "single version policy" difficult is when I'm trying to contribute to disparate packages or projects, with differing maintainers and version requirements. One person wants to use the latest, while another hasn't upgraded yet. Sandboxing is the only sane way to work on two such projects simultaneously. But if you, like Google, have enough control over all the projects worked on in order to dictate a single version policy, then that approach can certainly have its benefits. I'm not sure many people consider themselves in such a position, hence the pervasive assumption that sandboxing will be involved. On Nov 13, 2017 14:45, "Evan Laforge" wrote: On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton wrote: > I also lean towards the "you shouldn't be trying to uninstall" mentality. > But it's worth discussing. > > What is the motive for uninstalling? Is it to upgrade to a new version? To > narrow hoogle search results? For these, our sandbox tooling should allow > for upgrades or selective querying without having to manually uninstall. If > it's just because you want the hard drive space back, then I don't really > have anything for that. I'm usually backing out of a version so I can install something else. I always keep just one version of each library installed. It's less clutter, and I never have any question about what package is linked to what version of what other package. Maybe it's not the official way to do things, but it's probably the reason I've never encountered cabal hell. Back in the day, of course, it was the only option. Nowadays we have cabal sandbox, but global packages are still simpler and more convenient. Maybe the new cabal install will improve on the situation, but it seems hard to beat the convenience, and doesn't provide the guarantee that there's no version skew anywhere. But, I'm not the only one with a single version policy, Google does too. Anyway, if there's no interest in robust uninstallation, I'll just continue using my script, with a few extra hacks to avoid deleting /usr/local/lib. Except that one hiccup it's actually worked fine for the last 15 years or so. For me, making a better API to the package db than ghc-pkg would probably do well enough. -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Tue Nov 14 01:39:01 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 13 Nov 2017 17:39:01 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: To be fair, it's not absolute. I have found cabal sandbox useful to compile things thing tons of dependencies, like pandoc. And if I wanted to contribute to something with out of date version requirements (and the first step is not helping them upgrade, for whatever reason), then surely I'd go ahead and make a sandbox for that. It hasn't really come up though. I'm certainly not trying to push this as The Solution, that's a bigger windmill than just uninstalls :) On Mon, Nov 13, 2017 at 4:56 PM, Dan Burton wrote: > The point at which I find a "single version policy" difficult is when I'm > trying to contribute to disparate packages or projects, with differing > maintainers and version requirements. One person wants to use the latest, > while another hasn't upgraded yet. Sandboxing is the only sane way to work > on two such projects simultaneously. > > But if you, like Google, have enough control over all the projects worked on > in order to dictate a single version policy, then that approach can > certainly have its benefits. I'm not sure many people consider themselves in > such a position, hence the pervasive assumption that sandboxing will be > involved. > > > On Nov 13, 2017 14:45, "Evan Laforge" wrote: > > On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton > wrote: >> I also lean towards the "you shouldn't be trying to uninstall" mentality. >> But it's worth discussing. >> >> What is the motive for uninstalling? Is it to upgrade to a new version? To >> narrow hoogle search results? For these, our sandbox tooling should allow >> for upgrades or selective querying without having to manually uninstall. >> If >> it's just because you want the hard drive space back, then I don't really >> have anything for that. > > I'm usually backing out of a version so I can install something else. > I always keep just one version of each library installed. It's less > clutter, and I never have any question about what package is linked to > what version of what other package. > > Maybe it's not the official way to do things, but it's probably the > reason I've never encountered cabal hell. Back in the day, of course, > it was the only option. Nowadays we have cabal sandbox, but global > packages are still simpler and more convenient. Maybe the new cabal > install will improve on the situation, but it seems hard to beat the > convenience, and doesn't provide the guarantee that there's no version > skew anywhere. But, I'm not the only one with a single version > policy, Google does too. > > Anyway, if there's no interest in robust uninstallation, I'll just > continue using my script, with a few extra hacks to avoid deleting > /usr/local/lib. Except that one hiccup it's actually worked fine for > the last 15 years or so. For me, making a better API to the package > db than ghc-pkg would probably do well enough. > > From twhitehead at gmail.com Tue Nov 14 03:38:24 2017 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue, 14 Nov 2017 03:38:24 +0000 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: I used to fight with a combination of system and cabal installed packages under debian testing. Then, about a year ago, the frustration became too much and I switched to using nix, intero in emacs, and stack with the nix resolver, all installed with nix on my debian machine. Couldn't be happier. If I want a new dependency, I just add it to my cabal file, rerun cabal2nix, restart intero and it all just works. Talk about a vastly improved experience over what I used to have. As a major bonus I now also run the exact same setup on our HPC cluster, which runs centos 6, and I can switch between them seamlessly. Cheers -Tyson PS: The only gotcha I ran into so far is that stack/intero installs a ghcpaths package outside of nix on first startup that can causes conflicts with some packages. Turns out you can just manually remove it though to resolve this, so no big deal. On Sun, Nov 12, 2017, 23:52 Brandon Allbery, wrote: > cabal and stack, and in the case of stack, cabal new-build, and possibly > cabal sandboxes, you probably shouldn't be trying to uninstall. > > And yes, the data lines are telling ghc what to compile / link with, not > files but command line inclusions. And this will be especially messy on OS > X because of the need to group .dylibs together to avoid making the link > commands section too large with multiple RPATH entries. (Which will also > complicate uninstallation there.) > > On Sun, Nov 12, 2017 at 11:45 PM, Evan Laforge wrote: > >> On Sun, Nov 12, 2017 at 8:14 PM, Brandon Allbery >> wrote: >> > This is something of a nasty problem, considering that storing uninstall >> > information separately is not particularly robust. Perhaps ghc-pkg >> should, >> > if it doesn't already, support extension fields that e.g. cabal can use >> to >> > store uninstall information. (But even that potentially has problems, >> given >> > that people are known to copy package registration information between >> > package databases. If there is uninstall information in there, what >> happens >> > if someone uninstalls via one or the other copy?) >> >> Aren't packages only allowed to install a restricted set of things >> into a restricted set of places? We have the code (.hi, .a, .so, >> etc., in import-dirs / library-dirs), possibly library-specific data >> (I assume that's data-dir), and haddock (haddock-html and >> haddock-interfaces, awkwardly in separate places). >> >> One problem is that I don't fully understand what those fields mean, >> is there documentation somewhere? And then the fact that these are >> all plural so presumably you could have a lot of them, what is that >> for? >> >> I'm guessing library-dirs means something like "put this on your -L >> line" so it's clearly a mistake to interpret that as "here's where I >> put the library", and you'll have things like /usr/local/lib if you >> need to link external libraries. >> >> Is there any more complicated install plan than put *.a, *.so, *.hi in >> $root/lib/$ghc/$package-$id, put haddock in >> $root/share/doc/$ghc/$package, put ad-hoc junk in >> $root/share/$ghc/$package? I assume there must be, but who's doing >> that and why? If it's OS packages, then they have their own uninstall >> mechanisms, presumably not ghc's problem. >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qdunkan at gmail.com Tue Nov 14 07:31:34 2017 From: qdunkan at gmail.com (Evan Laforge) Date: Mon, 13 Nov 2017 23:31:34 -0800 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: <81578193-09f2-f4e2-4cf7-6b6ed53ea19e@users.sourceforge.net> References: <81578193-09f2-f4e2-4cf7-6b6ed53ea19e@users.sourceforge.net> Message-ID: On Mon, Nov 13, 2017 at 3:33 PM, Neil Mayhew wrote: > On 2017-11-13 08:30 AM, Michael Orlitzky wrote: >> The thing you want is called a package manager. > > Evan, have you considered using Nix? It's a package manager that sits on top > of the OS, and works on Linux and Mac OS. My Haskell development has been > much happier since I switched to using Nix. I have, but more just for fun because it seems like a neat system, and also of course because everyone keeps saying how great it is. But not necessarily to solve a real problem, since uninstalling the odd package already works fine. Except that /usr/local/lib fiasco. If there are more fiascos in the future I might wind up with nix :) From johannes.waldmann at htwk-leipzig.de Tue Nov 14 14:01:52 2017 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 14 Nov 2017 15:01:52 +0100 Subject: [Haskell-cafe] how to make a KnownNat at runtime? Message-ID: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> Dear Cafe, I am using type-level numbers for representing dimensions of vectors and matrices (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) Now when I indeed know all the dimensions at compile time, (in the example code, line 20) everything works nicely. But what do I do when the dimensions will only become available at run time? Here is a simplified example: print the null vector where the size is read from the command line - of course in my application "handle" does more, but it essentially has the type given here. I can extend the "case" in the "main" function to include all the values I want to handle. Looks ugly. Is there a better way? - J. {-# language KindSignatures, RankNTypes, LambdaCase, TypeApplications, DataKinds, ScopedTypeVariables #-} import GHC.TypeLits import Data.Proxy import System.Environment main :: IO () main = getArgs >>= \ case [ "2" ] -> handle (Proxy :: Proxy 2) [ "3" ] -> handle (Proxy :: Proxy 3) handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () handle (_ :: Proxy n) = print (zero :: V n Int) data V (n::Nat) a = V [a] deriving Show zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 From hesselink at gmail.com Tue Nov 14 14:27:59 2017 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 14 Nov 2017 15:27:59 +0100 Subject: [Haskell-cafe] how to make a KnownNat at runtime? In-Reply-To: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> References: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> Message-ID: Hi Johannes, I believe you can parse your argument into an `Integer`, and then use `someNatVal` [1] to produce `SomeNat`, an existential (unknown) type level number. Then, you can pattern match on this to gain access to the `KnownNat` instance. Regards, Erik [1] http://hackage.haskell.org/package/base-4.9.0.0/docs/GHC-TypeLits.html#v:someNatVal On 14 November 2017 at 15:01, Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > Dear Cafe, > > I am using type-level numbers for > representing dimensions of vectors and matrices > (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) > Now when I indeed know all the dimensions at compile time, > (in the example code, line 20) everything works nicely. > > But what do I do when the dimensions > will only become available at run time? > > Here is a simplified example: print the null vector > where the size is read from the command line - > of course in my application "handle" does more, > but it essentially has the type given here. > > I can extend the "case" in the "main" function > to include all the values I want to handle. > Looks ugly. Is there a better way? > > - J. > > {-# language KindSignatures, RankNTypes, LambdaCase, > TypeApplications, DataKinds, ScopedTypeVariables > #-} > > import GHC.TypeLits > import Data.Proxy > import System.Environment > > main :: IO () > main = getArgs >>= \ case > [ "2" ] -> handle (Proxy :: Proxy 2) > [ "3" ] -> handle (Proxy :: Proxy 3) > > handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () > handle (_ :: Proxy n) = print (zero :: V n Int) > > data V (n::Nat) a = V [a] deriving Show > > zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a > zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 olshanskydr at gmail.com Tue Nov 14 14:54:39 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Tue, 14 Nov 2017 17:54:39 +0300 Subject: [Haskell-cafe] how to make a KnownNat at runtime? In-Reply-To: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> References: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> Message-ID: I asked the same question on stackoverflow . It is impossible now. If it is possible we have a language with dependent types. Unfortunately we haven't it at least till 2020. I spent some time trying to find a decision but had no success. Success here means a bug in type system. Regards, Dmitry 2017-11-14 17:01 GMT+03:00 Johannes Waldmann < johannes.waldmann at htwk-leipzig.de>: > Dear Cafe, > > I am using type-level numbers for > representing dimensions of vectors and matrices > (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) > Now when I indeed know all the dimensions at compile time, > (in the example code, line 20) everything works nicely. > > But what do I do when the dimensions > will only become available at run time? > > Here is a simplified example: print the null vector > where the size is read from the command line - > of course in my application "handle" does more, > but it essentially has the type given here. > > I can extend the "case" in the "main" function > to include all the values I want to handle. > Looks ugly. Is there a better way? > > - J. > > {-# language KindSignatures, RankNTypes, LambdaCase, > TypeApplications, DataKinds, ScopedTypeVariables > #-} > > import GHC.TypeLits > import Data.Proxy > import System.Environment > > main :: IO () > main = getArgs >>= \ case > [ "2" ] -> handle (Proxy :: Proxy 2) > [ "3" ] -> handle (Proxy :: Proxy 3) > > handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () > handle (_ :: Proxy n) = print (zero :: V n Int) > > data V (n::Nat) a = V [a] deriving Show > > zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a > zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 gregmainland at gmail.com Tue Nov 14 16:20:29 2017 From: gregmainland at gmail.com (Greg Horn) Date: Tue, 14 Nov 2017 16:20:29 +0000 Subject: [Haskell-cafe] how to make a KnownNat at runtime? In-Reply-To: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> References: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> Message-ID: I think the functionality you're looking for is reifyNat :: Integer -> (forall n. KnownNat n => Proxy n -> r) -> r http://hackage.haskell.org/package/reflection-2.1.2/docs/Data-Reflection.html#v:reifyNat On Tue, Nov 14, 2017 at 6:11 AM Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > Dear Cafe, > > I am using type-level numbers for > representing dimensions of vectors and matrices > (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) > Now when I indeed know all the dimensions at compile time, > (in the example code, line 20) everything works nicely. > > But what do I do when the dimensions > will only become available at run time? > > Here is a simplified example: print the null vector > where the size is read from the command line - > of course in my application "handle" does more, > but it essentially has the type given here. > > I can extend the "case" in the "main" function > to include all the values I want to handle. > Looks ugly. Is there a better way? > > - J. > > {-# language KindSignatures, RankNTypes, LambdaCase, > TypeApplications, DataKinds, ScopedTypeVariables > #-} > > import GHC.TypeLits > import Data.Proxy > import System.Environment > > main :: IO () > main = getArgs >>= \ case > [ "2" ] -> handle (Proxy :: Proxy 2) > [ "3" ] -> handle (Proxy :: Proxy 3) > > handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () > handle (_ :: Proxy n) = print (zero :: V n Int) > > data V (n::Nat) a = V [a] deriving Show > > zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a > zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Tue Nov 14 17:30:02 2017 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 14 Nov 2017 18:30:02 +0100 Subject: [Haskell-cafe] how to make a KnownNat at runtime? In-Reply-To: References: <1c49e95c-7010-3b96-d8fb-84ba0032d2e4@htwk-leipzig.de> Message-ID: <109e7cb2-7ab5-d188-9a46-64de7aa2af5d@htwk-leipzig.de> On 14.11.2017 17:20, Greg Horn wrote: > http://hackage.haskell.org/package/reflection-2.1.2/docs/Data-Reflection.html#v:reifyNat Thanks! That is exactly what I want. - J. main :: IO () main = getArgs >>= \ case [ s ] -> reifyNat (read s :: Integer) handle handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () ... From ben.franksen at online.de Wed Nov 15 10:34:07 2017 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 15 Nov 2017 11:34:07 +0100 Subject: [Haskell-cafe] uninstalling libraries In-Reply-To: References: Message-ID: I recommend cabal new-build. I am using it ever since it came out and never looked back. You can have the cake and eat it. Yes it's not yet fully stable and every once in a while I have to remove dist-newstyle and do a clean re-build. This happens mostly when I pull changes to the cabal file and is still *much* faster than re-building all dependencies. Cheers Ben Am 14.11.2017 um 02:39 schrieb Evan Laforge: > To be fair, it's not absolute. I have found cabal sandbox useful to > compile things thing tons of dependencies, like pandoc. And if I > wanted to contribute to something with out of date version > requirements (and the first step is not helping them upgrade, for > whatever reason), then surely I'd go ahead and make a sandbox for > that. It hasn't really come up though. I'm certainly not trying to > push this as The Solution, that's a bigger windmill than just > uninstalls :) > > On Mon, Nov 13, 2017 at 4:56 PM, Dan Burton wrote: >> The point at which I find a "single version policy" difficult is when I'm >> trying to contribute to disparate packages or projects, with differing >> maintainers and version requirements. One person wants to use the latest, >> while another hasn't upgraded yet. Sandboxing is the only sane way to work >> on two such projects simultaneously. >> >> But if you, like Google, have enough control over all the projects worked on >> in order to dictate a single version policy, then that approach can >> certainly have its benefits. I'm not sure many people consider themselves in >> such a position, hence the pervasive assumption that sandboxing will be >> involved. >> >> >> On Nov 13, 2017 14:45, "Evan Laforge" wrote: >> >> On Mon, Nov 13, 2017 at 12:27 PM, Dan Burton >> wrote: >>> I also lean towards the "you shouldn't be trying to uninstall" mentality. >>> But it's worth discussing. >>> >>> What is the motive for uninstalling? Is it to upgrade to a new version? To >>> narrow hoogle search results? For these, our sandbox tooling should allow >>> for upgrades or selective querying without having to manually uninstall. >>> If >>> it's just because you want the hard drive space back, then I don't really >>> have anything for that. >> >> I'm usually backing out of a version so I can install something else. >> I always keep just one version of each library installed. It's less >> clutter, and I never have any question about what package is linked to >> what version of what other package. >> >> Maybe it's not the official way to do things, but it's probably the >> reason I've never encountered cabal hell. Back in the day, of course, >> it was the only option. Nowadays we have cabal sandbox, but global >> packages are still simpler and more convenient. Maybe the new cabal >> install will improve on the situation, but it seems hard to beat the >> convenience, and doesn't provide the guarantee that there's no version >> skew anywhere. But, I'm not the only one with a single version >> policy, Google does too. >> >> Anyway, if there's no interest in robust uninstallation, I'll just >> continue using my script, with a few extra hacks to avoid deleting >> /usr/local/lib. Except that one hiccup it's actually worked fine for >> the last 15 years or so. For me, making a better API to the package >> db than ghc-pkg would probably do well enough. >> >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > From monkleyon at gmail.com Wed Nov 15 14:30:37 2017 From: monkleyon at gmail.com (MarLinn) Date: Wed, 15 Nov 2017 15:30:37 +0100 Subject: [Haskell-cafe] Project idea, seeking feedback In-Reply-To: <20171108082124.71b447b4@centromere.net> References: <20171108082124.71b447b4@centromere.net> Message-ID: Hi Alex, sounds ambitious. But you might be able to reduce the scope massively by relying on existing tools. Examples: * Let something like Nagios do the monitoring. I know there's tools to control Nagios from Haskell. What I don't know is how up-to-date they are, and I haven't seen something that reports internal performance data of a Haskell app to Nagios, but that should be simple if necessary. * Let something like Cassandra handle both the heaviest parts of messaging between your node controllers and the storage of their config data. If you base your WUI on top of the DB, you can separate it from the controllers as well. * Coordination of resources is a variant of scheduling, which is a ""solved"" problem. So there should be libraries you can use. * Logging has been worked on by many a commercial Haskeller. My guess is that filtering is just a matter of looking at one of the libraries from the right angle. This leaves orchestration, API connectors, and the DSL as the missing parts. Which sounds way more doable than having your tool do all the lifting itself. Or just use Kubernetes. Whichever is easier. ;) Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai.maruseac at gmail.com Wed Nov 15 15:58:06 2017 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Wed, 15 Nov 2017 07:58:06 -0800 Subject: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (33rd ed., November 2017) Message-ID: On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (33rd edition, November 2017) is now available, in PDF and HTML formats: http://haskell.org/communities/11-2017/report.pdf http://haskell.org/communities/11-2017/html/report.html All previous editions of HCAR can be accessed on the wiki at https://wiki.haskell.org/Haskell_Communities_and_Activities_Report Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of February 2018: target deadline for contributions to the May 2018 edition of the HCAR Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in November (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From jeffbrown.the at gmail.com Wed Nov 15 19:04:38 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Wed, 15 Nov 2017 11:04:38 -0800 Subject: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (33rd ed., November 2017) In-Reply-To: References: Message-ID: This treasure trove almost flew under my radar! From the title I thought it was just going to be the results of the recent survey. When I started reading, I thought it would only be plans for changes to the language. Finally I made it to the list (section 4) of tools that exist now and was like woah. On Wed, Nov 15, 2017 at 7:58 AM, Mihai Maruseac wrote: > On behalf of all the contributors, we are pleased to announce that the > > Haskell Communities and Activities Report > (33rd edition, November 2017) > > is now available, in PDF and HTML formats: > > http://haskell.org/communities/11-2017/report.pdf > http://haskell.org/communities/11-2017/html/report.html > > All previous editions of HCAR can be accessed on the wiki at > https://wiki.haskell.org/Haskell_Communities_and_Activities_Report > > Many thanks go to all the people that contributed to this report, > both directly, by sending in descriptions, and indirectly, by doing > all the interesting things that are reported. We hope you will find > it as interesting a read as we did. > > If you have not encountered the Haskell Communities and Activities > Reports before, you may like to know that the first of these reports > was published in November 2001. Their goal is to improve the > communication between the increasingly diverse groups, projects, and > individuals working on, with, or inspired by Haskell. The idea behind > these reports is simple: > > Every six months, a call goes out to all of you enjoying Haskell to > contribute brief summaries of your own area of work. Many of you > respond (eagerly, unprompted, and sometimes in time for the actual > deadline) to the call. The editors collect all the contributions > into a single report and feed that back to the community. > > When we try for the next update, six months from now, you might want > to report on your own work, project, research area or group as well. > So, please put the following into your diaries now: > > ======================================== > End of February 2018: > target deadline for contributions to the > May 2018 edition of the HCAR Report > ======================================== > > Unfortunately, many Haskellers working on interesting projects are so > busy with their work that they seem to have lost the time to follow > the Haskell related mailing lists and newsgroups, and have trouble even > finding time to report on their work. If you are a member, user or > friend of a project so burdened, please find someone willing to make > time to report and ask them to "register" with the editors for a simple > e-mail reminder in November (you could point us to them as well, and we > can then politely ask if they want to contribute, but it might work > better if you do the initial asking). Of course, they will still have to > find the ten to fifteen minutes to draw up their report, but maybe we > can increase our coverage of all that is going on in the community. > > Feel free to circulate this announcement further in order to > reach people who might otherwise not see it. Enjoy! > > > -- > Mihai Maruseac (MM) > "If you can't solve a problem, then there's an easier problem you can > solve: find it." -- George Polya > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 (spammy, so I often miss messages here) | Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From leiva.steven at gmail.com Wed Nov 15 20:02:16 2017 From: leiva.steven at gmail.com (Steven Leiva) Date: Wed, 15 Nov 2017 15:02:16 -0500 Subject: [Haskell-cafe] [Haskell-beginners] ANNOUNCE: Haskell Communities and Activities Report (33rd ed., November 2017) In-Reply-To: References: Message-ID: I'd also like to express my gratitude for this publication. Treasury trove is the most appropriate term for it indeed. (Going to go check out yesod-rest now). - Steven On Wed, Nov 15, 2017 at 2:04 PM, Jeffrey Brown wrote: > This treasure trove almost flew under my radar! From the title I thought > it was just going to be the results of the recent survey. When I started > reading, I thought it would only be plans for changes to the language. > Finally I made it to the list (section 4) of tools that exist now and was > like woah. > > On Wed, Nov 15, 2017 at 7:58 AM, Mihai Maruseac > wrote: > >> On behalf of all the contributors, we are pleased to announce that the >> >> Haskell Communities and Activities Report >> (33rd edition, November 2017) >> >> is now available, in PDF and HTML formats: >> >> http://haskell.org/communities/11-2017/report.pdf >> http://haskell.org/communities/11-2017/html/report.html >> >> All previous editions of HCAR can be accessed on the wiki at >> https://wiki.haskell.org/Haskell_Communities_and_Activities_Report >> >> Many thanks go to all the people that contributed to this report, >> both directly, by sending in descriptions, and indirectly, by doing >> all the interesting things that are reported. We hope you will find >> it as interesting a read as we did. >> >> If you have not encountered the Haskell Communities and Activities >> Reports before, you may like to know that the first of these reports >> was published in November 2001. Their goal is to improve the >> communication between the increasingly diverse groups, projects, and >> individuals working on, with, or inspired by Haskell. The idea behind >> these reports is simple: >> >> Every six months, a call goes out to all of you enjoying Haskell to >> contribute brief summaries of your own area of work. Many of you >> respond (eagerly, unprompted, and sometimes in time for the actual >> deadline) to the call. The editors collect all the contributions >> into a single report and feed that back to the community. >> >> When we try for the next update, six months from now, you might want >> to report on your own work, project, research area or group as well. >> So, please put the following into your diaries now: >> >> ======================================== >> End of February 2018: >> target deadline for contributions to the >> May 2018 edition of the HCAR Report >> ======================================== >> >> Unfortunately, many Haskellers working on interesting projects are so >> busy with their work that they seem to have lost the time to follow >> the Haskell related mailing lists and newsgroups, and have trouble even >> finding time to report on their work. If you are a member, user or >> friend of a project so burdened, please find someone willing to make >> time to report and ask them to "register" with the editors for a simple >> e-mail reminder in November (you could point us to them as well, and we >> can then politely ask if they want to contribute, but it might work >> better if you do the initial asking). Of course, they will still have to >> find the ten to fifteen minutes to draw up their report, but maybe we >> can increase our coverage of all that is going on in the community. >> >> Feel free to circulate this announcement further in order to >> reach people who might otherwise not see it. Enjoy! >> >> >> -- >> Mihai Maruseac (MM) >> "If you can't solve a problem, then there's an easier problem you can >> solve: find it." -- George Polya >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 > (spammy, so I often > miss messages here) | Github > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > -- Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Wed Nov 15 21:13:04 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Wed, 15 Nov 2017 22:13:04 +0100 Subject: [Haskell-cafe] how to make a KnownNat at runtime? In-Reply-To: References: Message-ID: <14FB09AC-5088-4D1E-91AD-0381CB5A3A90@steinitz.org> You mean something like this? > withMatrix > :: forall z > . Matrix ℝ > -> (forall m n . (KnownNat m, KnownNat n) => L m n -> z) > -> z > withMatrix a f = > case someNatVal $ fromIntegral $ rows a of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy m)) -> > case someNatVal $ fromIntegral $ cols a of > Nothing -> error "static/dynamic mismatch" > Just (SomeNat (_ :: Proxy n)) -> > f (mkL a :: L m n) > Dear Cafe, > > I am using type-level numbers for > representing dimensions of vectors and matrices > (similar to https://github.com/ekmett/ersatz/blob/master/tests/Z001.hs ) > Now when I indeed know all the dimensions at compile time, > (in the example code, line 20) everything works nicely. > > But what do I do when the dimensions > will only become available at run time? > > Here is a simplified example: print the null vector > where the size is read from the command line - > of course in my application "handle" does more, > but it essentially has the type given here. > > I can extend the "case" in the "main" function > to include all the values I want to handle. > Looks ugly. Is there a better way? > > - J. > > {-# language KindSignatures, RankNTypes, LambdaCase, > TypeApplications, DataKinds, ScopedTypeVariables > #-} > > import GHC.TypeLits > import Data.Proxy > import System.Environment > > main :: IO () > main = getArgs >>= \ case > [ "2" ] -> handle (Proxy :: Proxy 2) > [ "3" ] -> handle (Proxy :: Proxy 3) > > handle :: forall (n::Nat) . KnownNat n => Proxy n -> IO () > handle (_ :: Proxy n) = print (zero :: V n Int) > > data V (n::Nat) a = V [a] deriving Show > > zero :: forall (n::Nat) a . (KnownNat n, Num a) => V n a > zero = V $ replicate (fromIntegral $ natVal (Proxy :: Proxy n)) 0 > Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From alex at centromere.net Wed Nov 15 22:44:14 2017 From: alex at centromere.net (Alex) Date: Wed, 15 Nov 2017 17:44:14 -0500 Subject: [Haskell-cafe] Project idea, seeking feedback In-Reply-To: References: <20171108082124.71b447b4@centromere.net> Message-ID: <20171115174414.7b990b3c@centromere.net> On Wed, 15 Nov 2017 15:30:37 +0100 MarLinn wrote: > Hi Alex, > > sounds ambitious. But you might be able to reduce the scope massively > by relying on existing tools. > Yes! I do not wish to reinvent the wheel. > Examples: > > * > > Let something like Nagios do the monitoring. I know there's tools > to control Nagios from Haskell. What I don't know is how up-to-date > they are, and I haven't seen something that reports internal > performance data of a Haskell app to Nagios, but that should be > simple if necessary. > I don't think Nagios is a good fit because I want to do more than monitor the performance of the interpreter. I want to rely on that performance data so that I can use resources more effectively. For example, I want to know what the load average of a particular node is, and then I want to rely on historical performance data of the DSL primitives to determine if the next instruction to be executed should be scheduled to run on that node or a different one. > * > > Let something like Cassandra handle both the heaviest parts of > messaging between your node controllers and the storage of their > config data. If you base your WUI on top of the DB, you can > separate it from the controllers as well. > > * > > Coordination of resources is a variant of scheduling, which is a > ""solved"" problem. So there should be libraries you can use. > For cluster coordination/configuration I was thinking of using Consul. > * > > Logging has been worked on by many a commercial Haskeller. My > guess is that filtering is just a matter of looking at one of the > libraries from the right angle. > I intend to leverage existing libraries where possible. I want to create an environment in which the commercial Haskeller never has to choose and wire in a logging library. The decision is already made by the framework. They just need to insert logging statements where appropriate. > Or just use Kubernetes. Whichever is easier. ;) > Kubernetes is a great tool, but it doesn't do what I envision. -- Alex From ben.kolera at gmail.com Wed Nov 15 23:17:07 2017 From: ben.kolera at gmail.com (Ben Kolera) Date: Wed, 15 Nov 2017 23:17:07 +0000 Subject: [Haskell-cafe] Project idea, seeking feedback In-Reply-To: <20171115174414.7b990b3c@centromere.net> References: <20171108082124.71b447b4@centromere.net> <20171115174414.7b990b3c@centromere.net> Message-ID: Don't forget http://zipkin.io/ . It's awesome. :) Cheers, Ben On Thu, 16 Nov 2017 at 08:46 Alex wrote: > On Wed, 15 Nov 2017 15:30:37 +0100 > MarLinn wrote: > > > Hi Alex, > > > > sounds ambitious. But you might be able to reduce the scope massively > > by relying on existing tools. > > > > Yes! I do not wish to reinvent the wheel. > > > Examples: > > > > * > > > > Let something like Nagios do the monitoring. I know there's tools > > to control Nagios from Haskell. What I don't know is how up-to-date > > they are, and I haven't seen something that reports internal > > performance data of a Haskell app to Nagios, but that should be > > simple if necessary. > > > > I don't think Nagios is a good fit because I want to do more than > monitor the performance of the interpreter. I want to rely on that > performance data so that I can use resources more effectively. For > example, I want to know what the load average of a particular node is, > and then I want to rely on historical performance data of the DSL > primitives to determine if the next instruction to be executed should > be scheduled to run on that node or a different one. > > > * > > > > Let something like Cassandra handle both the heaviest parts of > > messaging between your node controllers and the storage of their > > config data. If you base your WUI on top of the DB, you can > > separate it from the controllers as well. > > > > * > > > > Coordination of resources is a variant of scheduling, which is a > > ""solved"" problem. So there should be libraries you can use. > > > > For cluster coordination/configuration I was thinking of using Consul. > > > * > > > > Logging has been worked on by many a commercial Haskeller. My > > guess is that filtering is just a matter of looking at one of the > > libraries from the right angle. > > > > I intend to leverage existing libraries where possible. I want to > create an environment in which the commercial Haskeller never has to > choose and wire in a logging library. The decision is already made by > the framework. They just need to insert logging statements where > appropriate. > > > Or just use Kubernetes. Whichever is easier. ;) > > > > Kubernetes is a great tool, but it doesn't do what I envision. > > -- > Alex > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjenvanweelden at gmail.com Thu Nov 16 09:46:26 2017 From: arjenvanweelden at gmail.com (Arjen) Date: Thu, 16 Nov 2017 10:46:26 +0100 Subject: [Haskell-cafe] Dutch FP-day 2018 (early registration required) References: <1510133843.4548.6.camel@gmail.com> Message-ID: <1510825586.2943.1.camel@gmail.com> I would like to invite you to the next Dutch Functional Programming Day. It will take place on Friday 5th of January 2018, at the Walter Bos Complex of the Dutch Tax and Customs Administration at John F. Kennedylaan 8, Apeldoorn. The Dutch Functional Programming Day is an annual gathering of researchers, students, and practitioners sharing a common interest in functional programming. Experts and newcomers to the field are equally welcome.  For more information see http://wiki.clean.cs.ru.nl/NL-FP_dag_2018 Please note that to the nature of the location, registration before December 15 is required. We need a list of participants for the security staff. We also need this to order the right number of badges, drinks and pizza's.  You can register by sending a mail to a.van.weelden at belastingdienst.nl (or reply to this e-mail) including: 1. your name (used for identification) 2. your affiliation, if any 3. whether you want (vegetarian) pizza 4. whether you want to give a talk There are no costs for anything this year, as it is fully sponsored by the Dutch Tax and Customs Administration. kind regards,         Betsy Pepels and Arjen van Weelden From taylor at fausak.me Thu Nov 16 13:23:25 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 16 Nov 2017 07:23:25 -0600 Subject: [Haskell-cafe] 2017 state of Haskell survey results Message-ID: <4ED935E4-DF06-48E2-909B-C8E9E99302B6@fausak.me> I am excited to announce that the results of the 2017 state of Haskell survey are now available: http://taylor.fausak.me/2017/11/15/2017-state-of-haskell-survey-results/ Thanks to everyone who responded! -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Nov 17 09:38:07 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Nov 2017 10:38:07 +0100 (CET) Subject: [Haskell-cafe] latin file encoding Message-ID: I have a LATIN-1 encoded file on a UTF-8 configured system: $ iconv -f latin1 Text Häßkell $ echo $LANG de_DE.UTF-8 Thus, a Haskell program cannot process it as it is: $ cat Text | ghc-8.2.2 -e 'interact id' | iconv -f latin1 : : hGetContents: invalid argument (invalid byte sequence) So far, so expected. Now I want to run it with latin encoding: $ cat Text | (LANG=de_DE ghc-8.2.2 -e 'interact id') | iconv -f latin1 : : hGetContents: invalid argument (invalid byte sequence) That's unexpected. Is this the reason: $ LANG=de_DE ghc-8.2.2 -e 'print System.IO.localeEncoding' ASCII ? Btw. what would be the Locale name for Latin-1 encoding? From lemming at henning-thielemann.de Fri Nov 17 10:04:47 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 17 Nov 2017 11:04:47 +0100 (CET) Subject: [Haskell-cafe] latin file encoding In-Reply-To: References: Message-ID: On Fri, 17 Nov 2017, Henning Thielemann wrote: > That's unexpected. Is this the reason: > > $ LANG=de_DE ghc-8.2.2 -e 'print System.IO.localeEncoding' > ASCII > > ? Btw. what would be the Locale name for Latin-1 encoding? I see, the de_DE locale was missing on my system. I did: $ sudo locale-gen de_DE Generating locales (this might take a while)... de_DE.ISO-8859-1... done Generation complete. Now I get: $ LANG=de_DE ghc-8.2.2 -e 'print System.IO.localeEncoding' ISO-8859-1 and everything works perfectly. From life.130815 at gmail.com Sun Nov 19 06:53:20 2017 From: life.130815 at gmail.com (mo jia) Date: Sun, 19 Nov 2017 14:53:20 +0800 Subject: [Haskell-cafe] implement a simple DSL meet problem with env data can't be changed Message-ID: Base on the correct compiler desc on https://github.com/pa-ba/calc-comp Here is the source code module Lambda_define ( Name, Expr, eval )where import Prelude hiding (null, lookup, map, filter) import Data.HashMap.Lazy type Name = [Char] data Expr = Val Int | Add [Expr] | Var Name | Abs Name Expr | App Expr Expr | Define Name Expr | Begin [Expr] | Let (Name, Expr) Expr data Env = Root | Env { current :: HashMap Name Value, parent :: Env } data Value = Num Int | Clo Name Expr Env envLookup :: Name -> Env -> Value envLookup n Root = Num 10000 --- fix it envLookup n env = case lookup n (current env) of Just v -> v otherwise -> envLookup n (parent env) --------------- setvar :: Name -> Value -> Env -> Env setvar n v Root = Env{current=fromList [(n, v)] , parent=Root } setvar n v Env{current=c, parent=p} = Env{current=(insert n v c), parent=p } eval :: Expr -> Env -> (Value, Env) eval (Val n) e = (Num n , e) eval (Add [x , y]) e = case eval x e of (Num n, e') -> case eval y e of (Num m, e1') -> (Num (n+m), e) eval (Add [x]) e = case eval x e of (Num n, e') -> (Clo "y" (Add [(Val n), (Var "y")]) e' , e) eval (Var n) e = (envLookup n e, e) eval (Abs n x) e = (Clo n x e, e) eval (App x y) e = case eval x e of (Clo n' x' e', env') -> case eval y e of (vy, e'') -> (fst (eval x' (Env (fromList [(n', vy)]) e')), e ) --- the saved clojure env can't be changed eval (Define n e) env = case eval e env of (v, e') -> (Num 0, setvar n v env) --- fix me why 0 eval (Let (n, e1) e2) env = ------ Let should don't chanve the env (fst (eval e2 (Env (fromList [(n, (fst (eval e1 env)))]) env)), env) eval (Begin xs) e = case length xs of 0 -> (Num 0, Root) -- never come here 1 -> case eval (xs !! 0) e of (v, e') -> (v, e') n -> case eval (Begin (take (n - 1) xs)) e of (v, e') -> eval (last xs) e' test1 = eval (Begin [(Define "z" (Val 1)), (Define "y" (Abs "x" (Add [(Var "z"), (Var "x")]))), (Define "x" (Val 7)), (Define "z" (Val 90)), (Add [(Val 5), (App (Var "y") (Val 8))])]) Root test2 = eval (Begin [(Define "z" (Val 1)), (Define "y" (Abs "x" (Add [(Var "z"), (Var "x")]))), (Define "x" (Val 7)), (Let ("z", (Val 90)) (Add [(Val 5), (App (Var "y") (Val 8))])) ]) Root In case you want to see the total program. I put it into https://github.com/jiamo/correct_compiler/blob/master/src/Lambda_define.hs Here is my problem: I want test1 return (Num 103) I want test2 return (Num 14) But now it both return (Num 14) One problem I can figure out that "the eval of Define return a new env can't change the old env" Any one have suggests? From trent.shipley at gmail.com Sun Nov 19 07:05:57 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 07:05:57 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet Message-ID: I have a vision for a spreadsheet that is programmable as a spreadsheet itself. (Excel, for example, is programmable in VBA, but VBA requires switching modes to the VBA environment and using a non-spreadsheet idiom. Excel is not self-programmable as a spreadsheet.) First there one function in a cell or array can reference other cells and arrays, including those that contain functions themselves. Second, IF(boolean,then,else) functions provide for selection. Third, the Function local scope property for a sheet in a workbook, the PARAMETER() function, and the RETURN() function allow the spreadsheet programmer to write new functions, including recursive functions. * Is a spreadsheet you can program from the spreadsheet a reasonable goal? * Has it been done? (I don't have the academic CS chops to know what keywords to use, and how search CS publications in English.) I have written a 30 page essay on Scriptsheets, but the essence boils down to the above. (If you, for some inexplicable reason, actually want the draft of the essay I'd be more than happy to share it with the understanding that you would provide feedback). I call the proposal Scriptsheets. So the plan is to take something like GNUmeric or LibreOffice Calc and graft on a primitive function sheet interpreter. It would be natural to use C++, but the astute will note that a spreadsheet basically does not rewrite cells (unless you use a circular reference), so I'd also like to use a functional language, maybe Haskel. * Would using a functional language as a basic language of the project save effort and intellectual load? In the longer term I'd like as much of the spreadsheet programmable as a spreadsheet to be written to run on the JVM. As near as I can tell near future Java and typed functional languages, include the following options: Eta, Frege, Kotlin and, Scala. Note that a spreadsheet needs to give the satisfaction of immediate results, or failing immediate results, the sensation of actively working, so if the language could be interpreted that would be a huge help. * Which combination of typed, compiled, interpreted, FOSS functional language that runs on the JVM, JAVA, Haskell, C++, C, used in that order of preference, makes the most sense for the Java compatible functional language at the top of the preference hierarchy? Note also, that I have only the equivalent of an AA degree from a CIS, not a CS, perspective, so the odds are the whole idea is vaporware, unless I can determine feasibility and desirability, then sweet talk real developers to help out. trent1967.48 at outlook.com (junk email address) See also the spreadsheet at http://orgmode.org/ it's cool. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sivanov at colimite.fr Sun Nov 19 10:40:46 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Sun, 19 Nov 2017 11:40:46 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: <87a7zitutt.fsf@colimite.fr> Hello Trent, Thus quoth trent shipley on Sun Nov 19 2017 at 08:05 (+0100): > > I have a vision for a spreadsheet that is programmable as a spreadsheet > itself. [...] > * Is a spreadsheet you can program from the spreadsheet a reasonable > goal? What kind of use cases do you imagine for your programmable spreadsheet? "Reasonable" will usually depend on your context. The idea in itself is definitely interesting, but you really should define the application context to make it clearer. > * Has it been done? > (I don't have the academic CS chops to know what keywords to use, and how > search CS publications in English.) I haven't heard of anything like that expressly, but then the functions in conventional spreadsheets are technically sufficiently powerful to express any computation. The question therefore comes back again to what your application would be: you could design your spreadsheet around it. > It would be natural to use C++, but the astute will note that a spreadsheet > basically does not rewrite cells (unless you use a circular reference), so > I'd also like to use a functional language, maybe Haskel. Since you want to write functions in cells, you are probably better off using a language with a compact syntax. Haskell is one of them, but not the only one. Using C++ looks in no way natural _to me_; "natural" will also depend on your use case ;-) > Note that a spreadsheet needs to give the satisfaction of immediate > results, or failing immediate results, the sensation of actively working, > so if the language could be interpreted that would be a huge help. Since your spreadsheet code will be heavily modularised, you could probably do some very granular (therefore fast) compilation. > Note also, that I have only the equivalent of an AA degree from a CIS, not > a CS, perspective, so the odds are the whole idea is vaporware, unless I > can determine feasibility and desirability, then sweet talk real developers > to help out. Having or not a degree is usually rather weakly (if not negatively) correlated with thinking or being capable of getting things done :-) So don't worry, go ahead and think big; there will always be people around to try and shoot down the hot-air balloons of your imagination for you. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From trent.shipley at gmail.com Sun Nov 19 11:12:52 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 11:12:52 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <87a7zitutt.fsf@colimite.fr> References: <87a7zitutt.fsf@colimite.fr> Message-ID: Middle posting follows On Sun, Nov 19, 2017 at 3:40 AM Sergiu Ivanov wrote: > Hello Trent, > > Thus quoth trent shipley on Sun Nov 19 2017 at 08:05 (+0100): > > > > I have a vision for a spreadsheet that is programmable as a spreadsheet > > itself. > [...] > > * Is a spreadsheet you can program from the spreadsheet a reasonable > > goal? > > What kind of use cases do you imagine for your programmable spreadsheet? > "Reasonable" will usually depend on your context. > > The idea in itself is definitely interesting, but you really should > define the application context to make it clearer. > I really haven't thought of specific use cases, but I have thought in general terms about what you might do with a natively programmable spreadsheet. 1. It would be an interesting exercise in itself, and if it hadn't been done before, might be worth a paper. (I submit that this is actually a real use case.) 2. It would be more elegant that the current solution to a programmable spreadsheet, which is a spreadsheet that is almost, but not quite programmable, with a helper imperative language and programming mode stuck onto the base spreadsheet. 3. You could build a programmable spreadsheet on steroids with this idea, and I have some other interesting ideas, like "virtual spreadsheets" that would allow spreadsheets to extend into n dimensions (but I digress). 4. So engineers, scientists, economists, and finance might have niche uses for a (n-dimensional) programmable spreadsheet on steroids--though I don't know in detail what those would be. 5. I am a trained social scientist (anthropology) I know it is not uncommon for social scientists to have to deal with large, multidimensional datasets, and analyze the same. A multidimensional programmable spreadsheet might help a lot with that. 6. I have heard that finance wizards often use Excel+VBA to do modeling. They might like a consistent, single language programming environment that offers more power and type safety that Excel + VBA. It would also need to be FAST if it is to be used for something like market analysis or automated trading. Finding plausible use cases is also hindered by both a version of an existing spreadsheet enabling native functions, or a more full featured Scriptsheets product both being vaporware. > > * Has it been done? > > (I don't have the academic CS chops to know what keywords to use, and how > > search CS publications in English.) > > I haven't heard of anything like that expressly, but then the functions > in conventional spreadsheets are technically sufficiently powerful to > express any computation. > > The question therefore comes back again to what your application would > be: you could design your spreadsheet around it. > > > It would be natural to use C++, but the astute will note that a > spreadsheet > > basically does not rewrite cells (unless you use a circular reference), > so > > I'd also like to use a functional language, maybe Haskel. > > Since you want to write functions in cells, you are probably better off > using a language with a compact syntax. Haskell is one of them, but not > the only one. > > Using C++ looks in no way natural _to me_; "natural" will also depend on > your use case ;-) > The main argument for C++ is that if you are "reusing" existing code from GNUmeric or LibreOffice Calc none of that is in a functional language. It will tend to be in C++ (and maybe Java for Calc). That's an unfortunate fact if you want to pilot the central idea on a FOSS spreadsheet as a proof of concept. Also, if speed is of the essence, my impression is that C++ and C come to the fore. > > Note that a spreadsheet needs to give the satisfaction of immediate > > results, or failing immediate results, the sensation of actively working, > > so if the language could be interpreted that would be a huge help. > > Since your spreadsheet code will be heavily modularised, you could > probably do some very granular (therefore fast) compilation. > > > Note also, that I have only the equivalent of an AA degree from a CIS, > not > > a CS, perspective, so the odds are the whole idea is vaporware, unless I > > can determine feasibility and desirability, then sweet talk real > developers > > to help out. > > Having or not a degree is usually rather weakly (if not negatively) > correlated with thinking or being capable of getting things done :-) So > don't worry, go ahead and think big; there will always be people around > to try and shoot down the hot-air balloons of your imagination for you. > > -- > Sergiu > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Sun Nov 19 12:04:04 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 19 Nov 2017 13:04:04 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: <4685bcfc-aab2-9c68-f815-df48d09b4d67@durchholz.org> Am 19.11.2017 um 08:05 schrieb trent shipley: > * Is a spreadsheet you can program from the spreadsheet a reasonable goal? I.e. use the same programming language for cells formulae and scripts? Yes, that's very much reasonable. > * Has it been done? Not in any mainstream spreadsheet. Which boils down to two: Excel and Open/Libre Office Calc. Excel offers VBA. Calc is actually language-agnostic and uses URLs and XML to tie things together. It currently supports BeanShell (Java-without-types, it seems), Java, JS, Python, and OO Basic. > So the plan is to take something like GNUmeric or LibreOffice Calc and > graft on a primitive function sheet interpreter. The main point is that you'd have to replace the formular language. I do not think that Calc was made for that. > It would be natural to use C++, You'd instantly kill adoption with that. Only a minimal part of the Calc user base is even remotely capable of coding formulae in C++, and even of these, a substantial fraction would be able but unwilling. > but the astute will note that a > spreadsheet basically does not rewrite cells (unless you use a circular > reference), so I'd also like to use a functional language, maybe Haskel. You don't want to inline the formulae of other cells anyway, because then the calculation will be done twice: Once to fill the referenced cell, and once as part of the referencing cell. So for reference cycles, you'll rely on whatever the spreadsheet is already doing to deal with them. > * Would using a functional language as a basic language of the project > save effort and intellectual load? That depends on whether you're talking about the implementation language or the cell/macro language. For the implementation language, you'll save the most time by using whatever you already know. Unless the project is going to last longer than, say, two years. And if you plan on getting other people to join the project, you'll want the language with the largest pool of interested and able people, which is essentially guesswork but I'd avoid, say, the VBA or PHP crowd ;-) For the user-facing language, do whatever is easy to use for a non-programmer. Haskell should work fine, but prepare to collect references to tutorials, and what does *not* work fine is performance predictions, particularly not for nonprogrammers. This probably means you need strict evaluation, which means even if it looks like Haskell it's going to be an entirely different language. > In the longer term I'd like as much of the spreadsheet programmable as a > spreadsheet to be written to run on the JVM. > As near as I can tell near future Java and typed functional languages, > include the following options: > > Eta, > Frege, > Kotlin and, > Scala. I don't know any of these well enough to make any recommendations. However, for the user-facing language, you need this: 1) As easy to learn as possible. 2) Scales well to a few thousand lines of code. The learning curve must not have bumps along that road, because with every bump, a substantial fraction of the user base will be deterred from progressing to more complicated tasks. 3) You'll need good support for large-scale programming if you want to enable "just calling" into third-party modules (which would be pretty appealing to people who use Calc for nontrivial stuff). The JVM excels at this, BTW, though if you don't use Java, a substantial fraction of Maven modules will be awkward to use. For (3), you'll need static typing. For (1) - and arguably (2) and (3) as well - you need something that is excellent at type inference. Type inference does not work well for updatable data structures, so you will want something that excels at handling immutable data. Which essentially rules out C++ or any other imperative language. The type system is a real problem. For many real-world situations you need dependent types, but these have complicated error situations so newbies will usually be unable to deal with it, which means a bump in the learning curve. I don't know of a good way to deal with that, it's just on the list of things that I routinely check if somebody asks me to take a look at his great new language :-) (Haskell people excel at bending its type system to simulate all kinds of things, and I wouldn't be surprised if nobody had tried to achieve most dependent-type benefits from Haskell's type system; however, people using such a type framework will need to know the Haskell type system and the internals of the framework to make sense of any error messages that come out of a type bug, so this is a variant of programmer's golf, not something you want for newbies and learners.) The JVM would be desirable, but typical .jar modules make heavy use of mutable data. So you need something that's alien to mutable data types but not incompatible with then; that's a relative fine line that the language design would have to strike. I'd probably use a language that allows mutables but disallows aliases to them. Clean does this via the type system, other strategies might be work. However, given that arbitrary modules from the JVM ecosystem might throw aliased updateable references left and right, all guarantees are off as soon as a computation relies on data provided from a JVM module, so maybe it's still not worth using that. (Java folks have been thinking about "value types", i.e. immutables, for a while now, but I don't see that coming any year soon.) Evalutation strategy is another issue. Non-strict has some nice properties, in particular you don't need to differentiate between an expression and its value. However, nonstrict is difficult to control performance-wise, and I still see people struggle if they see that their code is unexpectedly slow. > Note that a spreadsheet needs to give the satisfaction of immediate > results, or failing immediate results, the sensation of actively > working, so if the language could be interpreted that would be a huge help. +1 > * Which combination of typed, compiled, interpreted, FOSS functional > language that runs on the JVM, JAVA, Haskell, C++, C, used in that order > of preference, makes the most sense for the Java compatible functional > language at the top of the preference hierarchy? C++ and C aren't worth it if you plan to go for the JVM. Don't know if there's a useful JVM port of Haskell. You *can* interface with OO using XML descriptors and such, so the JVM isn't your only option. You could even use (or invent) a language that compiles to binary, with LLVM that has become a realistic option. However, plan to invest some time into understanding LLVM. > Note also, that I have only the equivalent of an AA degree from a CIS, > not a CS, perspective, so the odds are the whole idea is vaporware, > unless I can determine feasibility and desirability, I suspect that no existing language fits the bill. Given your background, you'll need somebody with language design experience; language design is hard because of so many conflicting goals. > then sweet talk > real developers to help out. That's a good plan :-) From trent.shipley at gmail.com Sun Nov 19 15:41:28 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 15:41:28 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: ASCII examples (view in monospaced font): NormalSheet ------------------------- | A | B | ------------------------- 1 | 1 | | ------------------------- 2 | 2 | | -------------------------- 3 | 3 | | -------------------------- 4 | 4 | | ------------------------- 5 | =SUM(A1:A4) | | (answer is 10) ------------------------- 6 | =myFunction(A5) | | ------------------------- ================================== A new sheet ================================== myFunction (it has the "function sheet" property) ---------------------------- | A | B | ---------------------------- 1 | =PARAMETER(double) | | ---------------------------- 2 | = A1 * A1 | | ---------------------------- 3 | =RETURN(A2) | | ---------------------------- Copy to CSV NormalSheet 1 2 3 4 5 =SUM(A1:A5) =MY_FUNCTION(A6) Copy second sheet to CSV MY_FUNCTION (a function sheet) =PARAMETER(double) =A1*A1 =RETURN(A3) On Sun, Nov 19, 2017 at 12:05 AM trent shipley wrote: > I have a vision for a spreadsheet that is programmable as a spreadsheet > itself. (Excel, for example, is programmable in VBA, but VBA requires > switching modes to the VBA environment and using a non-spreadsheet idiom. > Excel is not self-programmable as a spreadsheet.) > > First there one function in a cell or array can reference other cells and > arrays, including those that contain functions themselves. Second, > IF(boolean,then,else) functions provide for selection. > > Third, the Function local scope property for a sheet in a workbook, the > PARAMETER() function, and the RETURN() function allow the spreadsheet > programmer to write new functions, including recursive functions. > > * Is a spreadsheet you can program from the spreadsheet a reasonable goal? > * Has it been done? > (I don't have the academic CS chops to know what keywords to use, and how > search CS publications in English.) > > I have written a 30 page essay on Scriptsheets, but the essence boils down > to the above. (If you, for some inexplicable reason, actually want the > draft of the essay I'd be more than happy to share it with the > understanding that you would provide feedback). I call the proposal > Scriptsheets. > > So the plan is to take something like GNUmeric or LibreOffice Calc and > graft on a primitive function sheet interpreter. > > It would be natural to use C++, but the astute will note that a > spreadsheet basically does not rewrite cells (unless you use a circular > reference), so I'd also like to use a functional language, maybe Haskel. > > * Would using a functional language as a basic language of the project > save effort and intellectual load? > > In the longer term I'd like as much of the spreadsheet programmable as a > spreadsheet to be written to run on the JVM. > > As near as I can tell near future Java and typed functional languages, > include the following options: > > Eta, > Frege, > Kotlin and, > Scala. > > Note that a spreadsheet needs to give the satisfaction of immediate > results, or failing immediate results, the sensation of actively working, > so if the language could be interpreted that would be a huge help. > > * Which combination of typed, compiled, interpreted, FOSS functional > language that runs on the JVM, JAVA, Haskell, C++, C, used in that order of > preference, makes the most sense for the Java compatible functional > language at the top of the preference hierarchy? > > Note also, that I have only the equivalent of an AA degree from a CIS, not > a CS, perspective, so the odds are the whole idea is vaporware, unless I > can determine feasibility and desirability, then sweet talk real developers > to help out. > > trent1967.48 at outlook.com (junk email address) > > See also the spreadsheet at http://orgmode.org/ it's cool. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trent.shipley at gmail.com Sun Nov 19 16:29:48 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 16:29:48 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <4685bcfc-aab2-9c68-f815-df48d09b4d67@durchholz.org> References: <4685bcfc-aab2-9c68-f815-df48d09b4d67@durchholz.org> Message-ID: Middle posting follows: First there are a few things going on. There is the language or languages used by the developers of the spreadsheet product. There is the language of the spreadsheet itself. There are the programming languages used by the developers of the spreadsheet (say accounting power users), like VBA. Case A: So for Excel: Implementation Language: MS C++ (my guess), Spreadsheet Language: Excel, Built-in Language VBA. (Excel HAS a programming language and tool.) Case B: For Emacs OrgMode spreadsheets (a weird little spreadsheet in a tool whose main purpose is hardly being a spreadsheet.) (See http://orgmode.org/manual/The-spreadsheet.html#The-spreadsheet ) Imlementation Language: Emacs Lisp (my guess), Spreadsheet languages: Emacs Calc, and Emacs Lisp, Built-in Language: I'm not sure it has one. Given the fact that you can write ELisp in the cells, it may not need one. However, it also doesn't look like a full-blown 3d spreadsheet. Case C: For the proposed Scriptsheets product: Implementation Languages: Frege (?), Java, Haskell, C++, C, in that order. Spreadsheet languages: Scriptsheets, Bulit-in language: Scriptsheets. (Scriptsheets IS a programming language and tool.) Note that a spreadsheet product can have programming languages, it can be a programming language, and it can interpret (or very quickly compile) programming statements in a language such as ELisp or Haskell within the cells of the spreadsheet itself. The features are not mutually exclusive. I meant to imply that I was interested in Case C, and I believe Joachim understood me to be interested in Case B (but not Emacs OrgMode as a specific example of Case B). Middle posting follows. On Sun, Nov 19, 2017 at 5:07 AM Joachim Durchholz wrote: > Am 19.11.2017 um 08:05 schrieb trent shipley: > > * Is a spreadsheet you can program from the spreadsheet a reasonable > goal? > > I.e. use the same programming language for cells formulae and scripts? > Yes, that's very much reasonable. > That is possible. However, I am interested in programming scripts in spreadsheet, not say, programming formula in Haskell. > > > * Has it been done? > > Not in any mainstream spreadsheet. Which boils down to two: Excel and > Open/Libre Office Calc. > Excel offers VBA. > Calc is actually language-agnostic and uses URLs and XML to tie things > together. It currently supports BeanShell (Java-without-types, it > seems), Java, JS, Python, and OO Basic. > > > So the plan is to take something like GNUmeric or LibreOffice Calc and > > graft on a primitive function sheet interpreter. > > The main point is that you'd have to replace the formular language. > I do not think that Calc was made for that. > > > It would be natural to use C++, > > You'd instantly kill adoption with that. Only a minimal part of the Calc > user base is even remotely capable of coding formulae in C++, and even > of these, a substantial fraction would be able but unwilling. > Agreed. I was not thinking of programming cells in C++. I was thinking of moving Scriptsheets from vaporware to proof of concept and beyond using C++ by the PROJECT developers (in large measure to appropriate existing FOSS code). > > but the astute will note that a > > spreadsheet basically does not rewrite cells (unless you use a circular > > reference), so I'd also like to use a functional language, maybe Haskel. > > You don't want to inline the formulae of other cells anyway, because > then the calculation will be done twice: Once to fill the referenced > cell, and once as part of the referencing cell. > > So for reference cycles, you'll rely on whatever the spreadsheet is > already doing to deal with them. > Exactly, at least until your forked product goes from, say, version 1.0 to version 2.0. > > * Would using a functional language as a basic language of the project > > save effort and intellectual load? > > That depends on whether you're talking about the implementation language > or the cell/macro language. > I was talking about implementation language. > For the implementation language, you'll save the most time by using > whatever you already know. Unless the project is going to last longer > than, say, two years. And if you plan on getting other people to join > the project, you'll want the language with the largest pool of > interested and able people, which is essentially guesswork but I'd > avoid, say, the VBA or PHP crowd ;-) > Would there be any advantage over preferring a functional over an imperative language given that Scriptsheets (as a full blown product) would itself be a functional language. > For the user-facing language, do whatever is easy to use for a > non-programmer. Haskell should work fine, but prepare to collect > references to tutorials, and what does *not* work fine is performance > predictions, particularly not for nonprogrammers. This probably means > you need strict evaluation, which means even if it looks like Haskell > it's going to be an entirely different language. > > > In the longer term I'd like as much of the spreadsheet programmable as a > > spreadsheet to be written to run on the JVM. > > As near as I can tell near future Java and typed functional languages, > > include the following options: > > > > Eta, > > Frege, > > Kotlin and, > > Scala. > > I don't know any of these well enough to make any recommendations. > > However, for the user-facing language, you need this: > 1) As easy to learn as possible. > 2) Scales well to a few thousand lines of code. The learning curve must > not have bumps along that road, because with every bump, a substantial > fraction of the user base will be deterred from progressing to more > complicated tasks. > 3) You'll need good support for large-scale programming if you want to > enable "just calling" into third-party modules (which would be pretty > appealing to people who use Calc for nontrivial stuff). The JVM excels > at this, BTW, though if you don't use Java, a substantial fraction of > Maven modules will be awkward to use. > > For (3), you'll need static typing. > For (1) - and arguably (2) and (3) as well - you need something that is > excellent at type inference. > > Type inference does not work well for updatable data structures, so you > will want something that excels at handling immutable data. Which > essentially rules out C++ or any other imperative language. > The type system is a real problem. For many real-world situations you > need dependent types, but these have complicated error situations so > newbies will usually be unable to deal with it, which means a bump in > the learning curve. I don't know of a good way to deal with that, it's > just on the list of things that I routinely check if somebody asks me to > take a look at his great new language :-) (Haskell people excel at > bending its type system to simulate all kinds of things, and I wouldn't > be surprised if nobody had tried to achieve most dependent-type benefits > from Haskell's type system; however, people using such a type framework > will need to know the Haskell type system and the internals of the > framework to make sense of any error messages that come out of a type > bug, so this is a variant of programmer's golf, not something you want > for newbies and learners.) > > The JVM would be desirable, but typical .jar modules make heavy use of > mutable data. So you need something that's alien to mutable data types > but not incompatible with then; that's a relative fine line that the > language design would have to strike. > I'd probably use a language that allows mutables but disallows aliases > to them. Clean does this via the type system, other strategies might be > work. However, given that arbitrary modules from the JVM ecosystem might > throw aliased updateable references left and right, all guarantees are > off as soon as a computation relies on data provided from a JVM module, > so maybe it's still not worth using that. (Java folks have been thinking > about "value types", i.e. immutables, for a while now, but I don't see > that coming any year soon.) > > Evalutation strategy is another issue. > Non-strict has some nice properties, in particular you don't need to > differentiate between an expression and its value. However, nonstrict is > difficult to control performance-wise, and I still see people struggle > if they see that their code is unexpectedly slow. > > > Note that a spreadsheet needs to give the satisfaction of immediate > > results, or failing immediate results, the sensation of actively > > working, so if the language could be interpreted that would be a huge > help. > > +1 > > > * Which combination of typed, compiled, interpreted, FOSS functional > > language that runs on the JVM, JAVA, Haskell, C++, C, used in that order > > of preference, makes the most sense for the Java compatible functional > > language at the top of the preference hierarchy? > > C++ and C aren't worth it if you plan to go for the JVM. > Don't know if there's a useful JVM port of Haskell. > > I know Hadoop in in Java, except where speed is of essence, then Hadoop uses C++ or sometimes C. I figure the same would be true for this project. For Haskell on JVM see Eta and Frege. Frege is the older project. Neither seem to be particularly mature. > You *can* interface with OO using XML descriptors and such, so the JVM > isn't your only option. You could even use (or invent) a language that > compiles to binary, with LLVM that has become a realistic option. > However, plan to invest some time into understanding LLVM. > > > > Note also, that I have only the equivalent of an AA degree from a CIS, > > not a CS, perspective, so the odds are the whole idea is vaporware, > > unless I can determine feasibility and desirability, > > I suspect that no existing language fits the bill. > Given your background, you'll need somebody with language design > experience; language design is hard because of so many conflicting goals. > > > then sweet talk > > real developers to help out. > > That's a good plan :-) > Do you know any gullible developers with the chops? Which do you see as more promising a real GUI spreadsheet for Case B or one for Case C? Or would it make sense to be ambitious and try to do both in the same project using a common spreadsheet core backend and largely shared front end? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jgbm at acm.org Sun Nov 19 18:31:28 2017 From: jgbm at acm.org (J. Garrett Morris) Date: Sun, 19 Nov 2017 12:31:28 -0600 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: On Sun, Nov 19, 2017 at 9:41 AM, trent shipley wrote: > ================================== > A new sheet > ================================== > > myFunction (it has the "function sheet" property) > ---------------------------- > | A | B | > ---------------------------- > 1 | =PARAMETER(double) | | > ---------------------------- > 2 | = A1 * A1 | | > ---------------------------- > 3 | =RETURN(A2) | | > ---------------------------- You might find Simon PJ's classic paper on Excel as a functional language relevant: https://www.microsoft.com/en-us/research/publication/a-user-centred-approach-to-functions-in-excel/ /g From jo at durchholz.org Sun Nov 19 19:31:03 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 19 Nov 2017 20:31:03 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <4685bcfc-aab2-9c68-f815-df48d09b4d67@durchholz.org> Message-ID: <2e372b75-23fd-0d70-1e19-c46aa6fd2b27@durchholz.org> > There is the language or languages used by the developers of the > spreadsheet product. There is the language of the spreadsheet itself. Not sure what you mean with "language of the spreadsheet iself". The formula language? > There are the programming languages used by the developers of the > spreadsheet (say accounting power users), like VBA. > Note that a spreadsheet product can have programming languages, it can > be a programming language, A spreadsheet is not a programming language, so you must be meaning something different, but I have no idea what. > On Sun, Nov 19, 2017 at 5:07 AM Joachim Durchholz > wrote: > > Am 19.11.2017 um 08:05 schrieb trent shipley: > > * Is a spreadsheet you can program from the spreadsheet a > reasonable goal? > > I.e. use the same programming language for cells formulae and scripts? > Yes, that's very much reasonable. > > > That is possible. > > However, I am interested in programming scripts in spreadsheet, not say, > programming formula in Haskell. I have no idea what your plan is, then. > > * Would using a functional language as a basic language of the > project > > save effort and intellectual load? > > That depends on whether you're talking about the implementation language > or the cell/macro language. > > I was talking about implementation language. If you plan to create a new spreadsheet program, that's a huge project. Even if you stick to cells and formulae and skip everything on the presentation side. > For the implementation language, you'll save the most time by using > whatever you already know. Unless the project is going to last longer > than, say, two years. And if you plan on getting other people to join > the project, you'll want the language with the largest pool of > interested and able people, which is essentially guesswork but I'd > avoid, say, the VBA or PHP crowd ;-) > > Would there be any advantage over preferring a functional over an > imperative language given that Scriptsheets (as a full blown product) > would itself be a functional language. The choice of the programming language for building a new product is pretty independent of the product itself. This is because the logic that you see (cell calculations) is just a very small part of the overall code. For a new spreadsheet program, look for a language that has a good GUI library, for example, that's going to be a much larger timesaver than language semantics that matches the application domain. > I know Hadoop in in Java, except where speed is of essence, then Hadoop > uses C++ or sometimes C. I figure the same would be true for this project. Only once the project has seen several person-decades of work. >  > then sweet talk > > real developers to help out. > > That's a good plan :-) > > > Do you know any gullible developers with the chops? Actually I'd be interested in something like this if I didn't have my own project ;-P > Which do you see as more promising a real GUI spreadsheet for Case B or > one for Case C? Or would it make sense to be ambitious and try to do > both in the same project using a common spreadsheet core backend and > largely shared front end? I haven't really understood what you're trying to do, so I can'd advise. Regards, Jo From S.J.Thompson at kent.ac.uk Sun Nov 19 20:18:02 2017 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Sun, 19 Nov 2017 20:18:02 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: Trent, You might be interested in this article on Interactive Visual Functional Programming, from Keith Hanna (formerly of University of Kent), from ICFP 2002 https://dl.acm.org/citation.cfm?id=581493 Abstract: An interactive graphical environment for supporting the development and use of Haskell applications programs is described. The environment, named Vital, is particularly intended for supporting the open-ended, incremental development style often preferred by non-specialist users in which successive steps of program development are motivated and informed by results so far obtained.Significant features of Vital include: the graphical display of data structures in a format defined by a datatype-indexed stylesheet, the way that evaluation of (possibly infinite) values is demand-driven by the action of the user scrolling around an unbounded workspace, and support for copy-and-paste graphical editing of data structures. This latter allows, for example, the user to modify a complex data structure by point-and-click operations, or to create (by functional evaluation) a regular data structure and then edit values or expressions into it. The effect of each editing operation is immediately reflected in the Haskell program source code. Simon > On 19 Nov 2017, at 07:05, trent shipley wrote: > > I have a vision for a spreadsheet that is programmable as a spreadsheet itself. (Excel, for example, is programmable in VBA, but VBA requires switching modes to the VBA environment and using a non-spreadsheet idiom. Excel is not self-programmable as a spreadsheet.) > > First there one function in a cell or array can reference other cells and arrays, including those that contain functions themselves. Second, IF(boolean,then,else) functions provide for selection. > > Third, the Function local scope property for a sheet in a workbook, the PARAMETER() function, and the RETURN() function allow the spreadsheet programmer to write new functions, including recursive functions. > > * Is a spreadsheet you can program from the spreadsheet a reasonable goal? > * Has it been done? > (I don't have the academic CS chops to know what keywords to use, and how search CS publications in English.) > > I have written a 30 page essay on Scriptsheets, but the essence boils down to the above. (If you, for some inexplicable reason, actually want the draft of the essay I'd be more than happy to share it with the understanding that you would provide feedback). I call the proposal Scriptsheets. > > So the plan is to take something like GNUmeric or LibreOffice Calc and graft on a primitive function sheet interpreter. > > It would be natural to use C++, but the astute will note that a spreadsheet basically does not rewrite cells (unless you use a circular reference), so I'd also like to use a functional language, maybe Haskel. > > * Would using a functional language as a basic language of the project save effort and intellectual load? > > In the longer term I'd like as much of the spreadsheet programmable as a spreadsheet to be written to run on the JVM. > > As near as I can tell near future Java and typed functional languages, include the following options: > > Eta, > Frege, > Kotlin and, > Scala. > > Note that a spreadsheet needs to give the satisfaction of immediate results, or failing immediate results, the sensation of actively working, so if the language could be interpreted that would be a huge help. > > * Which combination of typed, compiled, interpreted, FOSS functional language that runs on the JVM, JAVA, Haskell, C++, C, used in that order of preference, makes the most sense for the Java compatible functional language at the top of the preference hierarchy? > > Note also, that I have only the equivalent of an AA degree from a CIS, not a CS, perspective, so the odds are the whole idea is vaporware, unless I can determine feasibility and desirability, then sweet talk real developers to help out. > > trent1967.48 at outlook.com (junk email address) > > See also the spreadsheet at http://orgmode.org/ it's cool. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Sun Nov 19 20:39:35 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 19 Nov 2017 21:39:35 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet Message-ID: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Hello Trent, let me suggest to step back and think about why people use spreadsheets. They provide access to data analysis functions, statistics and graphing that is otherwise missing (at least on) Windows systems. Serious number crunching is not done in spreadsheets, though. There is R, Matlab and the like. You should not try to comptete with that. The big selling point (in my eyes) of spreadsheets over scripting languages like R is that the data as well as the formulae and intermediate results are, well, spread out in front of your eyes. That is e.g. desirable when you need someone else to understand what you did and how you arrived at the answer given. But is it important that the intermediate result resides in cells C2 to C13? Certainly not. I wrote a small financial application in Haskell that would otherwise be done in spreadsheets. Haskell provided, via its type system, extra sanity checks and much more that spreadsheets don't provide. However, I often wished that there was a way to disassemble the computation into logical bits that can be formatted neatly and be presented to a human inspector. Haskell provides ways to do this, e.g. by mixing Haskell and LaTeX, or writing a small DSL with two interpreters, one for calculations, one for layout. So instead of enhancing a spreadsheet format I'd rather have a scripting language with a workbook file format à la Mathematica, where comments, code and results of computations are displayed together. Changing a formula triggers change in the results. (The workbooks I've seen don't do that.) Input data and intermediate results can be hidden or expanded via mouse click. Results can be traced back through the workbook's formulae up to the input data. (The latter is not always easy in spreadsheets.) One would need to research whether such a language exists. If not, I'd be happy to help develop it. Olaf From trent.shipley at gmail.com Sun Nov 19 21:50:44 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 21:50:44 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> References: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Message-ID: Hi Olaf, I must say you haven't convinced me that there is no use for a spreadsheet functional language. Nor have you convinced that important, mission critical work is not done in spreadsheets. However, what you want certainly seems worthwhile. Where can I see an example of what Mathematica does. It costs the Earth, and I've never played with it. For simplicity I will assume serial code, not parallel. Code is linear in almost all programming models. Code flows left to right and down the page (screen, at least in English). So what I imagine you want is something like a persistent code tracer, that by default reruns the code as changes are made. | Input | Code | Result | Comment | LaTeX | Etc | Many Possible Columns ---------------------------------------------------------------------------- 0001 | input1 | expression1 | result1 | comment1 | formula1 | etc1 | ----------------------------------------------------------------------- And so on to the end of the program. Like so? A tabular view of the program and it's execution. You can program in the table. The table auto-updates when you change stuff. Works best with LOTS of screen real estate. That would be kinda cool. You might want to refine your idea and start another thread about that. It's cool, but it's not a functional spreadsheet like in https://www.microsoft.com/en-us/research/publication/a-user-centred-approach-to-functions-in-excel/ and some of the article's citations, which is very much what I'm talking about. It looks like I could have plagiarized most of my ideas from that article, even though I've never read it before. (I was aware of comparisons of spreadsheets to functional programming before.) On Sun, Nov 19, 2017 at 1:39 PM Olaf Klinke wrote: > Hello Trent, > > let me suggest to step back and think about why people use spreadsheets. > They provide access to data analysis functions, statistics and graphing > that is otherwise missing (at least on) Windows systems. Serious number > crunching is not done in spreadsheets, though. There is R, Matlab and the > like. You should not try to comptete with that. The big selling point (in > my eyes) of spreadsheets over scripting languages like R is that the data > as well as the formulae and intermediate results are, well, spread out in > front of your eyes. That is e.g. desirable when you need someone else to > understand what you did and how you arrived at the answer given. But is it > important that the intermediate result resides in cells C2 to C13? > Certainly not. > I wrote a small financial application in Haskell that would otherwise be > done in spreadsheets. Haskell provided, via its type system, extra sanity > checks and much more that spreadsheets don't provide. However, I often > wished that there was a way to disassemble the computation into logical > bits that can be formatted neatly and be presented to a human inspector. > Haskell provides ways to do this, e.g. by mixing Haskell and LaTeX, or > writing a small DSL with two interpreters, one for calculations, one for > layout. > So instead of enhancing a spreadsheet format I'd rather have a scripting > language with a workbook file format à la Mathematica, where comments, code > and results of computations are displayed together. Changing a formula > triggers change in the results. (The workbooks I've seen don't do that.) > Input data and intermediate results can be hidden or expanded via mouse > click. Results can be traced back through the workbook's formulae up to the > input data. (The latter is not always easy in spreadsheets.) One would need > to research whether such a language exists. If not, I'd be happy to help > develop it. > > Olaf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Nov 19 23:38:42 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 19 Nov 2017 18:38:42 -0500 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Message-ID: On Sun, Nov 19, 2017 at 4:50 PM, trent shipley wrote: > I must say you haven't convinced me that there is no use for a spreadsheet > functional language. Nor have you convinced that important, mission > critical work is not done in spreadsheets. > I am pretty sure you're talking past each other at this point. Step back and take a deep breath, both of 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 trent.shipley at gmail.com Sun Nov 19 23:51:34 2017 From: trent.shipley at gmail.com (trent shipley) Date: Sun, 19 Nov 2017 23:51:34 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Message-ID: Hi Brandon, Olaf, I did not mean to be a jerk. I think Olaf has an itch and a good idea of how to scratch it, and it could be the basis for a great project. I've never used Mathematica, so I have a hard time visualizing what he is driving at. My apologies if I was inappropriate. It is reasonable to ask whether there would be a reasonable user base for a functional programming language/spreadsheet. My intuition is that there would be among more advanced spreadsheet users. So that is obviously a point of disagreement, but that is OK. We should probably debate that. I also think he is talking about a different thing than I am, and what this thread has been apart thus far. It is a Bad Thing (in the Winnie the Pooh sense) when threads turn into fibers. I think Olaf's idea/itch is actually quite good, and deserves a thread of its own. With apologies, Trent. On Sun, Nov 19, 2017 at 4:38 PM Brandon Allbery wrote: > On Sun, Nov 19, 2017 at 4:50 PM, trent shipley > wrote: > >> I must say you haven't convinced me that there is no use for a >> spreadsheet functional language. Nor have you convinced that important, >> mission critical work is not done in spreadsheets. >> > > I am pretty sure you're talking past each other at this point. Step back > and take a deep breath, both of 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 olopierpa at gmail.com Mon Nov 20 00:12:57 2017 From: olopierpa at gmail.com (Pierpaolo Bernardi) Date: Mon, 20 Nov 2017 01:12:57 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Message-ID: People interested in implementing spreadsheets could give a look at "Spreadsheet Implementation Technology: Basics and Extensions", Peter Sestoft, MIT Press. It's the only book on the topic, as far as I know, and it's an interesting reading (even if they use C#, but we can't have everything). From dominic at steinitz.org Mon Nov 20 10:45:22 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Mon, 20 Nov 2017 10:45:22 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: Message-ID: <251D9922-FBB9-46E1-948E-0ACE968419CD@steinitz.org> Here’s a presentation about a functional language embedded in Excel which I used when I worked at an investment bank https://www.youtube.com/watch?v=uICBMTeIl2U http://cufp.org/2009/fmd-functional-development-excel.html As far as I know the code is still in use (I recall there was something like 400 users in the bank) and was never open-sourced but it may provide some ideas given it was pretty successful internally. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From sivanov at colimite.fr Mon Nov 20 14:23:02 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Mon, 20 Nov 2017 15:23:02 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> Message-ID: <871sktt4ft.fsf@colimite.fr> Hello Trent, Thus quoth trent shipley on Sun Nov 19 2017 at 12:12 (+0100): > On Sun, Nov 19, 2017 at 3:40 AM Sergiu Ivanov wrote: >> Thus quoth trent shipley on Sun Nov 19 2017 at 08:05 (+0100): >> > >> > I have a vision for a spreadsheet that is programmable as a spreadsheet >> > itself. >> [...] >> > * Is a spreadsheet you can program from the spreadsheet a reasonable >> > goal? >> >> What kind of use cases do you imagine for your programmable spreadsheet? >> "Reasonable" will usually depend on your context. > > I really haven't thought of specific use cases, but I have thought in > general terms about what you might do with a natively programmable > spreadsheet. > > 1. It would be an interesting exercise in itself, and if it hadn't been > done before, might be worth a paper. (I submit that this is actually a real > use case.) That's a good and a fun use case, but it's probably not going to attract a lot of developers/maintainers. > 2. It would be more elegant that the current solution to a programmable > spreadsheet, which is a spreadsheet that is almost, but not quite > programmable, with a helper imperative language and programming mode stuck > onto the base spreadsheet. Well, as Olaf points out in another thread (I think), the fact that conventional spreadsheets are not completely programmable is also an advantage: you know what your spreadsheet _cannot_ do, which helps with debugging. I do admit that's not an argument against programmable spreadsheets, though. > 3. You could build a programmable spreadsheet on steroids with this > idea, and I have some other interesting ideas, like "virtual spreadsheets" > that would allow spreadsheets to extend into n dimensions (but I digress). > 4. So engineers, scientists, economists, and finance might have niche > uses for a (n-dimensional) programmable spreadsheet on steroids--though I > don't know in detail what those would be. > 5. I am a trained social scientist (anthropology) I know it is not > uncommon for social scientists to have to deal with large, multidimensional > datasets, and analyze the same. A multidimensional programmable spreadsheet > might help a lot with that. Multidimensionality seems to be a really important point in your project. On the other hand, without having any specialised knowledge in spreadsheet-crunching, I'm tempted to suppose that what these scientist need is quite below Turing completeness, once multidimensionality is provided. Do you think a semi-programmable (as in LibreOffice) multidimensional spreadsheet may cut it for them? > 6. I have heard that finance wizards often use Excel+VBA to do modeling. > They might like a consistent, single language programming environment that > offers more power and type safety that Excel + VBA. It would also need to > be FAST if it is to be used for something like market analysis or automated > trading. Your argument is probably based on way more experience than mine, but personally I don't at all aspire to have a homogeneous language environment. I actually like the separation in Excel: formulas for almost any operations; VBA when real muscle-power is inevitable. That was my two-cent addition to the brainstorming :-) > Finding plausible use cases is also hindered by both a version of an > existing spreadsheet enabling native functions, or a more full featured > Scriptsheets product both being vaporware. Not necessarily, as you showed in the message I am replying to :-) My reasoning behind suggesting to consider potential applications is that the abstract model you are mulling over is very general and can be implemented in various quite different ways—e.g., LibreOffice, Scilab, and the R language all focus on matrix processing (more or less), but they are so different that people seem to agree they are not really directly comparable, and thus not conflicting. Now, I may be mistaken and you may have a very clear idea of an implementation, in which case my suggestions are simply redundant. >> > It would be natural to use C++ >> >> Using C++ looks in no way natural _to me_; "natural" will also depend on >> your use case ;-) >> > > The main argument for C++ is that if you are "reusing" existing code from > GNUmeric or LibreOffice Calc none of that is in a functional language. It > will tend to be in C++ (and maybe Java for Calc). Are you talking about the language for spreadsheet programming or about the implementation language for your project? If we are in the former case, the implementation language need not necessarily be the same as the language of the spreadsheet, like in the HotSpot JVM which seems to be written in C++ [0] even though it runs tons of other languages or Excel itself, which I doubt is written in VBA. > Also, if speed is of the essence, my impression is that C++ and C come to > the fore. Yes, but overoptimisation along one criterion among many is also an issue. The trade-off between faster code or code easier to maintain is a difficult one. But then you're are right, C++ and C are often quite in the lead in what concerns speed (even though some tweaks may bring other programming languages quite close [1]). -- Sergiu [0] https://en.wikipedia.org/wiki/HotSpot [1] http://paulspontifications.blogspot.fr/2013/01/when-haskell-is-faster-than-c.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From guthrie at mum.edu Mon Nov 20 17:13:31 2017 From: guthrie at mum.edu (Gregory Guthrie) Date: Mon, 20 Nov 2017 11:13:31 -0600 Subject: [Haskell-cafe] argument counts... Message-ID: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> I have a simple function: revFn (x:xs) = (revFn xs) . (x:) Of course GHCi correctly infers the type as: revFn :: [a] -> [a] -> c Adding the base case: revFn [] xs = xs Now gives an error; "Equations for 'revF' have different numbers of arguments" Of course this can be "fixed" by either adding the cancelled argument to the first clause, or converting the base case to only have one explicit argument, and a RHS of a lambda or identity function. But since the interpreter already correctly inferred that the first clause has two arguments (with only one explicit), why does it then ignore this and give an error when the second clause shows two explicit arguments? The types are all correct in either case - why require explicit arguments? Or, perhaps I am missing something simple? -------------- next part -------------- An HTML attachment was scrubbed... URL: From zemyla at gmail.com Mon Nov 20 18:00:17 2017 From: zemyla at gmail.com (Zemyla) Date: Mon, 20 Nov 2017 12:00:17 -0600 Subject: [Haskell-cafe] argument counts... In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> Message-ID: You need to turn the second case into a lambda: revFn [] = \xs -> xs Or more succinctly, revFn [] = id On Mon, Nov 20, 2017 at 11:13 AM, Gregory Guthrie wrote: > I have a simple function: > > revFn (x:xs) = (revFn xs) . (x:) > > > > Of course GHCi correctly infers the type as: revFn :: [a] -> [a] -> c > > > > Adding the base case: > > revFn [] xs = xs > > > > Now gives an error; > > “Equations for ‘revF’ have different numbers of arguments” > > > > Of course this can be “fixed” by either adding the cancelled argument to the > first clause, or converting the base case to only have one explicit > argument, and a RHS of a lambda or identity function. > > > > But since the interpreter already correctly inferred that the first clause > has two arguments (with only one explicit), why does it then ignore this and > give an error when the second clause shows two explicit arguments? The types > are all correct in either case – why require explicit arguments? > > > > Or, perhaps I am missing something simple? > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 neil_mayhew at users.sourceforge.net Mon Nov 20 18:16:27 2017 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Mon, 20 Nov 2017 11:16:27 -0700 Subject: [Haskell-cafe] argument counts... In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> Message-ID: <0af1a8d1-5047-c350-7ea8-b0003b03f4dd@users.sourceforge.net> On 2017-11-20 10:13 AM, Gregory Guthrie wrote: > > But since the interpreter already correctly inferred that the first > clause has two arguments (with only one explicit), why does it then > ignore this and give an error when the second clause shows two > explicit arguments? The types are all correct in either case – why > require explicit arguments? > Actually, the first clause doesn't have two arguments. It's a single-argument function that returns a one-argument function. Strictly speaking, all multi-argument functions are one-argument functions that return other functions, but the compiler makes a distinction, perhaps to help guard against mistakes. So it's a requirement that all clauses of a function definition have the same number of explicit arguments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil_mayhew at users.sourceforge.net Mon Nov 20 19:09:09 2017 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Mon, 20 Nov 2017 12:09:09 -0700 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> References: <7E02AEFD-EDF8-4271-9DAA-6B9A88E48E70@aatal-apotheke.de> Message-ID: On 2017-11-19 01:39 PM, Olaf Klinke wrote: So instead of enhancing a spreadsheet format I’d rather have a scripting language with a workbook file format à la Mathematica, where comments, code and results of computations are displayed together. Changing a formula triggers change in the results. (The workbooks I’ve seen don’t do that.) Input data and intermediate results can be hidden or expanded via mouse click. Results can be traced back through the workbook’s formulae up to the input data. (The latter is not always easy in spreadsheets.) Olaf, have you looked at Jupyter at all? This now has a backend for Haskell and supports many of the things you mention. ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjenvanweelden at gmail.com Mon Nov 20 19:42:07 2017 From: arjenvanweelden at gmail.com (Arjen) Date: Mon, 20 Nov 2017 20:42:07 +0100 Subject: [Haskell-cafe] argument counts... In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> Message-ID: <1511206927.3717.4.camel@gmail.com> On Mon, 2017-11-20 at 11:13 -0600, Gregory Guthrie wrote: > I have a simple function: >        revFn (x:xs) = (revFn xs) . (x:) >   > Of course GHCi correctly infers the type as:   revFn :: [a] -> [a] -> > c >   > Adding the base case: >     revFn [] xs = xs >   > Now gives an error; >   “Equations for ‘revF’ have different numbers of arguments” >   > Of course this can be “fixed” by either adding the cancelled argument > to the first clause, or converting the base case to only have one > explicit argument, and a RHS of a lambda or identity function. >   > But since the interpreter already correctly inferred that the first > clause has two arguments (with only one explicit), why does it then > ignore this and give an error when the second clause shows two > explicit arguments? The types are all correct in either case – why > require explicit arguments? >   > Or, perhaps I am missing something simple? > The semantics are based on Term Rewriting Systems. The number of arguments determines when the left side gets rewritten (evaluated) to the right side. This makes a difference in time and space properties. I think that is why Haskell (GHC) makes it explicit, and requires all parts of the function definition to have the same number of arguments. hope this helps, Arjen From trebla at vex.net Mon Nov 20 21:04:29 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 20 Nov 2017 16:04:29 -0500 Subject: [Haskell-cafe] argument counts... In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA0678889B2B49@MAIL.cs.mum.edu> Message-ID: On 2017-11-20 12:13 PM, Gregory Guthrie wrote: > I have a simple function: > >        revFn (x:xs) = (revFn xs) . (x:) [...] > >     revFn [] xs = xs > > Now gives an error; > >   “Equations for ‘revF’ have different numbers of arguments” Please see Haskell 2010 section 4.4.3.1 "Function bindings" and look for "and the number of patterns in each clause must be the same". From seanmatthews1 at gmail.com Mon Nov 20 22:05:31 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Mon, 20 Nov 2017 23:05:31 +0100 Subject: [Haskell-cafe] Questions about Numeric.AD / Automatic differentiation Message-ID: I'm having some problems with Numeric.AD (translation, things are not working for reason that I don't understand). Note I don't have much experience with this package, so these are newbie questions, thus appropriate answers may involve pointing me to a document somewhere out there on the net. Anyway, here is my problem: I have a function (call it f x theta) which I have defined purely in terms of basic arithmetic functions (+/-/(/)/*/**) glued together using standard applicative functor operations has type f :: m1 (m2 Double) -> m3 Double -> Double f x theta = ... m1 m2 and m3 are all Traversable. f is defined purely in terms of basic arithmetic operations, (+/-/(/)/*/**) glued together using standard applicative functor operations, and m1 m2 and m3 are all pretty trivial record types (no recursion, even). I would like to write df x theta = grad (f x) theta But it refuses to type, even though (admittedly quite a lot) simpler versions do. So what am I missing? Does AD not go through Applicative? That seems unlikely to me. Any advice / suggestions, etc. gratefully received. Sean Matthews -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trent.shipley at gmail.com Tue Nov 21 02:52:07 2017 From: trent.shipley at gmail.com (trent shipley) Date: Tue, 21 Nov 2017 02:52:07 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <871sktt4ft.fsf@colimite.fr> References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> Message-ID: Middle posting follows. On Mon, Nov 20, 2017 at 7:23 AM Sergiu Ivanov wrote: > Hello Trent, > > Thus quoth trent shipley on Sun Nov 19 2017 at 12:12 (+0100): > > On Sun, Nov 19, 2017 at 3:40 AM Sergiu Ivanov > wrote: > >> Thus quoth trent shipley on Sun Nov 19 2017 at 08:05 (+0100): > >> > > >> > I have a vision for a spreadsheet that is programmable as a > spreadsheet > >> > itself. > >> [...] > >> > * Is a spreadsheet you can program from the spreadsheet a reasonable > >> > goal? > >> > >> What kind of use cases do you imagine for your programmable spreadsheet? > >> "Reasonable" will usually depend on your context. > > > > I really haven't thought of specific use cases, but I have thought in > > general terms about what you might do with a natively programmable > > spreadsheet. > > > > 1. It would be an interesting exercise in itself, and if it hadn't > been > > done before, might be worth a paper. (I submit that this is actually > a real > > use case.) > > That's a good and a fun use case, but it's probably not going to attract > a lot of developers/maintainers. > No it wouldn't I suppose. It would be a way to get it started, and to explore new possibilities, but the academic use case certainly won't produce stability. Actually a few fully functional spreadsheets have been developed, mostly to explore the spreadsheet as a visual programming tool, or human computer interaction. "Spreadsheet Implementation Technology: Basics and Extensions", Peter Sestoft, MIT Press. may provide fully functional spreadsheets for hacking (maybe based on Forms/3 http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html, at least in part. Forms/3 was M Burrnett's spreadsheet for HCI research.) > > > 2. It would be more elegant that the current solution to a > programmable > > spreadsheet, which is a spreadsheet that is almost, but not quite > > programmable, with a helper imperative language and programming mode > stuck > > onto the base spreadsheet. > > Well, as Olaf points out in another thread (I think), the fact that > conventional spreadsheets are not completely programmable is also an > advantage: you know what your spreadsheet _cannot_ do, which helps with > debugging. > > I do admit that's not an argument against programmable spreadsheets, > though. > > > 3. You could build a programmable spreadsheet on steroids with this > > idea, and I have some other interesting ideas, like "virtual > spreadsheets" > > that would allow spreadsheets to extend into n dimensions (but I > digress). > > 4. So engineers, scientists, economists, and finance might have niche > > uses for a (n-dimensional) programmable spreadsheet on > steroids--though I > > don't know in detail what those would be. > > 5. I am a trained social scientist (anthropology) I know it is not > > uncommon for social scientists to have to deal with large, > multidimensional > > datasets, and analyze the same. A multidimensional programmable > spreadsheet > > might help a lot with that. > > Multidimensionality seems to be a really important point in your > project. On the other hand, without having any specialised knowledge in > spreadsheet-crunching, I'm tempted to suppose that what these scientist > need is quite below Turing completeness, once multidimensionality is > provided. > > I should be more careful with the distinction between multidimensional spreadsheets and n-dimensional spreadsheets. Multidimensional spreadsheets like Lotus Improv and Lighthouse Design's Quantrix (based on Improv and ran on Steve Job's NextStep) were spreadsheets with a sophisticated way to model data that was called "multidimensional", that is not what I am referring to. Assume an additional level to the spreadsheet's organization between a workbook and a sheet called a "virtual workbook". A root (file) workbook can contain virtual workbooks or sheets. A virtual workbook can also contain virtual work books or sheets. Sheets are 3-dimensional, and then you're done, but virtual workbooks can be nested as deeply as desired, so a spreadsheet with virtual workbooks could model n-dimensions. Also, if sheets can be marked as being functions, virtual workbooks can support libraries of functions, or objects, if you want such things. > Do you think a semi-programmable (as in LibreOffice) multidimensional > spreadsheet may cut it for them? > Might. It might not for finance. https://arxiv.org/abs/0909.2452 See also: http://www.eusprig.org/index.htm http://www.eusprig.org/best-practice.htm I have to admit I haven't poked around as much as I should before passing these references on. > > > 6. I have heard that finance wizards often use Excel+VBA to do > modeling. > > They might like a consistent, single language programming environment > that > > offers more power and type safety that Excel + VBA. It would also > need to > > be FAST if it is to be used for something like market analysis or > automated > > trading. > > Your argument is probably based on way more experience than mine, but > personally I don't at all aspire to have a homogeneous language > environment. I actually like the separation in Excel: formulas for > almost any operations; VBA when real muscle-power is inevitable. > > That was my two-cent addition to the brainstorming :-) > S Jones, M Burnett, and A Blackwell called this (disparagingly) "the trap door model". It has also been called the "bolt on" model. It's not that bad. It does require two sets of knowledge, and rather separate skill sets. I'm really not that hostile to it. It works, but I do like to have more than one way to do things. A fully functional spreadsheet would be a nice alternative. Programmers have to learn multiple languages, and most wind up liking it. They also have favorite languages. LibreOffice Calc has about four bolt-on languages. As I recall, none of them are a functional programming language. Maybe a few programmers should get together and add one as a sub-project. > > Finding plausible use cases is also hindered by both a version of an > > existing spreadsheet enabling native functions, or a more full featured > > Scriptsheets product both being vaporware. > > Not necessarily, as you showed in the message I am replying to :-) > > My reasoning behind suggesting to consider potential applications is > that the abstract model you are mulling over is very general and can be > implemented in various quite different ways—e.g., LibreOffice, Scilab, > and the R language all focus on matrix processing (more or less), but > they are so different that people seem to agree they are not really > directly comparable, and thus not conflicting. > > Now, I may be mistaken and you may have a very clear idea of an > implementation, in which case my suggestions are simply redundant. > If implementation means "how to program it", I have no idea. If implementation means refining a proposal, and leading into a functional spec, then, yes, I am working on that. Up to now mostly in my own head, which is why I'm seeking input, validation, and criticism. Depending, I'll go back and refine what I have. > >> > It would be natural to use C++ > >> > >> Using C++ looks in no way natural _to me_; "natural" will also depend on > >> your use case ;-) > >> > > > > The main argument for C++ is that if you are "reusing" existing code from > > GNUmeric or LibreOffice Calc none of that is in a functional language. It > > will tend to be in C++ (and maybe Java for Calc). > > Are you talking about the language for spreadsheet programming or about > the implementation language for your project? > Implementation. > If we are in the former case, the implementation language need not > necessarily be the same as the language of the spreadsheet, like in the > HotSpot JVM which seems to be written in C++ [0] even though it runs > tons of other languages or Excel itself, which I doubt is written in > VBA. > > As far as I know, Access, Excel, PowerPoint, and Word, are all implemented in Microsoft C++. > > Also, if speed is of the essence, my impression is that C++ and C come to > > the fore. > > Yes, but overoptimisation along one criterion among many is also an > issue. The trade-off between faster code or code easier to maintain is > a difficult one. > Financiers' market trading code is notorious for being time critical, they are trying to beat other trading companies to the market. > > But then you're are right, C++ and C are often quite in the lead in what > concerns speed (even though some tweaks may bring other programming > languages quite close [1]). > > -- > Sergiu > > [0] https://en.wikipedia.org/wiki/HotSpot > > [1] > http://paulspontifications.blogspot.fr/2013/01/when-haskell-is-faster-than-c.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Tue Nov 21 06:45:42 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 21 Nov 2017 07:45:42 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> Message-ID: > I should be more careful with the distinction between multidimensional > spreadsheets and n-dimensional spreadsheets. Multidimensional > spreadsheets like Lotus Improv and Lighthouse Design's Quantrix (based > on Improv and ran on Steve Job's NextStep) were spreadsheets with a > sophisticated way to model data that was called "multidimensional", that > is not what I am referring to. > > Assume an additional level to the spreadsheet's organization between a > workbook and a sheet called a "virtual workbook". A root (file) workbook > can contain virtual workbooks or sheets. A virtual workbook can also > contain virtual work books or sheets. Sheets are 3-dimensional, and then > you're done, but virtual workbooks can be nested as deeply as desired, > so a spreadsheet with virtual workbooks could model n-dimensions. Which one it is that you are interested in? "Three-dimensional" as in "we have row, column, and layer", or as in "we have hierarchical workbooks"? > Also, if sheets can be marked as being functions, virtual workbooks can > support libraries of functions, or objects, if you want such things. Sometimes I think Excel etc. got it all wrong. People routinely reserve areas inside the spreadsheet for different tasks: input, intermediate results, output. Increasing the size of each area becomes a pain. I'd want to have a spreadsheet where it's easy to define multiple sheets on the same "table". Extending the input sheet with another row automatically extends the output sheet by a row (and if you have rollup then we get more than one row). Intermediate sheets could be replaced by a function definition. It's a bit of an ergonomic challenge; functions are much more abstract, and users will want to see how the results of applying a function to an input area look like. So the mental model might be that we still have intermediate sheets, but with just a single function, and the intermediate sheets can be create, destroyed, shown and hidden easily. The other challenge would be dealing with headers. Headers are important, but for the intermediate we have just the function so it needs to provide the headers. I.e. the function result would have to be a named tuple, and if you want multiline headers, we get a hierarchical named tuple. Manipulating the column order would also manipulate the tuple definition, i.e. you'd have to think about how GUI manipulation affects the function definition. There's pivot tables, so the difference between row and column isn't as clear-cut as the above assumes. There are a few more things to consider. It's firmly in the GUI ergonomics area. For this kind of stuff, you don't care whether the programming language evaluation semantics matches the problem domain (spreadsheet functional semantics is easy to do in any language, it was done in Assembler with Lotus 1-2-3), you care whether it is easy to prototype GUI approaches, which means GUI libraries that make it easy to create new widgets. > Programmers have to learn multiple languages, and most wind up liking > it. They also have favorite languages. LibreOffice Calc has about four > bolt-on languages. As I recall, none of them are a functional > programming language. Maybe a few programmers should get together and > add one as a sub-project. The problem is that any additional language needs to be installed. So either the new language needs to be integrated in the LO project, or it is not and anybody who passes on a spreadsheet in the new language needs to tell the recipients how to install the plugin for the language. Maybe that's the reason why only the four languages exist. > Financiers' market trading code is notorious for being time critical, > they are trying to beat other trading companies to the market. Spreadsheets are irrelevant to high-speed trading, they'd be too slow anyway. I am working for a company that operates a stock exchange, and rumor has it that the reaction times are down to 12 milli(!)seconds. Maybe it's not reaction time but ping time and the computation latency is on top of those 12 ms, but on a 4-GHz machine, 12 ms is 12,000 clock cycles, which is a pretty tight timescale to process dozens or maybe thousands of orders that have happened and post your own trade. > But then you're are right, C++ and C are often quite in the lead in what > concerns speed (even though some tweaks may bring other programming > languages quite close [1]). I think one of the important factors is how much coder effort is needed to get that kind of performance. The trade-off seems to be how much coder effort is needed to get the code correct. From what I hear: C++ gives easy and predictable performance (if you code for that), while being somewhat unpredictable on correctness. Haskell excels at correctness, gives reasonable but not very predictable performance. Java is predictable with correctness though not excellent, and predictable with performance though not excellent. From lysxia at gmail.com Tue Nov 21 06:48:14 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 21 Nov 2017 01:48:14 -0500 Subject: [Haskell-cafe] Questions about Numeric.AD / Automatic differentiation In-Reply-To: References: Message-ID: <7ec88b54-54c9-f800-74c1-7239750238e7@gmail.com> Hi Sean, AD relies on overloading to instrument functions so they can be differentiated. f :: Num a => m1 (m2 a) -> m3 a -> a By looking at the type of "grad", one can see that f will be specialized at type "Reverse s Double": f :: m1 (m2 (Reverse s Double)) -> m3 (Reverse s Double) -> Reverse s Double So if "x :: m1 (m2 Double)", you will need to apply "auto :: Double -> Reverse s Double" to lift x to the right type. df x theta = grad (f x') theta where x' = (fmap . fmap) auto x Cheers, Li-yao On 11/20/2017 05:05 PM, Sean Matthews wrote: > I'm having some problems with Numeric.AD (translation, things are not > working for reason that I don't understand). Note I don't have much > experience with this package, so these are newbie questions, thus > appropriate answers may involve pointing me to a document somewhere out > there on the net. > > Anyway, here is my problem: > > I have a function (call it f x theta) which I have defined purely in terms > of basic arithmetic functions (+/-/(/)/*/**) glued together using standard > applicative functor operations has type > > f :: m1 (m2 Double) -> m3 Double -> Double > f x theta = ... > > m1 m2 and m3 are all Traversable. > f is defined purely in terms of basic arithmetic operations, (+/-/(/)/*/**) > glued together using standard applicative functor operations, and m1 m2 and > m3 are all pretty trivial record types (no recursion, even). > > I would like to write > > df x theta = grad (f x) theta > > But it refuses to type, even though (admittedly quite a lot) simpler > versions do. > > So what am I missing? Does AD not go through Applicative? That seems > unlikely to me. > > Any advice / suggestions, etc. gratefully received. > > Sean Matthews > > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 olshanskydr at gmail.com Tue Nov 21 07:48:48 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Tue, 21 Nov 2017 10:48:48 +0300 Subject: [Haskell-cafe] problem with compiler error message Message-ID: Hello cafe! It seems that this behavior is wrong: > class Foo a where { type Bar a; baz :: a -> Bar a } > baz zzz -- zzz is not in scope :17:1: error: • Couldn't match expected type ‘Bar a’ with actual type ‘Bar a0’ NB: ‘Bar’ is a type function, and may not be injective The type variable ‘a0’ is ambiguous • In the ambiguity check for the inferred type for ‘it’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the inferred type it :: forall a. Bar a As opposite - correct behavior: > :t negate negate :: Num a => a -> a > negate zzz :19:8: error: Variable not in scope: zzz Best regards, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: From olshanskydr at gmail.com Tue Nov 21 09:51:27 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Tue, 21 Nov 2017 12:51:27 +0300 Subject: [Haskell-cafe] problem with compiler error message In-Reply-To: References: Message-ID: GHCi 8.2.1. 2017-11-21 10:48 GMT+03:00 Dmitry Olshansky : > Hello cafe! > > It seems that this behavior is wrong: > > > class Foo a where { type Bar a; baz :: a -> Bar a } > > baz zzz -- zzz is not in scope > :17:1: error: > • Couldn't match expected type ‘Bar a’ with actual type ‘Bar a0’ > NB: ‘Bar’ is a type function, and may not be injective > The type variable ‘a0’ is ambiguous > • In the ambiguity check for the inferred type for ‘it’ > To defer the ambiguity check to use sites, enable AllowAmbiguousTypes > When checking the inferred type > it :: forall a. Bar a > > As opposite - correct behavior: > > :t negate > negate :: Num a => a -> a > > negate zzz > :19:8: error: Variable not in scope: zzz > > Best regards, > Dmitry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanmatthews1 at gmail.com Tue Nov 21 12:24:55 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Tue, 21 Nov 2017 13:24:55 +0100 Subject: [Haskell-cafe] Questions about Numeric.AD / Automatic differentiation In-Reply-To: <7ec88b54-54c9-f800-74c1-7239750238e7@gmail.com> References: <7ec88b54-54c9-f800-74c1-7239750238e7@gmail.com> Message-ID: After working through the other problems, that fills the last remaining hole (at least for the moment). Many thanks, Sean On Tue, Nov 21, 2017 at 7:48 AM, Li-yao Xia wrote: > Hi Sean, > > AD relies on overloading to instrument functions so they can be > differentiated. > > f :: Num a => m1 (m2 a) -> m3 a -> a > > By looking at the type of "grad", one can see that f will be specialized > at type "Reverse s Double": > > f :: m1 (m2 (Reverse s Double)) -> m3 (Reverse s Double) -> Reverse s > Double > > So if "x :: m1 (m2 Double)", you will need to apply "auto :: Double -> > Reverse s Double" to lift x to the right type. > > df x theta = grad (f x') theta > where x' = (fmap . fmap) auto x > > Cheers, > Li-yao > > On 11/20/2017 05:05 PM, Sean Matthews wrote: > >> I'm having some problems with Numeric.AD (translation, things are not >> working for reason that I don't understand). Note I don't have much >> experience with this package, so these are newbie questions, thus >> appropriate answers may involve pointing me to a document somewhere out >> there on the net. >> >> Anyway, here is my problem: >> >> I have a function (call it f x theta) which I have defined purely in terms >> of basic arithmetic functions (+/-/(/)/*/**) glued together using >> standard >> applicative functor operations has type >> >> f :: m1 (m2 Double) -> m3 Double -> Double >> f x theta = ... >> >> m1 m2 and m3 are all Traversable. >> f is defined purely in terms of basic arithmetic operations, >> (+/-/(/)/*/**) >> glued together using standard applicative functor operations, and m1 m2 >> and >> m3 are all pretty trivial record types (no recursion, even). >> >> I would like to write >> >> df x theta = grad (f x) theta >> >> But it refuses to type, even though (admittedly quite a lot) simpler >> versions do. >> >> So what am I missing? Does AD not go through Applicative? That seems >> unlikely to me. >> >> Any advice / suggestions, etc. gratefully received. >> >> Sean Matthews >> >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Nov 21 12:27:40 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 21 Nov 2017 14:27:40 +0200 Subject: [Haskell-cafe] [ANN]: fin & vec Message-ID: <4822d950-4b6c-1d14-fe10-4af4e625aded@iki.fi> I'm happy to announce two packages: - http://hackage.haskell.org/package/fin - http://hackage.haskell.org/package/vec In short they provide following types:     data Nat where Z | S Nat     data Fin (n :: Nat) where         Z ::          Fin ('S n)         S :: Fin n -> Fin ('S n)     data Vec (n :: Nat) a where         VNil  :: Vec 'Z a         (:::) :: a -> Vec n a -> Vec ('S n) a Main motivation for creating these packages is that I didn't found anything similar on Hackage. Before comparison with the alternatives, let me mention few highlights: - `fin` and `vec` support GHC-7.8.4 .. GHC-8.2.1; and I plan to keep support   window as wide as possible. - `fin` package provides `Data.Fin.Enum` module to work generically with   enumerations. It's (subjectively) more ergonomic than working with   `All ((:~:) a) xs => NS I xs` from `generics-sop` [1] - `fin` package defines `InlineInduction` class,   letting us trick GHC to unfold recursion. One general example is         unfoldedFix :: forall n a proxy. InlineInduction n                     => proxy n -> (a -> a) -> a         unfoldedFix _ = getFix (inlineInduction1 start step :: Fix n a) where             start :: Fix 'Z a             start = Fix fix             step :: Fix m a -> Fix ('S m) a             step (Fix go) = Fix $ \f -> f (go f)         newtype Fix (n :: Nat) a = Fix { getFix :: (a -> a) -> a }    So, for statically known @n@, GHC's inliner will "simplify":        unfoldedFix (Proxy :: Proxy Nat3) f = f (f (f (fix f))) - `fin` has very light dependency footprint:   `base`, `deepseq`, `hashable` (and transitively `text`) on GHC>=8.0 - `vec` has a little more dependencies, essentially `lens`. See dependency   diagram in the readme. [2] - `vec` comes in three flavours:     * __naive__: with explicit recursion. It's simple, constraint-less, yet slow.     * __pull__: using `Fin n -> a` representation, which fuses well,       but makes some programs hard to write. And     * __inline__: which uses `InlineInduction`, unrolling       recursion if the size of 'Vec' is known statically. Differences with other packages ------------------------------- ### fin - [type-natural](http://hackage.haskell.org/package/type-natural) depends   on @singletons@ package. `fin` will try to stay light on the dependencies,   and support as many GHC versions as practical. - [peano](http://hackage.haskell.org/package/peano) is very incomplete - [nat](http://hackage.haskell.org/package/nat) as well. - [PeanoWitnesses](https://hackage.haskell.org/package/PeanoWitnesses)   doesn't use @DataKinds at . - [type-combinators](http://hackage.haskell.org/package/type-combinators)   is a big package. ### vec - [linear](http://hackage.haskell.org/package/linear) has 'V' type,   which uses 'Vector' from @vector@ package as backing store.   `Vec` is a real GADT, but tries to provide as many useful instances (upto   @lens@). - [sized-vector](http://hackage.haskell.org/package/sized-vector) depends   on 'singletons' package. `vec` isn't light on dependencies either,   but try to provide wide GHC support. - [sized](https://hackage.haskell.org/package/sized) also depends   on a 'singletons' package. The 'Sized f n a' type is generalisation of   linears 'V' for any 'ListLike'. - [clash-prelude](https://hackage.haskell.org/package/clash-prelude)   is a kitchen sink package, which has 'CLaSH.Sized.Vector' module.   Also depends on 'singletons'. Disclaimer ---------- These are the "first released versions", i.e. `fin-0` and `vec-0`. Don't be fooled by 0, we use them in production. We don't have (yet?) a use-case where proper full inlining would matter, it seems to work with simple examples. The `vec` package includes simple dot product benchmark, it gives sensible results: - *list* version sets the baseline, built-in fusion seems to kick in. - using `vector` is 3x slower (?) - naive `Vec` is even slower, not surprisingly - `Data.Vec.Pull` approach is slower, *except* - that without conversions it's up to speed with `vector` - `InlineInduction` is *fastest*. Acknowledgements ---------------- - *APLicative Programming with Naperian Functors* [3] has the very similar   `Nat`, `Fin` and `Vec` (sections 2--4). I spotted few missing functions in   `vec` by re-reading the paper (`vgroup` is `chunks` and `viota` is `universe`).   I don't claim that my library is novel in any kind :) - I learned *Pull array* idea from Josef Svenningsson talk at SmallFP 2017 [4].   See the video [5] if interested. - Herbert Valerio Riedel for the idea to split `fin` out of `vec`. It turned   out to be very light package. - Andres Löh for discussions about `generics-sop` [1], and about the static   inlining idea. - Joachim Breitner for creating `inspection-testing` [6], which really helps   validating optimisations working. Cheers, Oleg - [1] http://hackage.haskell.org/package/generics-sop - [2] https://github.com/phadej/vec#dependencies - [3] https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf - [4] http://clojutre.org/2017/ - [5] https://www.youtube.com/watch?v=5PZh0BcjIbY&list=PLetHPRQvX4a9uUK2JUZrgjtC_x4CeNLtN&index=5 - [6] http://hackage.haskell.org/package/inspection-testing -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From lysxia at gmail.com Tue Nov 21 13:02:44 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 21 Nov 2017 08:02:44 -0500 Subject: [Haskell-cafe] problem with compiler error message In-Reply-To: References: Message-ID: <49de13da-422d-fb65-0587-bc0d64f1172a@gmail.com> Hi Dmitry, This is indeed a GHC bug. Here's an existing ticket about it, it seems to be fixed for the next release of GHC. https://ghc.haskell.org/trac/ghc/ticket/14000 Cheers, Li-yao On 11/21/2017 04:51 AM, Dmitry Olshansky wrote: > GHCi 8.2.1. > > 2017-11-21 10:48 GMT+03:00 Dmitry Olshansky : > >> Hello cafe! >> >> It seems that this behavior is wrong: >> >>> class Foo a where { type Bar a; baz :: a -> Bar a } >>> baz zzz -- zzz is not in scope >> :17:1: error: >> • Couldn't match expected type ‘Bar a’ with actual type ‘Bar a0’ >> NB: ‘Bar’ is a type function, and may not be injective >> The type variable ‘a0’ is ambiguous >> • In the ambiguity check for the inferred type for ‘it’ >> To defer the ambiguity check to use sites, enable AllowAmbiguousTypes >> When checking the inferred type >> it :: forall a. Bar a >> >> As opposite - correct behavior: >>> :t negate >> negate :: Num a => a -> a >>> negate zzz >> :19:8: error: Variable not in scope: zzz >> >> Best regards, >> Dmitry >> > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 vagarenko at gmail.com Tue Nov 21 13:21:57 2017 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Tue, 21 Nov 2017 18:21:57 +0500 Subject: [Haskell-cafe] [ANN]: fin & vec In-Reply-To: <4822d950-4b6c-1d14-fe10-4af4e625aded@iki.fi> References: <4822d950-4b6c-1d14-fe10-4af4e625aded@iki.fi> Message-ID: I wrote a package not long ago which also uses static inlining for similar things: https://hackage.haskell.org/package/static-tensor There is also https://hackage.haskell.org/package/vector-sized which is a wrapper around 'vector' library. Virus-free. www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2017-11-21 17:27 GMT+05:00 Oleg Grenrus : > I'm happy to announce two packages: > > - http://hackage.haskell.org/package/fin > - http://hackage.haskell.org/package/vec > > In short they provide following types: > > data Nat where Z | S Nat > > data Fin (n :: Nat) where > Z :: Fin ('S n) > S :: Fin n -> Fin ('S n) > > data Vec (n :: Nat) a where > VNil :: Vec 'Z a > (:::) :: a -> Vec n a -> Vec ('S n) a > > Main motivation for creating these packages is that I didn't found anything > similar on Hackage. Before comparison with the alternatives, let me > mention few > highlights: > > - `fin` and `vec` support GHC-7.8.4 .. GHC-8.2.1; and I plan to keep > support > window as wide as possible. > > - `fin` package provides `Data.Fin.Enum` module to work generically with > enumerations. It's (subjectively) more ergonomic than working with > `All ((:~:) a) xs => NS I xs` from `generics-sop` [1] > > - `fin` package defines `InlineInduction` class, > letting us trick GHC to unfold recursion. One general example is > > unfoldedFix :: forall n a proxy. InlineInduction n > => proxy n -> (a -> a) -> a > unfoldedFix _ = getFix (inlineInduction1 start step :: Fix n a) > where > start :: Fix 'Z a > start = Fix fix > > step :: Fix m a -> Fix ('S m) a > step (Fix go) = Fix $ \f -> f (go f) > > newtype Fix (n :: Nat) a = Fix { getFix :: (a -> a) -> a } > > So, for statically known @n@, GHC's inliner will "simplify": > > unfoldedFix (Proxy :: Proxy Nat3) f = f (f (f (fix f))) > > - `fin` has very light dependency footprint: > `base`, `deepseq`, `hashable` (and transitively `text`) on GHC>=8.0 > > - `vec` has a little more dependencies, essentially `lens`. See dependency > diagram in the readme. [2] > > - `vec` comes in three flavours: > > * __naive__: with explicit recursion. It's simple, constraint-less, > yet slow. > > * __pull__: using `Fin n -> a` representation, which fuses well, > but makes some programs hard to write. And > > * __inline__: which uses `InlineInduction`, unrolling > recursion if the size of 'Vec' is known statically. > > Differences with other packages > ------------------------------- > > ### fin > > - [type-natural](http://hackage.haskell.org/package/type-natural) depends > on @singletons@ package. `fin` will try to stay light on the > dependencies, > and support as many GHC versions as practical. > > - [peano](http://hackage.haskell.org/package/peano) is very incomplete > > - [nat](http://hackage.haskell.org/package/nat) as well. > > - [PeanoWitnesses](https://hackage.haskell.org/package/PeanoWitnesses) > doesn't use @DataKinds at . > > - [type-combinators](http://hackage.haskell.org/package/type-combinators) > is a big package. > > ### vec > > - [linear](http://hackage.haskell.org/package/linear) has 'V' type, > which uses 'Vector' from @vector@ package as backing store. > `Vec` is a real GADT, but tries to provide as many useful instances (upto > @lens@). > > - [sized-vector](http://hackage.haskell.org/package/sized-vector) depends > on 'singletons' package. `vec` isn't light on dependencies either, > but try to provide wide GHC support. > > - [sized](https://hackage.haskell.org/package/sized) also depends > on a 'singletons' package. The 'Sized f n a' type is generalisation of > linears 'V' for any 'ListLike'. > > - [clash-prelude](https://hackage.haskell.org/package/clash-prelude) > is a kitchen sink package, which has 'CLaSH.Sized.Vector' module. > Also depends on 'singletons'. > > Disclaimer > ---------- > > These are the "first released versions", i.e. `fin-0` and `vec-0`. > Don't be fooled by 0, we use them in production. > > We don't have (yet?) a use-case where proper full inlining would matter, it > seems to work with simple examples. The `vec` package includes simple dot > product benchmark, it gives sensible results: > > - *list* version sets the baseline, built-in fusion seems to kick in. > - using `vector` is 3x slower (?) > - naive `Vec` is even slower, not surprisingly > - `Data.Vec.Pull` approach is slower, *except* > - that without conversions it's up to speed with `vector` > - `InlineInduction` is *fastest*. > > Acknowledgements > ---------------- > > - *APLicative Programming with Naperian Functors* [3] has the very similar > `Nat`, `Fin` and `Vec` (sections 2--4). I spotted few missing functions > in > `vec` by re-reading the paper (`vgroup` is `chunks` and `viota` is > `universe`). > I don't claim that my library is novel in any kind :) > - I learned *Pull array* idea from Josef Svenningsson talk at SmallFP > 2017 [4]. > See the video [5] if interested. > - Herbert Valerio Riedel for the idea to split `fin` out of `vec`. It > turned > out to be very light package. > - Andres Löh for discussions about `generics-sop` [1], and about the static > inlining idea. > - Joachim Breitner for creating `inspection-testing` [6], which really > helps > validating optimisations working. > > Cheers, > Oleg > > > - [1] http://hackage.haskell.org/package/generics-sop > - [2] https://github.com/phadej/vec#dependencies > - [3] > https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf > - [4] http://clojutre.org/2017/ > - [5] > https://www.youtube.com/watch?v=5PZh0BcjIbY&list= > PLetHPRQvX4a9uUK2JUZrgjtC_x4CeNLtN&index=5 > - [6] http://hackage.haskell.org/package/inspection-testing > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 oleg.grenrus at iki.fi Tue Nov 21 14:14:16 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 21 Nov 2017 16:14:16 +0200 Subject: [Haskell-cafe] [ANN]: fin & vec In-Reply-To: References: <4822d950-4b6c-1d14-fe10-4af4e625aded@iki.fi> Message-ID: <83ea1261-db5f-eb95-682a-6f6529fed40a@iki.fi> Thanks for more references! I was quite sure I didn't found all packages around fin/nat/vec (and I feel a little bad for making "standards" problem worse :) - https://hackage.haskell.org/package/finite-typelits uses GHC.TypeLits.Nat (fair thing to do). - https://hackage.haskell.org/package/vector-sized builds on top of that and looks like a nice package too! I dislike GHC.TypeLits.Nat for doing induction over, yet for many things they (+ [1,2] or [3]) are great. I have to write that down in the description of the package(s). Hopefully the approaches: compiler built-in magic and DataKinds definition would be unified in the future. Cheers, Oleg. - [1] https://hackage.haskell.org/package/ghc-typelits-natnormalise - [2] https://hackage.haskell.org/package/ghc-typelits-extra - [3] http://hackage.haskell.org/package/constraints-0.9.1/docs/Data-Constraint-Nat.html On 21.11.2017 15:20, Alexey Vagarenko wrote: > I wrote a package not long ago which also uses static inlining for > similar things: https://hackage.haskell.org/package/static-tensor > > There is also https://hackage.haskell.org/package/vector-sized which > is a wrapper around 'vector' library. > > > Virus-free. www.avg.com > > > > > 2017-11-21 17:27 GMT+05:00 Oleg Grenrus >: > > I'm happy to announce two packages: > > - http://hackage.haskell.org/package/fin > > - http://hackage.haskell.org/package/vec > > > In short they provide following types: > >     data Nat where Z | S Nat > >     data Fin (n :: Nat) where >         Z ::          Fin ('S n) >         S :: Fin n -> Fin ('S n) > >     data Vec (n :: Nat) a where >         VNil  :: Vec 'Z a >         (:::) :: a -> Vec n a -> Vec ('S n) a > > Main motivation for creating these packages is that I didn't found > anything > similar on Hackage. Before comparison with the alternatives, let me > mention few > highlights: > > - `fin` and `vec` support GHC-7.8.4 .. GHC-8.2.1; and I plan to > keep support >   window as wide as possible. > > - `fin` package provides `Data.Fin.Enum` module to work > generically with >   enumerations. It's (subjectively) more ergonomic than working with >   `All ((:~:) a) xs => NS I xs` from `generics-sop` [1] > > - `fin` package defines `InlineInduction` class, >   letting us trick GHC to unfold recursion. One general example is > >         unfoldedFix :: forall n a proxy. InlineInduction n >                     => proxy n -> (a -> a) -> a >         unfoldedFix _ = getFix (inlineInduction1 start step :: Fix > n a) > where >             start :: Fix 'Z a >             start = Fix fix > >             step :: Fix m a -> Fix ('S m) a >             step (Fix go) = Fix $ \f -> f (go f) > >         newtype Fix (n :: Nat) a = Fix { getFix :: (a -> a) -> a } > >    So, for statically known @n@, GHC's inliner will "simplify": > >        unfoldedFix (Proxy :: Proxy Nat3) f = f (f (f (fix f))) > > - `fin` has very light dependency footprint: >   `base`, `deepseq`, `hashable` (and transitively `text`) on GHC>=8.0 > > - `vec` has a little more dependencies, essentially `lens`. See > dependency >   diagram in the readme. [2] > > - `vec` comes in three flavours: > >     * __naive__: with explicit recursion. It's simple, > constraint-less, > yet slow. > >     * __pull__: using `Fin n -> a` representation, which fuses well, >       but makes some programs hard to write. And > >     * __inline__: which uses `InlineInduction`, unrolling >       recursion if the size of 'Vec' is known statically. > > Differences with other packages > ------------------------------- > > ### fin > > - [type-natural](http://hackage.haskell.org/package/type-natural > ) depends >   on @singletons@ package. `fin` will try to stay light on the > dependencies, >   and support as many GHC versions as practical. > > - [peano](http://hackage.haskell.org/package/peano > ) is very incomplete > > - [nat](http://hackage.haskell.org/package/nat > ) as well. > > - > [PeanoWitnesses](https://hackage.haskell.org/package/PeanoWitnesses > ) >   doesn't use @DataKinds at . > > - > [type-combinators](http://hackage.haskell.org/package/type-combinators > ) >   is a big package. > > ### vec > > - [linear](http://hackage.haskell.org/package/linear > ) has 'V' type, >   which uses 'Vector' from @vector@ package as backing store. >   `Vec` is a real GADT, but tries to provide as many useful > instances (upto >   @lens@). > > - [sized-vector](http://hackage.haskell.org/package/sized-vector > ) depends >   on 'singletons' package. `vec` isn't light on dependencies either, >   but try to provide wide GHC support. > > - [sized](https://hackage.haskell.org/package/sized > ) also depends >   on a 'singletons' package. The 'Sized f n a' type is > generalisation of >   linears 'V' for any 'ListLike'. > > - > [clash-prelude](https://hackage.haskell.org/package/clash-prelude > ) >   is a kitchen sink package, which has 'CLaSH.Sized.Vector' module. >   Also depends on 'singletons'. > > Disclaimer > ---------- > > These are the "first released versions", i.e. `fin-0` and `vec-0`. > Don't be fooled by 0, we use them in production. > > We don't have (yet?) a use-case where proper full inlining would > matter, it > seems to work with simple examples. The `vec` package includes > simple dot > product benchmark, it gives sensible results: > > - *list* version sets the baseline, built-in fusion seems to kick in. > - using `vector` is 3x slower (?) > - naive `Vec` is even slower, not surprisingly > - `Data.Vec.Pull` approach is slower, *except* > - that without conversions it's up to speed with `vector` > - `InlineInduction` is *fastest*. > > Acknowledgements > ---------------- > > - *APLicative Programming with Naperian Functors* [3] has the very > similar >   `Nat`, `Fin` and `Vec` (sections 2--4). I spotted few missing > functions in >   `vec` by re-reading the paper (`vgroup` is `chunks` and `viota` is > `universe`). >   I don't claim that my library is novel in any kind :) > - I learned *Pull array* idea from Josef Svenningsson talk at SmallFP > 2017 [4]. >   See the video [5] if interested. > - Herbert Valerio Riedel for the idea to split `fin` out of `vec`. > It turned >   out to be very light package. > - Andres Löh for discussions about `generics-sop` [1], and about > the static >   inlining idea. > - Joachim Breitner for creating `inspection-testing` [6], which > really helps >   validating optimisations working. > > Cheers, > Oleg > > > - [1] http://hackage.haskell.org/package/generics-sop > > - [2] https://github.com/phadej/vec#dependencies > > - [3] > https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/aplicative.pdf > > - [4] http://clojutre.org/2017/ > - [5] > https://www.youtube.com/watch?v=5PZh0BcjIbY&list=PLetHPRQvX4a9uUK2JUZrgjtC_x4CeNLtN&index=5 > > - [6] http://hackage.haskell.org/package/inspection-testing > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From frank at fstaals.net Tue Nov 21 20:13:06 2017 From: frank at fstaals.net (Frank Staals) Date: Tue, 21 Nov 2017 21:13:06 +0100 Subject: [Haskell-cafe] [ANN]: fin & vec In-Reply-To: <83ea1261-db5f-eb95-682a-6f6529fed40a@iki.fi> (Oleg Grenrus's message of "Tue, 21 Nov 2017 16:14:16 +0200") References: <4822d950-4b6c-1d14-fe10-4af4e625aded@iki.fi> <83ea1261-db5f-eb95-682a-6f6529fed40a@iki.fi> Message-ID: Oleg Grenrus writes: > Thanks for more references! I was quite sure I didn't found all packages > around fin/nat/vec (and I feel a little bad for making "standards" > problem worse :) > There is also https://hackage.haskell.org/package/fixed-vector which I've been using for this sort of thing. -- - Frank From olf at aatal-apotheke.de Tue Nov 21 20:29:35 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 21 Nov 2017 21:29:35 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet Message-ID: > Olaf, have you looked at Jupyter at all? This now > has a backend for Haskell and supports many of the things you mention. Neil, I must have forgotten about Jupyter. That is exactly what I was takling about! I have become quite a fan of literate programming. Now I admit that Jupyter looks quite different from spreadsheets, so wont' fit the bill of what Trent was originally asking for. As I tried to express earlier, the strength of spreadseets in my eyes is the somewhat explicit data flow. (You need to highlight a cell to see its formula.) Hence I envision a Jupyter with data flow made explicit. You start by defining your input data. Single values, lists, matrices, whatever. You can define some functions, which will act as edges of your data flow graph. Then you combine these functions and apply to the data. For each (f.g)(x), all of x, g(x) and (f.g)(x) become nodes of a graph with (f.g)(x) hyperlinked to g(x) which in turn gets hyperlinked to x. Thus you can explore backwards from the result and see how the answer was derived. Of course a nicely written Jupyter notebook needs no hyperlinks. One can leave enough explanation in the markup cells. But not everyone is trained to read and understand such mixture of text and code. There might be an applicative functor (a variant of 'State SomeGraph') for what I'm after. Once I've defined it, I'll post it here. Olaf From jo at durchholz.org Tue Nov 21 20:47:27 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 21 Nov 2017 21:47:27 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> Message-ID: <0aaf8e53-f20b-baab-4f30-83275c1b753a@durchholz.org> Am 21.11.2017 um 08:13 schrieb trent shipley: > Which one it is that you are interested in? > "Three-dimensional" as in "we have row, column, and layer", or as in "we > have hierarchical workbooks"? > > They are not mutually exclusive. A workbook can contain sheets--just > like now. IN ADDITION, you can put workbooks in workbooks, until you > reach the root workbook, which is also a file. Not an answer that helps me understand your point. > > Also, if sheets can be marked as being functions, virtual > workbooks can > > support libraries of functions, or objects, if you want such things. > > Sometimes I think Excel etc. got it all wrong. > People routinely reserve areas inside the spreadsheet for different > tasks: input, intermediate results, output. Increasing the size of each > area becomes a pain. > > I'd want to have a spreadsheet where it's easy to define multiple sheets > on the same "table". Extending the input sheet with another row > automatically extends the output sheet by a row (and if you have rollup > then we get more than one row). Intermediate sheets could be replaced by > a function definition. > > It's a bit of an ergonomic challenge; functions are much more abstract, > and users will want to see how the results of applying a function to an > input area look like. So the mental model might be that we still have > intermediate sheets, but with just a single function, and the > intermediate sheets can be create, destroyed, shown and hidden easily. > > The other challenge would be dealing with headers. Headers are > important, but for the intermediate we have just the function so it > needs to provide the headers. I.e. the function result would have to be > a named tuple, and if you want multiline headers, we get a hierarchical > named tuple. > Manipulating the column order would also manipulate the tuple > definition, i.e. you'd have to think about how GUI manipulation affects > the function definition. > > > (No longer Haskell discussion, but anything civil goes in Cafe) > > Sounds both interesting and relevant, but I don't quite get it. Can you > provide a simple, concrete, narrative example--with pictures (ASCII > OK)--if possible. Nah, I'm only good at walls of text. And at answering directed questions - start asking about what exactly you didn't understand. Guessing what you might have not understood is going to be a waste of everybody's time. (Besides, if you need to tell where exactly you didn't understand may help your understanding. Well, the keyword being "may"; I know it worked for me on various occasions.) > There's pivot tables, so the difference between row and column isn't as > clear-cut as the above assumes. > > Don't worry about pivot tables. Simple cases first. You have to design for the maximum complication. Otherwise, stuff will not fit in well, and you'll be stuck with either a half-assed solution, nothing at all, or a full rewrite. Trust me. I've been coding and designing software for decades. > There are a few more things to consider. It's firmly in the GUI > ergonomics area. > For this kind of stuff, you don't care whether the programming language > evaluation semantics matches the problem domain (spreadsheet functional > semantics is easy to do in any language, it was done in Assembler with > Lotus 1-2-3), you care whether it is easy to prototype GUI approaches, > which means GUI libraries that make it easy to create new widgets. > > Any suggestions for a GUI library--that kind of implies C++ or Java. > Ideally your GUI would be cross platform. I know only the Java GUI landscape well enough to say anything. In that area, dialog boxes, menus and such will be easy enough with any lib, but you'll be mostly on your own for the grid. Also if you aim for unlimited size you'll get into a lot of hairy memory management issues - a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and you end with a memory footprint of a gigabyte. Evaluating a formula for each cell is going to get you a slideshow-like performance. So... managing which cells are actually needed and which aren't is going to be a major point of the software. Did I mention that coding a spreadsheet is a huge project? ;-) > > Programmers have to learn multiple languages, and most wind up liking > > it. They also have favorite languages. LibreOffice Calc has about > four > > bolt-on languages. As I recall, none of them are a functional > > programming language. Maybe a few programmers should get together and > > add one as a sub-project. > > The problem is that any additional language needs to be installed. So > either the new language needs to be integrated in the LO project, or it > is not and anybody who passes on a spreadsheet in the new language needs > to tell the recipients how to install the plugin for the language. > > Maybe that's the reason why only the four languages exist. > > Doubt it. > > A given plugin's installation could be automated and check for dependencies. Heh. Famous last words. The Java folks got a 90% solution working - just for managing dependencies, mind you; for some people it doesn't work at all because they don't know how to get past the corporate firewall. Besides, most corporate firewalls do a man-in-the-middle certificate nowadays and will inspect and reject some packets and not others, so any update mechanism must be able to deal with wilfully unreliable internet connections. So that's another area that's going to bind a lot of developer resources. From ben at well-typed.com Tue Nov 21 22:00:36 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Nov 2017 17:00:36 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 released Message-ID: <878tezfg1u.fsf@ben-laptop.smart-cactus.org> =============================================== The Glasgow Haskell Compiler -- version 8.2.2 =============================================== The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. Notable bug-fixes include * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html How to get it ~~~~~~~~~~~~~ This release can be downloaded from https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Tue Nov 21 22:31:53 2017 From: ben at well-typed.com (Ben Gamari) Date: Tue, 21 Nov 2017 17:31:53 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 released In-Reply-To: <878tezfg1u.fsf@ben-laptop.smart-cactus.org> References: <878tezfg1u.fsf@ben-laptop.smart-cactus.org> Message-ID: <8760a3femx.fsf@ben-laptop.smart-cactus.org> Ben Gamari writes: > A thorough list of the changes in the release can be found in the release > notes, > > https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html > For the record this link was incorrect. It should be https://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/8.2.2-notes.html My apologies for the confusion. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From trent.shipley at gmail.com Wed Nov 22 05:06:47 2017 From: trent.shipley at gmail.com (trent shipley) Date: Wed, 22 Nov 2017 05:06:47 +0000 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: <0aaf8e53-f20b-baab-4f30-83275c1b753a@durchholz.org> References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> <0aaf8e53-f20b-baab-4f30-83275c1b753a@durchholz.org> Message-ID: On Tue, Nov 21, 2017 at 1:50 PM Joachim Durchholz wrote: > Am 21.11.2017 um 08:13 schrieb trent shipley: > > Which one it is that you are interested in? > > "Three-dimensional" as in "we have row, column, and layer", or as in > "we > > have hierarchical workbooks"? > > > > They are not mutually exclusive. A workbook can contain sheets--just > > like now. IN ADDITION, you can put workbooks in workbooks, until you > > reach the root workbook, which is also a file. > > Not an answer that helps me understand your point. > One more try. +---+---+ | | | Sheet. 2d. rows & colums. +---+---+ | | | +---+---+ +---+---+ / / /| +---+---+ + / / /|/| +---+---+ + + | | |/|/ Worksheet or Virtual Worksheet. 3d. +---+---+ + Stacked sheets. Maximum for mainstream spreadsheets | | |/ +---+---+ root workbook (file) +---------------------------------------+ | +---+---+ +---+---+ | | [0] / / /| / / /| [1] | | +---+---+ + +---+---+ + | | / / /|/| / / /|/| | | +---+---+ + + +---+---+ + + | | | | |/|/ | | |/|/ | | +---+---+ + +---+---+ + | | | | |/ | | |/ | | +---+---+ +---+---+ | | | +---------------------------------------+ File workbook "root" contains, rectangular (not jagged) virtual workbooks 0 and 1. It is 4d. Assuming a theoretical infinte machine, a root workbook could contain virtual workbook containers that contain virtual workbooks to an arbitrary depth. Virtual workbooks can contain either sheets, or virtual workbooks (or, at the application designer's option, both sheets and virtual workbooks. A virtual workbook is just a container. Like arrays or matrixes virtual workbooks are a convenient way to model n-dimensions. Note, that it would be convenient if the spreadsheet application numbered columns, rows, sheets, and virtual workbooks by default instead of naming sheets like Excel seems to do. If you were to allow function libraries or objects in a spreadsheet application you could store them in workbooks or virtual workbooks, extending the concept of putting a proper function in sheet marked with the function property. ------------------------------------------------------- > > > Also, if sheets can be marked as being functions, virtual > > workbooks can > > > support libraries of functions, or objects, if you want such > things. > > > > Sometimes I think Excel etc. got it all wrong. > > People routinely reserve areas inside the spreadsheet for different > > tasks: input, intermediate results, output. Increasing the size of > each > > area becomes a pain. > You would need some objects. The idea of linked areas. I'm guessing that Excel tables, kinda do this, but only for one contiguous area on one sheet. > > > > I'd want to have a spreadsheet where it's easy to define multiple > sheets > > on the same "table". Extending the input sheet with another row > > automatically extends the output sheet by a row (and if you have > rollup > > then we get more than one row). So this would be a three dimensional Excel table basically? It would involve the program taking a best guess at what you want in a lot of cases. > Intermediate sheets could be replaced by > > a function definition. > > > > It's a bit of an ergonomic challenge; functions are much more > abstract, > > and users will want to see how the results of applying a function to > an > > input area look like. So the mental model might be that we still have > > intermediate sheets, but with just a single function, It has been suggested that you can write functions when you would want a complex chain of calculations. You would call the function like any other function. You would still have cell by cell replication, but the user defined function would be defined one, and called many times. How would you bind one function to a column/row/range. You would need a visual representation of the binding. Current spreadsheets don't do that. (Except Emacs Org Mode spreadsheets have column functions.) In the existing paradigm, you would try your best to generate a plausible solution, then copy it to each cell in the new range in the calculation layer(s). My intuition is to get that working, THEN conquer the single function bound to many cells problem. > and the > > intermediate sheets can be create, destroyed, shown and hidden > easily. > Are you hoping to autogenerate the functions? Data -> range bound mono-function on intermediate function page -> Results > The other challenge would be dealing with headers. Headers are > > important, but for the intermediate we have just the function so it > > needs to provide the headers. I.e. the function result would have to > be > > a named tuple, and if you want multiline headers, we get a > hierarchical > > named tuple. > Concatenated names, generated functions get numbers added to the concatenated name. I don't think you can make the names you generate terribly pretty or human readable. The intermediate function guessed and generated for the addition isn't transient, it's durable data too. > > Manipulating the column order would also manipulate the tuple > > definition, i.e. you'd have to think about how GUI manipulation > affects > > the function definition. > That's more heuristics, and UX/UI testing. Excel guesses wrong on this frequently, and when it does it's a pain. But mostly it's behaves well. I'd want to leverage the current engine that deals with GUI implications for the model. I'm still not certain I'm on the same page as you, but that's a little more effort. > > > > (No longer Haskell discussion, but anything civil goes in Cafe) > > > > Sounds both interesting and relevant, but I don't quite get it. Can you > > provide a simple, concrete, narrative example--with pictures (ASCII > > OK)--if possible. > > Nah, I'm only good at walls of text. > And at answering directed questions - start asking about what exactly > you didn't understand. > Guessing what you might have not understood is going to be a waste of > everybody's time. > (Besides, if you need to tell where exactly you didn't understand may > help your understanding. Well, the keyword being "may"; I know it worked > for me on various occasions.) > > > There's pivot tables, so the difference between row and column isn't > as > > clear-cut as the above assumes. > > > > Don't worry about pivot tables. Simple cases first. > > You have to design for the maximum complication. > Otherwise, stuff will not fit in well, and you'll be stuck with either a > half-assed solution, nothing at all, or a full rewrite. > Trust me. I've been coding and designing software for decades. > > > There are a few more things to consider. It's firmly in the GUI > > ergonomics area. > > For this kind of stuff, you don't care whether the programming > language > > evaluation semantics matches the problem domain (spreadsheet > functional > > semantics is easy to do in any language, it was done in Assembler > with > > Lotus 1-2-3), you care whether it is easy to prototype GUI > approaches, > > which means GUI libraries that make it easy to create new widgets. > > > > Any suggestions for a GUI library--that kind of implies C++ or Java. > > Ideally your GUI would be cross platform. > > I know only the Java GUI landscape well enough to say anything. > In that area, dialog boxes, menus and such will be easy enough with any > lib, but you'll be mostly on your own for the grid. Also if you aim for > unlimited size you'll get into a lot of hairy memory management issues - > a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and > you end with a memory footprint of a gigabyte. Evaluating a formula for > each cell is going to get you a slideshow-like performance. > https://en.wikipedia.org/wiki/List_of_spreadsheet_software With the usual cautions about Wikipedia, there is a chart relevant to your argument on this page. It's probably really out of date. Does anyone know anything about Lotus Improv or Flexisheet? > So... managing which cells are actually needed and which aren't is going > to be a major point of the software. > > Did I mention that coding a spreadsheet is a huge project? ;-) > > > > Programmers have to learn multiple languages, and most wind up > liking > > > it. They also have favorite languages. LibreOffice Calc has about > > four > > > bolt-on languages. As I recall, none of them are a functional > > > programming language. Maybe a few programmers should get together > and > > > add one as a sub-project. > > > > The problem is that any additional language needs to be installed. So > > either the new language needs to be integrated in the LO project, or > it > > is not and anybody who passes on a spreadsheet in the new language > needs > > to tell the recipients how to install the plugin for the language. > > > > Maybe that's the reason why only the four languages exist. > > > > Doubt it. > > > > A given plugin's installation could be automated and check for > dependencies. > > Heh. Famous last words. > The Java folks got a 90% solution working - just for managing > dependencies, mind you; for some people it doesn't work at all because > they don't know how to get past the corporate firewall. Besides, most > corporate firewalls do a man-in-the-middle certificate nowadays and will > inspect and reject some packets and not others, so any update mechanism > must be able to deal with wilfully unreliable internet connections. > > So that's another area that's going to bind a lot of developer resources. > The last few companies I've worked for had the policy: IT owns your tech. DON'T put software on it. If you need software we haven't given you, you don't really need it, but if you really, really need it, then it will go to the change committee who will evaluate your request, audit the software you want for security threats, price, and maintainability, and MIGHT give it to you in several months, if you are lucky. I can't imagine trying to maintain my own software stack it a big enterprise. That's some poor sys admin's job. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 aquagnu at gmail.com Wed Nov 22 09:12:58 2017 From: aquagnu at gmail.com (PY) Date: Wed, 22 Nov 2017 11:12:58 +0200 Subject: [Haskell-cafe] Arrows and streaming/piping Message-ID: <57516454-8398-ecc0-b8ac-33eeb7296acd@gmail.com> Hello, Cafe! There is a statement that Arrows can be used as streaming approach. Arrows are very new for me, so my question may looks stupid, but would somebody show me clean and simple example how it will look? Lets suppose we have function `getLines` which returns `IO [String]`, a lot of lines :) And I want to process them as I do it with streaming library (or pipes) - with constant space. If it's true, then I can use Arrows instead of pipes, right? === Best regards, Paul From sivanov at colimite.fr Wed Nov 22 10:46:16 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 22 Nov 2017 11:46:16 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> Message-ID: <87lgiyr3pj.fsf@colimite.fr> Hello Trent, Thus quoth trent shipley on Tue Nov 21 2017 at 03:52 (+0100): > On Mon, Nov 20, 2017 at 7:23 AM Sergiu Ivanov wrote: > >> Hello Trent, >> >> Thus quoth trent shipley on Sun Nov 19 2017 at 12:12 (+0100): >> >> > 1. It would be an interesting exercise in itself, and if it hadn't >> been >> > done before, might be worth a paper. (I submit that this is actually >> a real >> > use case.) >> >> That's a good and a fun use case, but it's probably not going to attract >> a lot of developers/maintainers. > > No it wouldn't I suppose. It would be a way to get it started, and to > explore new possibilities, but the academic use case certainly won't > produce stability. Actually a few fully functional spreadsheets have been > developed, mostly to explore the spreadsheet as a visual programming tool, > or human computer interaction. "Spreadsheet Implementation Technology: > Basics and Extensions", Peter > Sestoft, MIT Press. may provide fully functional spreadsheets for hacking > (maybe based on Forms/3 > http://web.engr.oregonstate.edu/~burnett/Forms3/forms3.html, at least in > part. Forms/3 was M Burrnett's spreadsheet for HCI research.) That looks like an interesting reference, thank you, I'll try giving it a look. >> Multidimensionality seems to be a really important point in your >> project. On the other hand, without having any specialised knowledge in >> spreadsheet-crunching, I'm tempted to suppose that what these scientist >> need is quite below Turing completeness, once multidimensionality is >> provided. >> >> > I should be more careful with the distinction between multidimensional > spreadsheets and n-dimensional spreadsheets. Multidimensional spreadsheets > like Lotus Improv and Lighthouse Design's Quantrix (based on Improv and ran > on Steve Job's NextStep) were spreadsheets with a sophisticated way to > model data that was called "multidimensional", that is not what I am > referring to. OK, I see. > Assume an additional level to the spreadsheet's organization between a > workbook and a sheet called a "virtual workbook". A root (file) workbook > can contain virtual workbooks or sheets. A virtual workbook can also > contain virtual work books or sheets. Sheets are 3-dimensional, and then > you're done, but virtual workbooks can be nested as deeply as desired, so a > spreadsheet with virtual workbooks could model n-dimensions. OK, so you have an arbitrary tree, at the leaves of which there are 3-dimensional sheets. I've never heard of any spreadsheet application capable of doing that. > Also, if sheets can be marked as being functions, virtual workbooks can > support libraries of functions, or objects, if you want such things. I see, you probably want some kind of first-class sheets in your language (modules/libraries of sheets, etc.) >> Do you think a semi-programmable (as in LibreOffice) multidimensional >> spreadsheet may cut it for them? >> > > Might. > > It might not for finance. OK, I see, noted. > https://arxiv.org/abs/0909.2452 > > > See also: > http://www.eusprig.org/index.htm > http://www.eusprig.org/best-practice.htm > > I have to admit I haven't poked around as much as I should before passing > these references on. All right, I must admit I didn't know there were so many people discussing spreadsheets, although that shouldn't come as a surprise given the widespread use of this tool. Thank you for the references. >> Your argument is probably based on way more experience than mine, but >> personally I don't at all aspire to have a homogeneous language >> environment. I actually like the separation in Excel: formulas for >> almost any operations; VBA when real muscle-power is inevitable. >> >> That was my two-cent addition to the brainstorming :-) >> > > S Jones, M Burnett, and A Blackwell called this (disparagingly) "the trap > door model". It has also been called the "bolt on" model. It's not that > bad. It does require two sets of knowledge, and rather separate skill > sets. I'm really not that hostile to it. It works, but I do like to have > more than one way to do things. A fully functional spreadsheet would be a > nice alternative. I see. > Programmers have to learn multiple languages, and most wind up liking > it. That raises an important point: is your target audience programmers or finance wizards? Finance wizards will probably not like learning multiple languages, but you are probably aiming at being more general. >> Now, I may be mistaken and you may have a very clear idea of an >> implementation, in which case my suggestions are simply redundant. >> > > If implementation means "how to program it", I have no idea. > > If implementation means refining a proposal, and leading into a functional > spec, then, yes, I am working on that. Up to now mostly in my own head, > which is why I'm seeking input, validation, and criticism. Depending, I'll > go back and refine what I have. Yeah, that's what I meant. Thanks for sharing your ideas :-) >> > Also, if speed is of the essence, my impression is that C++ and C come to >> > the fore. >> >> Yes, but overoptimisation along one criterion among many is also an >> issue. The trade-off between faster code or code easier to maintain is >> a difficult one. >> > > Financiers' market trading code is notorious for being time critical, they > are trying to beat other trading companies to the market. I see. I'll probably tend to agree with what Joachim said in a later message, but I can't have an educated opinion given that I've never worked in time-critical systems. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sivanov at colimite.fr Wed Nov 22 10:48:12 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 22 Nov 2017 11:48:12 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> Message-ID: <87k1yir3mb.fsf@colimite.fr> Thus quoth Joachim Durchholz on Tue Nov 21 2017 at 07:45 (+0100): >> >> But then you're are right, C++ and C are often quite in the lead in what >> concerns speed (even though some tweaks may bring other programming >> languages quite close [1]). > > I think one of the important factors is how much coder effort is needed > to get that kind of performance. > The trade-off seems to be how much coder effort is needed to get the > code correct. I definitely agree. I'd even say: "to get the code correct and to maintain its correctness over future updates". > From what I hear: > C++ gives easy and predictable performance (if you code for that), while > being somewhat unpredictable on correctness. > Haskell excels at correctness, gives reasonable but not very predictable > performance. > Java is predictable with correctness though not excellent, and > predictable with performance though not excellent. I like this chart, thank you :-) -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mike at barrucadu.co.uk Wed Nov 22 17:22:58 2017 From: mike at barrucadu.co.uk (Michael Walker) Date: Wed, 22 Nov 2017 17:22:58 +0000 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? Message-ID: Hello, Can reallyUnsafePtrEquality give false positives? I can see how it can give false negatives (eg, compiler optimisations increasing or decreasing sharing), but I'm not so sure if it can give false positives. I don't see how in a garbage collected language two live values could compare reference equal. Unless the implementation is something like: reallyUnsafePtrEquality a b = getptr a == getptr b ...as that then means that if the GC moves things after `getptr a` is evaluated but before `getptr b` is, then you could get a false positive. But that doesn't seem like a sensible implementation to me, because then reallyUnsafePtrEquality would surely be totally useless. -- Michael Walker (http://www.barrucadu.co.uk) From andrew.thaddeus at gmail.com Wed Nov 22 19:06:50 2017 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Wed, 22 Nov 2017 14:06:50 -0500 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: Message-ID: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> It cannot give false positives. If it could, that would make it totally worthless. Sent from my iPhone > On Nov 22, 2017, at 12:22 PM, Michael Walker wrote: > > Hello, > > Can reallyUnsafePtrEquality give false positives? I can see how it > can give false negatives (eg, compiler optimisations increasing or > decreasing sharing), but I'm not so sure if it can give false > positives. > > I don't see how in a garbage collected language two live values could > compare reference equal. Unless the implementation is something like: > > reallyUnsafePtrEquality a b = getptr a == getptr b > > ...as that then means that if the GC moves things after `getptr a` is > evaluated but before `getptr b` is, then you could get a false > positive. But that doesn't seem like a sensible implementation to me, > because then reallyUnsafePtrEquality would surely be totally useless. > > -- > Michael Walker (http://www.barrucadu.co.uk) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From hesselink at gmail.com Wed Nov 22 19:12:49 2017 From: hesselink at gmail.com (Erik Hesselink) Date: Wed, 22 Nov 2017 20:12:49 +0100 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: According to Edwark Kmett it can give false positives as well, or at least could in 2010: https://mail.haskell.org/pipermail/haskell-cafe/2010-June/079532.html Erik On 22 November 2017 at 20:06, Andrew Martin wrote: > It cannot give false positives. If it could, that would make it totally > worthless. > > Sent from my iPhone > > > On Nov 22, 2017, at 12:22 PM, Michael Walker > wrote: > > > > Hello, > > > > Can reallyUnsafePtrEquality give false positives? I can see how it > > can give false negatives (eg, compiler optimisations increasing or > > decreasing sharing), but I'm not so sure if it can give false > > positives. > > > > I don't see how in a garbage collected language two live values could > > compare reference equal. Unless the implementation is something like: > > > > reallyUnsafePtrEquality a b = getptr a == getptr b > > > > ...as that then means that if the GC moves things after `getptr a` is > > evaluated but before `getptr b` is, then you could get a false > > positive. But that doesn't seem like a sensible implementation to me, > > because then reallyUnsafePtrEquality would surely be totally useless. > > > > -- > > Michael Walker (http://www.barrucadu.co.uk) > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Nov 22 19:15:23 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 22 Nov 2017 14:15:23 -0500 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: Actually, I'd say that it can, but only if used incorrectly. Which is why it's reallyUnsafe. The OP is correct in that a gc at the wrong time can lead to spurious positives. The key to this is that, if you force everything to be evaluated to WHNF (so you actually have the pointers) and then gc, you have some determinacy as to when the next gc will happen: force to WHNF first, gc, make sure any subsequent operations between that and your reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and in this case, you can trust the result. So it requires a fair amount of care, but there is a window in which it is safe. On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin wrote: > It cannot give false positives. If it could, that would make it totally > worthless. > > Sent from my iPhone > > > On Nov 22, 2017, at 12:22 PM, Michael Walker > wrote: > > > > Hello, > > > > Can reallyUnsafePtrEquality give false positives? I can see how it > > can give false negatives (eg, compiler optimisations increasing or > > decreasing sharing), but I'm not so sure if it can give false > > positives. > > > > I don't see how in a garbage collected language two live values could > > compare reference equal. Unless the implementation is something like: > > > > reallyUnsafePtrEquality a b = getptr a == getptr b > > > > ...as that then means that if the GC moves things after `getptr a` is > > evaluated but before `getptr b` is, then you could get a false > > positive. But that doesn't seem like a sensible implementation to me, > > because then reallyUnsafePtrEquality would surely be totally useless. > > > > -- > > Michael Walker (http://www.barrucadu.co.uk) > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- 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 siddu.druid at gmail.com Wed Nov 22 19:22:09 2017 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Wed, 22 Nov 2017 19:22:09 +0000 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: This is out of curiosity: does the runtime actually provide guarantees about when the GC must kick in? Or is this implementation defined but common knowledge? Thanks, Siddharth On Wed 22 Nov, 2017, 20:20 Brandon Allbery, wrote: > Actually, I'd say that it can, but only if used incorrectly. Which is why > it's reallyUnsafe. > > The OP is correct in that a gc at the wrong time can lead to spurious > positives. The key to this is that, if you force everything to be evaluated > to WHNF (so you actually have the pointers) and then gc, you have some > determinacy as to when the next gc will happen: force to WHNF first, gc, > make sure any subsequent operations between that and your > reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and > in this case, you can trust the result. So it requires a fair amount of > care, but there is a window in which it is safe. > > On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin > wrote: > >> It cannot give false positives. If it could, that would make it totally >> worthless. >> >> Sent from my iPhone >> >> > On Nov 22, 2017, at 12:22 PM, Michael Walker >> wrote: >> > >> > Hello, >> > >> > Can reallyUnsafePtrEquality give false positives? I can see how it >> > can give false negatives (eg, compiler optimisations increasing or >> > decreasing sharing), but I'm not so sure if it can give false >> > positives. >> > >> > I don't see how in a garbage collected language two live values could >> > compare reference equal. Unless the implementation is something like: >> > >> > reallyUnsafePtrEquality a b = getptr a == getptr b >> > >> > ...as that then means that if the GC moves things after `getptr a` is >> > evaluated but before `getptr b` is, then you could get a false >> > positive. But that doesn't seem like a sensible implementation to me, >> > because then reallyUnsafePtrEquality would surely be totally useless. >> > >> > -- >> > Michael Walker (http://www.barrucadu.co.uk) >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > 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. -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Nov 22 19:24:39 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 22 Nov 2017 14:24:39 -0500 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: yeah, and if you look at how its generated, its pretty safe with some care (though still unsafe) https://github.com/ghc/ghc/blob/314bc31489f1f4cd69e913c3b1e33236b2bdf553/compiler/prelude/primops.txt.pp#L2644 and https://github.com/ghc/ghc/blob/ec080ea1f160263282500b30444cb2db857f2f93/compiler/codeGen/StgCmmPrim.hs#L358 are the two places in question :) On Wed, Nov 22, 2017 at 2:15 PM, Brandon Allbery wrote: > Actually, I'd say that it can, but only if used incorrectly. Which is why > it's reallyUnsafe. > > The OP is correct in that a gc at the wrong time can lead to spurious > positives. The key to this is that, if you force everything to be evaluated > to WHNF (so you actually have the pointers) and then gc, you have some > determinacy as to when the next gc will happen: force to WHNF first, gc, > make sure any subsequent operations between that and your > reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and > in this case, you can trust the result. So it requires a fair amount of > care, but there is a window in which it is safe. > > On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin > wrote: > >> It cannot give false positives. If it could, that would make it totally >> worthless. >> >> Sent from my iPhone >> >> > On Nov 22, 2017, at 12:22 PM, Michael Walker >> wrote: >> > >> > Hello, >> > >> > Can reallyUnsafePtrEquality give false positives? I can see how it >> > can give false negatives (eg, compiler optimisations increasing or >> > decreasing sharing), but I'm not so sure if it can give false >> > positives. >> > >> > I don't see how in a garbage collected language two live values could >> > compare reference equal. Unless the implementation is something like: >> > >> > reallyUnsafePtrEquality a b = getptr a == getptr b >> > >> > ...as that then means that if the GC moves things after `getptr a` is >> > evaluated but before `getptr b` is, then you could get a false >> > positive. But that doesn't seem like a sensible implementation to me, >> > because then reallyUnsafePtrEquality would surely be totally useless. >> > >> > -- >> > Michael Walker (http://www.barrucadu.co.uk) >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > 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 allbery.b at gmail.com Wed Nov 22 19:25:24 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 22 Nov 2017 14:25:24 -0500 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: There's some other complications here as well. Threads by default get their own nurseries, so you have such a safe window even in threaded programs --- but if another thread allocates enough (and subject to RTS options, IIRC -n matters here?) it could fill its nursery, and the RTS notices your thread's nursery is mostly unused and let the other thread start allocating from your nursery and shrink your safe window. (Also, it looks to me like 8.2's runtime changed some things; I thought there was an option explicitly specifying/controlling the separate-nurseries behavior, but I didn't see it in checking through the runtime options just now.) On Wed, Nov 22, 2017 at 2:15 PM, Brandon Allbery wrote: > Actually, I'd say that it can, but only if used incorrectly. Which is why > it's reallyUnsafe. > > The OP is correct in that a gc at the wrong time can lead to spurious > positives. The key to this is that, if you force everything to be evaluated > to WHNF (so you actually have the pointers) and then gc, you have some > determinacy as to when the next gc will happen: force to WHNF first, gc, > make sure any subsequent operations between that and your > reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and > in this case, you can trust the result. So it requires a fair amount of > care, but there is a window in which it is safe. > > On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin > wrote: > >> It cannot give false positives. If it could, that would make it totally >> worthless. >> >> Sent from my iPhone >> >> > On Nov 22, 2017, at 12:22 PM, Michael Walker >> wrote: >> > >> > Hello, >> > >> > Can reallyUnsafePtrEquality give false positives? I can see how it >> > can give false negatives (eg, compiler optimisations increasing or >> > decreasing sharing), but I'm not so sure if it can give false >> > positives. >> > >> > I don't see how in a garbage collected language two live values could >> > compare reference equal. Unless the implementation is something like: >> > >> > reallyUnsafePtrEquality a b = getptr a == getptr b >> > >> > ...as that then means that if the GC moves things after `getptr a` is >> > evaluated but before `getptr b` is, then you could get a false >> > positive. But that doesn't seem like a sensible implementation to me, >> > because then reallyUnsafePtrEquality would surely be totally useless. >> > >> > -- >> > Michael Walker (http://www.barrucadu.co.uk) >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Nov 22 19:31:20 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 22 Nov 2017 14:31:20 -0500 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: Actually, the current -n looks like a generalization of what I remember being there --- and one that re-adds safety, since instead of "scavenging" off another thread's nursery, the exhausting thread gets another chunk of nursery for itself if one is available. On Wed, Nov 22, 2017 at 2:25 PM, Brandon Allbery wrote: > There's some other complications here as well. Threads by default get > their own nurseries, so you have such a safe window even in threaded > programs --- but if another thread allocates enough (and subject to RTS > options, IIRC -n matters here?) it could fill its nursery, and the RTS > notices your thread's nursery is mostly unused and let the other thread > start allocating from your nursery and shrink your safe window. > > (Also, it looks to me like 8.2's runtime changed some things; I thought > there was an option explicitly specifying/controlling the > separate-nurseries behavior, but I didn't see it in checking through the > runtime options just now.) > > On Wed, Nov 22, 2017 at 2:15 PM, Brandon Allbery > wrote: > >> Actually, I'd say that it can, but only if used incorrectly. Which is why >> it's reallyUnsafe. >> >> The OP is correct in that a gc at the wrong time can lead to spurious >> positives. The key to this is that, if you force everything to be evaluated >> to WHNF (so you actually have the pointers) and then gc, you have some >> determinacy as to when the next gc will happen: force to WHNF first, gc, >> make sure any subsequent operations between that and your >> reallyUnsafePtrEquality either don't allocate or fit in the nursery --- and >> in this case, you can trust the result. So it requires a fair amount of >> care, but there is a window in which it is safe. >> >> On Wed, Nov 22, 2017 at 2:06 PM, Andrew Martin > > wrote: >> >>> It cannot give false positives. If it could, that would make it totally >>> worthless. >>> >>> Sent from my iPhone >>> >>> > On Nov 22, 2017, at 12:22 PM, Michael Walker >>> wrote: >>> > >>> > Hello, >>> > >>> > Can reallyUnsafePtrEquality give false positives? I can see how it >>> > can give false negatives (eg, compiler optimisations increasing or >>> > decreasing sharing), but I'm not so sure if it can give false >>> > positives. >>> > >>> > I don't see how in a garbage collected language two live values could >>> > compare reference equal. Unless the implementation is something like: >>> > >>> > reallyUnsafePtrEquality a b = getptr a == getptr b >>> > >>> > ...as that then means that if the GC moves things after `getptr a` is >>> > evaluated but before `getptr b` is, then you could get a false >>> > positive. But that doesn't seem like a sensible implementation to me, >>> > because then reallyUnsafePtrEquality would surely be totally useless. >>> > >>> > -- >>> > Michael Walker (http://www.barrucadu.co.uk) >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > To (un)subscribe, modify options or view archives go to: >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> > Only members subscribed via the mailman list are allowed to post. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > -- 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 monkleyon at gmail.com Wed Nov 22 19:39:05 2017 From: monkleyon at gmail.com (MarLinn) Date: Wed, 22 Nov 2017 20:39:05 +0100 Subject: [Haskell-cafe] Arrows and streaming/piping In-Reply-To: <57516454-8398-ecc0-b8ac-33eeb7296acd@gmail.com> References: <57516454-8398-ecc0-b8ac-33eeb7296acd@gmail.com> Message-ID: <047fb4a6-0e89-1e1c-b86a-6a391836aa86@gmail.com> Hi Paul. > There is a statement that Arrows can be used as streaming approach. > Arrows are very new for me, so my question may looks stupid, but would > somebody show me clean and simple example how it will look? Lets > suppose we have function `getLines` which returns `IO [String]`, a lot > of lines :) And I want to process them as I do it with streaming > library (or pipes) - with constant space. > > If it's true, then I can use Arrows instead of pipes, right? No. Or rather maybe. But mostly no. Arrows are just a particular way to write and think about code. You can structure a library to be particularly well suited to arrows, but what a library does and how you use it is completely orthogonal. When people say arrows are suitable for a streaming approach, what they often mean is that thinking in terms of arrows and thinking in terms of streams are compatible. That means that no amount of arrows will help you stream your data. And if you use a streaming library that's optimised for arrows, you can forego the arrows if you want. In fact arrows have fallen out of favour with most Haskell programmers because (1) you can get almost all their advantages with just Applicatives and (2) many things Arrow syntax would be great for can't be implemented with how the Arrow hierarchy is currently structured and desugared. For that reason I don't think any modern streaming library will rely on arrows. That being said, to help you with the need for streams, might I point you to the excellent conduit-library. It's a bit complex to learn, but their github (https://github.com/snoyberg/conduit) has a rather impressive introduction. Cheers, MarLinn From jo at durchholz.org Wed Nov 22 21:06:03 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 22 Nov 2017 22:06:03 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet In-Reply-To: References: <87a7zitutt.fsf@colimite.fr> <871sktt4ft.fsf@colimite.fr> <0aaf8e53-f20b-baab-4f30-83275c1b753a@durchholz.org> Message-ID: <7f6c05ce-45c9-daf7-0cd9-aabb19b6624d@durchholz.org> Am 22.11.2017 um 06:06 schrieb trent shipley: > On Tue, Nov 21, 2017 at 1:50 PM Joachim Durchholz > wrote: > > Am 21.11.2017 um 08:13 schrieb trent shipley: > >     Which one it is that you are interested in? > >     "Three-dimensional" as in "we have row, column, and layer", > or as in "we > >     have hierarchical workbooks"? > > > > They are not mutually exclusive. A workbook can contain sheets--just > > like now. IN ADDITION, you can put workbooks in workbooks, until you > > reach the root workbook, which is also a file. > > Not an answer that helps me understand your point. > > > One more try. So you mean you want both. Not sure how useful a 3D sheet is. It's too abstract for those who need the visual feedback, and not powerful for those who deal with abstractions. A hierarchy of sheets is pretty useful in my book. I think the main problem for me was that you didn't spell out clearly which part of your description related to existing concepts and which was new, which one was desirable and which one was not interesting to you. (Defining what's NOT in a project is often the most important task when outlining it.) > Note, that it would be convenient if the spreadsheet application > numbered columns, rows, sheets, and virtual workbooks by default instead > of naming sheets like Excel seems to do. Excel has the problem that there is no uniform naming convention for a cell. An address that includes the sheet name looks and acts in a pretty different fashion than one that's in a cell. > If you were to allow function libraries or objects in a spreadsheet > application you could store them in workbooks or virtual workbooks, > extending the concept of putting a proper function in sheet marked with > the function property. I don't see what problem is being solved with that. But then I do not really share your vision it seems, so it's okay. > ------------------------------------------------------- > > > >      > Also, if sheets can be marked as being functions, virtual > >     workbooks can > >      > support libraries of functions, or objects, if you want > such things. > > > >     Sometimes I think Excel etc. got it all wrong. > >     People routinely reserve areas inside the spreadsheet for > different > >     tasks: input, intermediate results, output. Increasing the > size of each > >     area becomes a pain. > > You would need some objects.  The idea of linked areas. I'm guessing > that Excel tables, kinda do this, but only for one contiguous area on > one sheet. Exactly. > >     I'd want to have a spreadsheet where it's easy to define > multiple sheets > >     on the same "table". Extending the input sheet with another row > >     automatically extends the output sheet by a row (and if you > have rollup > >     then we get more than one row). > > So this would be a three dimensional Excel table basically? It would > involve the program taking a best guess at what you want in a lot of cases. No, what I described above is entirely within the 2d area. Though it should extend naturally to an arbitary number of dimensions. Not because I find multiple dimensions a killer feature, but it should be there for those who need it. Plus this removes the somewhat arbitrary definitions of a cell address, which in Excel is "the file or data source name, the sheet name, and exactly two numbered coordinates". Plus all kinds of extra ad-hockery to integrade ODBC data sources (which is useful but requires jumping through extra hoops to get a complete definition of "what is a cell address"). > Intermediate sheets could be replaced by > >     a function definition. > > > >     It's a bit of an ergonomic challenge; functions are much more > abstract, > >     and users will want to see how the results of applying a > function to an > >     input area look like. So the mental model might be that we > still have > >     intermediate sheets, but with just a single function, > > It has been suggested that you can write functions when you would want a > complex chain of calculations. That's exactly my thinking. > How would you bind one function to a column/row/range. You would need a > visual representation of the binding. Current spreadsheets don't do > that. That's one of the major reasons why spreadsheets are such a maintenance nightmare. > (Except Emacs Org Mode spreadsheets have column functions.) > > In the existing paradigm, you would try your best to generate a > plausible solution, then copy it to each cell in the new range in the > calculation layer(s). My intuition is to get that working, THEN conquer > the single function bound to many cells problem. You will need a rewrite then. Well, that's just my intuition, based on a few decades of designing and coding software but even that much experience can lead one astray, so don't take just my word for it. > and the > >     intermediate sheets can be create, destroyed, shown and > hidden easily. > > Are you hoping to autogenerate the functions? No... rather the other way round: Have the user define a function (ideally without calling it that) and let him put that function into a column. CPU people call this the "SIMD model": SIMD = Single Instruction, Multiple Data. Or "vector operation". But don't mention that in the manual :-) It's pretty near to the GPU model of doing things. Though you wouldn't want to model that you cannot really look into what a GPU is doing and why, which you definitely don't want in a spreadsheet (and not in a GPU either if you're struggling to make it do what you wanted, instead of just painting the whole screen in pink and you don't know why). > Data -> range bound mono-function on intermediate function page -> Results I'm more after functions bound to columns. > >     The other challenge would be dealing with headers. Headers are > >     important, but for the intermediate we have just the function > so it > >     needs to provide the headers. I.e. the function result would > have to be > >     a named tuple, and if you want multiline headers, we get a > hierarchical > >     named tuple. > > > Concatenated names, generated functions get numbers added to the > concatenated name. I don't think you can make the names you generate > terribly pretty or human readable. I'm definitely not after anything autogenerated. Particularly not names. One could autogenerate a tuple definition from individual field names or something like that, but even then I wouldn't leave it to the user to give the thing a name. > The intermediate function guessed and generated for the addition isn't > transient, it's durable data too. I think we're not talking about the same concept here. No guessing, no name autogeneration. > >     Manipulating the column order would also manipulate the tuple > >     definition, i.e. you'd have to think about how GUI > manipulation affects > >     the function definition. > > > That's more heuristics, and UX/UI testing. Excel guesses wrong on this > frequently, and when it does it's a pain. But mostly it's behaves well. > I'd want to leverage the current engine that deals with GUI implications > for the model. If leveraging the existing engine were possible, Microsoft would have done it years ago. > I'm still not certain I'm on the same page as you, but that's a little > more effort. Probably not, no. > > Any suggestions for a GUI library--that kind of implies C++ or Java. > > Ideally your GUI would be cross platform. > > I know only the Java GUI landscape well enough to say anything. > In that area, dialog boxes, menus and such will be easy enough with any > lib, but you'll be mostly on your own for the grid. Also if you aim for > unlimited size you'll get into a lot of hairy memory management issues - > a 64kx64k grid has 1 million cells, multiply that with 1KB per cell and > you end with a memory footprint of a gigabyte. Evaluating a formula for > each cell is going to get you a slideshow-like performance. > > > > https://en.wikipedia.org/wiki/List_of_spreadsheet_software Spreadsheet software is definitely not a GUI library. But I guess I'm talking about a new spreadsheet software and you're talking about extending an existing one. As I said above, I don't think the latter will work. Anyway. We've been talking at cross-purposes for a while now, and I guess we have given each other enough keywords for our own thinking, but we're probably after too different things to make further discussions. I'm still open for questions to clarify a point, but I don't think I can help you much when it comes to elaborating project options. Regards, Jo From bertram.felgenhauer at googlemail.com Thu Nov 23 12:12:39 2017 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu, 23 Nov 2017 13:12:39 +0100 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> Message-ID: <20171123121239.GA29203@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Brandon Allbery wrote: > Actually, I'd say that it can, but only if used incorrectly. Which is why > it's reallyUnsafe. > > The OP is correct in that a gc at the wrong time can lead to spurious > positives. There will be no such GCs. Consider the type: reallyUnsafePtrEquality# :: a -> a -> Int# The operation takes two *Haskell values*, represented by pointers to the heap, and compares those pointers. (See also Carter Schonwald's mail.) The same code would also be allowed to dereference those pointers to find the tags of the corresponding heap objects, check whether they are constructors, and if so, read the corresponding values from the heap. In other words, if the identity of heap objects could be confused at this point, then perfectly ordinary compiled Haskell code could go wrong as well. The compiler and RTS ensure that the pointers that the pointer comparison sees are valid pointers for the Haskell values. (The story would be different if reallyUnsafePtrEquality# were implemented in terms of anyToAddr#.) So there are no false positives; if reallyUnsafePtrEquality# x y returned 1#, then x and y had a common corresponding heap object at the time. There is plenty of room for surprises and unsafety though: - Even if x and y compare as equal once, this may change later on. For example, with multiple threads running in parallel, a thunk may be evaluated several times, resulting in several results on the heap. - Extending the previous scenario, if purity is violated in the evaluation of the initially shared thunk, then x and y may become distinct values later on. - Even without parallelism, it is possible that after evaluating y, x points to an indirection on the heap and y to the evaluated value, resulting in distinct pointers (at least until the next GC). - Bottoms also complicate the picture. For example, if one uses pointer equality as an optimization in an Eq instance, one may find x == y by pointer equality once, just to later find that x == y bottoms out. The opposite scenario is also possible. So it's quite easy to violate purity this way. These scenarios can be mitigated by evaluating to WHNF first. [Note: No spurious positives by GCs] In current GHC, all garbage collections (even minor ones) stop execution of all Haskell threads; this is done by tweaking the heap check, and Haskell threads are not interrupted between heap checks. There is a design and an experimental implementation of "local garbage collections" in ghc, from 2011: https://ghc.haskell.org/trac/ghc/blog/new-gc-preview https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/local-gc.pdf In this case, garbage collections of nurseries would run in parallel to other Haskell threads. However, even in this design, reallyUnsafePtrEquality# would not have false positives. To quote from the paper, "the key invariant is that the processor that owns the local heap has exclusive access to its contents." (In one design there are actually two local heaps; there is a second, "sticky" heap that contains objects that other processors might see; however, these objects are pinned.) Cheers, Bertram From mike at barrucadu.co.uk Thu Nov 23 12:48:24 2017 From: mike at barrucadu.co.uk (Michael Walker) Date: Thu, 23 Nov 2017 12:48:24 +0000 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: <20171123121239.GA29203@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> <20171123121239.GA29203@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: Thanks for the feedback, all. For some more context, I have a concurrency testing library[1], which uses an algorithm called DPOR to reduce the space of possible schedules it needs to explore. There's an algorithm called MCR which has the potential to reduce this space significantly further. One of the differences in MCR is taking into account reference equality of values written to shared mutable variables. I can't just use Eq because (a) putMVar/etc doesn't have an Eq constraint in the type, and (b) that would change strictness. So I looked to reallyUnsafePtrEquality# as a possible solution. In this setting, false negatives are fine. If the algorithm thinks two equal values are distinct, then it doesn't run as fast as it could potentially do, but should still outperform DPOR due to its other improvements. But false positives are not fine, and lead to unsoundness. An alternative is just using "\_ _ -> False", but if reallyUnsafePtrEquality# will sometimes identify two equal things without false positives, then it's effectively a free performance boost in the cases where it happens to work. > - Extending the previous scenario, if purity is violated in the > evaluation of the initially shared thunk, then x and y may become > distinct values later on. Fortunately, I don't need to worry about impure actions leading to a shared thunk evaluating to different things in different places, as any nondeterminism beyond scheduler nondeterminism and relaxed memory is already explicitly out of scope. [1] http://hackage.haskell.org/package/dejafu -- Michael Walker (http://www.barrucadu.co.uk) From olf at aatal-apotheke.de Thu Nov 23 18:26:14 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 23 Nov 2017 19:26:14 +0100 Subject: [Haskell-cafe] Speculation, OT: Program a Spreadsheet Message-ID: Yesterday I read in a slashdot thread [1] about Javelin [2], which was available shorty after I was born and before Excel existed. Telling from the wikipedia article, it did what I dreamed up in my previous post: instead of sheets, each logical piece of data occupied its own "variable". (Trent's virtual worksheet might be the equivalent here?) It also make the connections between data browsable. Is there anyone on this list who used Javelin back then? Care to share your experience? Olaf [1] https://news.slashdot.org/story/17/11/22/1525254/stop-using-excel-finance-chiefs-tell-staffs [2] https://en.wikipedia.org/wiki/Javelin_Software From seanmatthews1 at gmail.com Thu Nov 23 22:11:28 2017 From: seanmatthews1 at gmail.com (Sean Matthews) Date: Thu, 23 Nov 2017 23:11:28 +0100 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: Alas I spoke too soon, and my problem is still there. So it is back to the cafe, looking for suggestions. Here is my problem in more detail: - I am running a windows system. (note Windows, not Unix, Linux, OS X, or any other Unix-a-like). - I have a clean emacs installation - only thing I have done is to install haskell-mode using the install-package function. - I start-up interactive haskell mode (C-c interactive-haskell-mode, C-c C-l (and I get a parsing complaint, but we ignore that)). [at this point I have a live haskell process that I can interact with] - I load my file (not large) into haskell. - Emacs starts persisting in telling me in the Echo region the type of the term under the cursor - all the time - and locks down to do this. - The type report uses unicode text to do this (note that if I ask for the type with C-c C-t or C-c C-i, I also get the type, but using ascii characters, so it does not appear to be the same functionality that is being triggered - if I turn off haskell-doc then the problem continues). Anybody any suggestions, recognise this problem, or even just an address where I can submit a bug report? I cannot be the only person trying to work with haskell mode on windows. Thanks Sean Matthews On Sun, Nov 5, 2017 at 8:24 PM, Sean Matthews wrote: > Problem fixed. Not an interesting problem, either. Turns out that I had > not quite completely cleaned out my emacs before reinstallation. > > Many thanks, > > Sean > > On Sun, Nov 5, 2017 at 10:46 AM, Saurabh Nanda > wrote: > >> >>> 1. Exact behavior is that Emacs freezes for about a minute and displays >>> (in bold) in the type of the word I'm over. >>> Thus, I was trying to edit a small a-list with dummy 0.000s in the >>> range. Every third keystroke, emacs stopped to tell me that >>> my cursor was over 0.000::Double and I have to wait an indeterminate >>> time (at least tens of seconds, sometimes a minute or more) >>> to get control back. >>> >> >> >> So, the underlying mechanism to determine type at current cursor position >> isn't very fast. In spacemacs+intero C-c C-t (or C-c C-i) takes anywhere >> between 1 to 10 sec for me. Something in your setup has made this lookup >> automatic. It's trying to determine the type as your browse around your >> source code. Do you have any idea what could have caused that? >> >> You could try one more thing. Try delivering a SIGUSR2 to the Emacs >> process when it's stuck. It will stop doing whatever is holding it up and >> drop you into some sort of a debugger. That can give you some clues about >> what is causing this behaviour in your setup. >> >> -- Saurabh. >> > > > > -- > Sean Matthews > seanmatthews1 at gmail.com / +49 1515 800 1901 <+49%201515%208001901> > -- Sean Matthews seanmatthews1 at gmail.com / +49 1515 800 1901 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zemyla at gmail.com Fri Nov 24 04:03:56 2017 From: zemyla at gmail.com (Zemyla) Date: Thu, 23 Nov 2017 22:03:56 -0600 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> <20171123121239.GA29203@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: In that case, you probably want to use StableNames [1], which are unique and persistent even across GCs, and give you something you can use for a hash table. On Thu, Nov 23, 2017 at 6:48 AM, Michael Walker wrote: > Thanks for the feedback, all. > > For some more context, I have a concurrency testing library[1], which > uses an algorithm called DPOR to reduce the space of possible > schedules it needs to explore. There's an algorithm called MCR which > has the potential to reduce this space significantly further. One of > the differences in MCR is taking into account reference equality of > values written to shared mutable variables. > > I can't just use Eq because (a) putMVar/etc doesn't have an Eq > constraint in the type, and (b) that would change strictness. So I > looked to reallyUnsafePtrEquality# as a possible solution. In this > setting, false negatives are fine. If the algorithm thinks two equal > values are distinct, then it doesn't run as fast as it could > potentially do, but should still outperform DPOR due to its other > improvements. But false positives are not fine, and lead to > unsoundness. > > An alternative is just using "\_ _ -> False", but if > reallyUnsafePtrEquality# will sometimes identify two equal things > without false positives, then it's effectively a free performance > boost in the cases where it happens to work. > >> - Extending the previous scenario, if purity is violated in the >> evaluation of the initially shared thunk, then x and y may become >> distinct values later on. > > Fortunately, I don't need to worry about impure actions leading to a > shared thunk evaluating to different things in different places, as > any nondeterminism beyond scheduler nondeterminism and relaxed memory > is already explicitly out of scope. > > [1] http://hackage.haskell.org/package/dejafu > > -- > Michael Walker (http://www.barrucadu.co.uk) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From mithrandi at mithrandi.net Fri Nov 24 20:53:54 2017 From: mithrandi at mithrandi.net (Tristan Seligmann) Date: Fri, 24 Nov 2017 20:53:54 +0000 Subject: [Haskell-cafe] Running an action periodically Message-ID: I just wrote this helper: > import Control.Concurrent > import Control.Concurrent.STM > import Control.Exception.Safe > > pollT :: Int -> IO a -> IO (STM (Maybe a), Async b) > pollT delay act = do > tv <- atomically (newTVar Nothing) > as <- > async . forever $ do > r <- tryAny act > case r of > Left _ -> pure () > Right r' -> atomically (writeTVar tv (Just r')) > threadDelay delay > pure (readTVar tv, as) I was sort of surprised not to find something like this in an existing library. 1. Did I miss an existing implementation? 2. Any problems with this one? 3. Any suggestions for a better name? 4. Any thoughts on the general idea? That is, "run an action periodically, updating a TVar with the result". There's a couple of obvious variations that can be built on top of this, like retrying if the TVar is Nothing when reading from it, or writing Nothing to the TVar when the action fails rather than keeping the old value. Maybe passing in the old value to the action? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sat Nov 25 00:51:58 2017 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Fri, 24 Nov 2017 16:51:58 -0800 Subject: [Haskell-cafe] Can reallyUnsafePtrEquality give false positives? In-Reply-To: References: <9FAC7BED-87D4-411D-9E5A-B7E8614E5E94@gmail.com> <20171123121239.GA29203@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: Zemlya, I think you dropped this. [1] https://hackage.haskell.org/package/base-4.10.0.0/docs/System-Mem-StableName.html On Thu, Nov 23, 2017 at 8:03 PM, Zemyla wrote: > In that case, you probably want to use StableNames [1], which are > unique and persistent even across GCs, and give you something you can > use for a hash table. > > On Thu, Nov 23, 2017 at 6:48 AM, Michael Walker > wrote: > > Thanks for the feedback, all. > > > > For some more context, I have a concurrency testing library[1], which > > uses an algorithm called DPOR to reduce the space of possible > > schedules it needs to explore. There's an algorithm called MCR which > > has the potential to reduce this space significantly further. One of > > the differences in MCR is taking into account reference equality of > > values written to shared mutable variables. > > > > I can't just use Eq because (a) putMVar/etc doesn't have an Eq > > constraint in the type, and (b) that would change strictness. So I > > looked to reallyUnsafePtrEquality# as a possible solution. In this > > setting, false negatives are fine. If the algorithm thinks two equal > > values are distinct, then it doesn't run as fast as it could > > potentially do, but should still outperform DPOR due to its other > > improvements. But false positives are not fine, and lead to > > unsoundness. > > > > An alternative is just using "\_ _ -> False", but if > > reallyUnsafePtrEquality# will sometimes identify two equal things > > without false positives, then it's effectively a free performance > > boost in the cases where it happens to work. > > > >> - Extending the previous scenario, if purity is violated in the > >> evaluation of the initially shared thunk, then x and y may become > >> distinct values later on. > > > > Fortunately, I don't need to worry about impure actions leading to a > > shared thunk evaluating to different things in different places, as > > any nondeterminism beyond scheduler nondeterminism and relaxed memory > > is already explicitly out of scope. > > > > [1] http://hackage.haskell.org/package/dejafu > > > > -- > > Michael Walker (http://www.barrucadu.co.uk) > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mtesseract at silverratio.net Sat Nov 25 12:27:50 2017 From: mtesseract at silverratio.net (Moritz Schulte) Date: Sat, 25 Nov 2017 13:27:50 +0100 Subject: [Haskell-cafe] Running an action periodically In-Reply-To: References: Message-ID: <20171125122750.GA578@blackbox.localdomain> Hi Tristan, how about the async-refresh package (https://hackage.haskell.org/package/async-refresh)? Looks close to what you have written — from the README: About This is Haskell library implementing the logic for refreshing of expiring data according to user-provided actions. Usage * Create a new configuration using newAsyncRefreshConf, providing the action to be used for data refreshing. * Adjust the configuration using the asyncRefreshConfSet* functions, in particular using asyncRefreshConfSetCallback. * Use newAsyncRefresh to initiate a new thread managing the asynchronous refreshing. [...] It is currently used by the package async-refresh-tokens (https://hackage.haskell.org/package/async-refresh-tokens), which specializes the async-refresh package to the refreshing of expiring authentication tokens. If you have questions or suggestions, feel free to open issues and/or contact me directly. Best, Moritz From nemesia.lilith at gmail.com Sat Nov 25 22:40:32 2017 From: nemesia.lilith at gmail.com (=?UTF-8?B?RXLDqGJl?=) Date: Sat, 25 Nov 2017 23:40:32 +0100 Subject: [Haskell-cafe] Running an action periodically In-Reply-To: References: Message-ID: You have the auto-update package that provide that kind of functionnality https://hackage.haskell.org/package/auto-update-0.1.4/ docs/Control-AutoUpdate.html 2017-11-24 21:53 GMT+01:00 Tristan Seligmann : > I just wrote this helper: > > > import Control.Concurrent > > import Control.Concurrent.STM > > import Control.Exception.Safe > > > > pollT :: Int -> IO a -> IO (STM (Maybe a), Async b) > > pollT delay act = do > > tv <- atomically (newTVar Nothing) > > as <- > > async . forever $ do > > r <- tryAny act > > case r of > > Left _ -> pure () > > Right r' -> atomically (writeTVar tv (Just r')) > > threadDelay delay > > pure (readTVar tv, as) > > I was sort of surprised not to find something like this in an existing > library. > > 1. Did I miss an existing implementation? > 2. Any problems with this one? > 3. Any suggestions for a better name? > 4. Any thoughts on the general idea? That is, "run an action > periodically, updating a TVar with the result". > > There's a couple of obvious variations that can be built on top of this, > like retrying if the TVar is Nothing when reading from it, or writing > Nothing to the TVar when the action fails rather than keeping the old > value. Maybe passing in the old value to the action? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 mtesseract at silverratio.net Sat Nov 25 22:53:50 2017 From: mtesseract at silverratio.net (Moritz Schulte) Date: Sat, 25 Nov 2017 23:53:50 +0100 Subject: [Haskell-cafe] Running an action periodically In-Reply-To: References: Message-ID: <20171125225350.GA16628@blackbox.localdomain> Hi Erèbe, Thanks for the suggestion. I've only had a very quick look at the auto-update package, so please correct me if I'm wrong. But I think there is an important difference between auto-update and the suggested pollT (or the async-refresh package): auto-update does not completely decouple the execution of the IO action from the calling thread. I'm referring to this comment: mkAutoUpdate :: UpdateSettings a -> IO (IO a) Generate an action which will either read from an automatically updated value, **or run the update action in the current thread**. pollT and async-refresh are implemented such that the caller really only retrieves the result of a previously executed IO action. Thus even if the IO action might block, the caller does basically not block (more than required for reading a TVar). For the use case it was created for (refreshing of authentication tokens in a micro service) it might be very important that the required tokens are *always* guaranteed to be available already at the time a request needs to be made. But maybe I'm overlooking something and auto-update does indeed also provide this functionality. Best, Moritz From nemesia.lilith at gmail.com Sat Nov 25 23:37:43 2017 From: nemesia.lilith at gmail.com (=?UTF-8?B?RXLDqGJl?=) Date: Sun, 26 Nov 2017 00:37:43 +0100 Subject: [Haskell-cafe] Running an action periodically In-Reply-To: <20171125225350.GA16628@blackbox.localdomain> References: <20171125225350.GA16628@blackbox.localdomain> Message-ID: Hello Moritz, Indeed, the auto-update do not do any refresh if the returned action is not called. So in your case your token will expire, which is not the desired behavior. >From the same package, you have Reaper https://hackage.haskell.org/package/auto-update-0.1.4/docs/Control-Reaper.html which allow you to run periodically an action on an associated resource while still providing the possibility to read and append from this resource. In your case it should fit by using the clean action as the refresh job, and using reaperRead to get your token. While this being said, using reaper may be a bit far fetched so using async-refresh or pollT may be a better call :) 2017-11-25 23:53 GMT+01:00 Moritz Schulte : > Hi Erèbe, > > Thanks for the suggestion. > > I've only had a very quick look at the auto-update package, so please > correct me if I'm wrong. But I think there is an important difference > between auto-update and the suggested pollT (or the async-refresh > package): > > auto-update does not completely decouple the execution of the IO > action from the calling thread. I'm referring to this comment: > > mkAutoUpdate :: UpdateSettings a -> IO (IO a) > > Generate an action which will either read from an automatically > updated value, **or run the update action in the current thread**. > > pollT and async-refresh are implemented such that the caller really > only retrieves the result of a previously executed IO action. Thus > even if the IO action might block, the caller does basically not block > (more than required for reading a TVar). > > For the use case it was created for (refreshing of authentication > tokens in a micro service) it might be very important that the > required tokens are *always* guaranteed to be available already at the > time a request needs to be made. > > But maybe I'm overlooking something and auto-update does indeed also > provide this functionality. > > Best, > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Sun Nov 26 22:07:10 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 26 Nov 2017 23:07:10 +0100 Subject: [Haskell-cafe] Munich Haskell Meeting, 2017-11-29 @ 19:30 Message-ID: <878tes66ep.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, November 29 at Cafe Puck 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-nov-2017/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From david.sorokin at gmail.com Mon Nov 27 05:13:18 2017 From: david.sorokin at gmail.com (David Sorokin) Date: Mon, 27 Nov 2017 08:13:18 +0300 Subject: [Haskell-cafe] emacs problem : haskell mode keeps hanging to report types, renders emacs useless In-Reply-To: References: Message-ID: Hi Sean, Did you try another mode which was called «deprecated» once? (require 'haskell-process) (add-hook 'haskell-mode-hook 'inf-haskell-mode) I personally use only this mode as I very appreciate a Lisp-like bottom-up development. Best regards, David Sorokin > 24 нояб. 2017 г., в 1:11, Sean Matthews написал(а): > > Alas I spoke too soon, and my problem is still there. So it is back to the cafe, looking for suggestions. Here is my problem in more detail: > > - I am running a windows system. (note Windows, not Unix, Linux, OS X, or any other Unix-a-like). > > - I have a clean emacs installation - only thing I have done is to install haskell-mode using the install-package function. > > - I start-up interactive haskell mode (C-c interactive-haskell-mode, C-c C-l (and I get a parsing complaint, but we ignore that)). > > [at this point I have a live haskell process that I can interact with] > > - I load my file (not large) into haskell. > > - Emacs starts persisting in telling me in the Echo region the type of the term under the cursor - all the time - and locks down to do this. > > - The type report uses unicode text to do this (note that if I ask for the type with C-c C-t or C-c C-i, I also get the type, but using ascii characters, so it does not appear to be the same functionality that is being triggered - if I turn off haskell-doc then the problem continues). > > Anybody any suggestions, recognise this problem, or even just an address where I can submit a bug report? > I cannot be the only person trying to work with haskell mode on windows. > > Thanks > > Sean Matthews > > On Sun, Nov 5, 2017 at 8:24 PM, Sean Matthews > wrote: > Problem fixed. Not an interesting problem, either. Turns out that I had not quite completely cleaned out my emacs before reinstallation. > > Many thanks, > > Sean > > On Sun, Nov 5, 2017 at 10:46 AM, Saurabh Nanda > wrote: > > 1. Exact behavior is that Emacs freezes for about a minute and displays (in bold) in the type of the word I'm over. > Thus, I was trying to edit a small a-list with dummy 0.000s in the range. Every third keystroke, emacs stopped to tell me that > my cursor was over 0.000::Double and I have to wait an indeterminate time (at least tens of seconds, sometimes a minute or more) > to get control back. > > > So, the underlying mechanism to determine type at current cursor position isn't very fast. In spacemacs+intero C-c C-t (or C-c C-i) takes anywhere between 1 to 10 sec for me. Something in your setup has made this lookup automatic. It's trying to determine the type as your browse around your source code. Do you have any idea what could have caused that? > > You could try one more thing. Try delivering a SIGUSR2 to the Emacs process when it's stuck. It will stop doing whatever is holding it up and drop you into some sort of a debugger. That can give you some clues about what is causing this behaviour in your setup. > > -- Saurabh. > > > > -- > Sean Matthews > seanmatthews1 at gmail.com / +49 1515 800 1901 > > > -- > Sean Matthews > seanmatthews1 at gmail.com / +49 1515 800 1901 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Mon Nov 27 06:24:00 2017 From: eraker at gmail.com (erik) Date: Sun, 26 Nov 2017 22:24:00 -0800 Subject: [Haskell-cafe] New Haskell Meetup in San Diego, California Message-ID: Hello Haskell Cafe, We have decided to start a new Haskell meetup in San Diego, California: https://www.meetup.com/Haskell-Hangout/ Our initial goals are to cover both theoretical and practical aspects of the language. More broadly, we'd like to provide a space for people to discuss, learn, and further their Haskell understanding and to foster awareness of and interest in the language in the community of professional developers here in San Diego. For our first meeting on January 10th, we're going to discuss Philip Wadler's 1992 paper "Monads for Functional Programming". If you're interested and nearby, feel free to join us. All are welcome to attend, no Haskell experience required. Best, -- Erik Aker -------------- next part -------------- An HTML attachment was scrubbed... URL: From onepoint at starurchin.org Mon Nov 27 15:13:21 2017 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon, 27 Nov 2017 15:13:21 +0000 Subject: [Haskell-cafe] ghc-8.2.2 downloads: missing checksums Message-ID: <20171127151321.GJ23883@omphalos.singularity> The SHA1SUMS and SHA256SUMS files in https://downloads.haskell.org/~ghc/8.2.2/ do not have checksums for ghc-8.2.2-x86_64-unknown-linux.tar.xz . Regards, Jeremy Henty From christiaan.baaij at gmail.com Tue Nov 28 23:33:04 2017 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 29 Nov 2017 00:33:04 +0100 Subject: [Haskell-cafe] Looking for opportunity to present Clash (Haskell-to-Hardware compiler) in San Francisco area Message-ID: Hello Cafe!, I'm on a business trip in San Francisco from 2nd until 8th of December, but only have meetings on 4th and 6th. I was wondering if there are any people out in the SF area interested in a presentation about Clash, a Haskell-to-Hardware compiler ( http://clash-lang.org), and could host me in some way (i.e. provide a room to present); or just talk Haskell. It could be on the 3rd, 5th, or 7th. Please contact me if you're interested, or know of a place/meetup I could contact. Cheers! Christiaan -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Nov 29 10:04:01 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 29 Nov 2017 11:04:01 +0100 (CET) Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches Message-ID: Occasionally I have multiple implementations of the same task and want to choose one quickly but statically. I do not want to out-comment unused branches because they shall still be type checked. So far I used this scheme: case 0::Int of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" With ghc-8.0.2 and ghc-8.2.2 I get these warnings: RedundantCase.hs:4:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 0 -> ... RedundantCase.hs:5:7: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: 1 -> ... I thought that "redundant" means that the first two cases overlap with '_'. But if I replace '_' by '2' I get not only the non-exhaustive patterns warning but an additional redundancy warning on pattern '2'. Is there a nice way to tell GHC that the unused branches are intended, without generally disabling overlapping patterns warning? I mean, this one does not provoke any warnings: if True then putStrLn "X" else putStrLn "Y" but is limited to two branches. From sivanov at colimite.fr Wed Nov 29 10:43:20 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 29 Nov 2017 11:43:20 +0100 Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: References: Message-ID: <87k1y9pdpz.fsf@colimite.fr> Hi Henning, Thus quoth Henning Thielemann on Wed Nov 29 2017 at 11:04 (+0100): > Occasionally I have multiple implementations of the same task and want to > choose one quickly but statically. I do not want to out-comment unused > branches because they shall still be type checked. So far I used this > scheme: > > case 0::Int of > 0 -> putStrLn "A" > 1 -> putStrLn "B" > _ -> putStrLn "C" Maybe you can factor out the implementations of different branches into separate functions, like in: case 0 :: Int of 0 -> putStrLn "A" 1 -> handleOne1 where handleOne1 :: Int -> IO () handleOne1 = putStrLn "B" handleOne1 :: Int -> IO () handleOne2 = putStrLn "C" This should keep the typechecking. > With ghc-8.0.2 and ghc-8.2.2 I get these warnings: > > RedundantCase.hs:4:7: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: 0 -> ... > > RedundantCase.hs:5:7: warning: [-Woverlapping-patterns] > Pattern match is redundant > In a case alternative: 1 -> ... > > I thought that "redundant" means that the first two cases overlap with > '_'. But if I replace '_' by '2' I get not only the non-exhaustive > patterns warning but an additional redundancy warning on pattern '2'. > > Is there a nice way to tell GHC that the unused branches are intended, > without generally disabling overlapping patterns warning? To me, you are creating overlapping patterns in the case statements, so having unused branches and _not_ having warnings about them kind of breaks the point of this type of warning (personal opinion). Now, depending on the localisation of alternative branches, you may want to use per-file preprocessor directives to disable the warning. -- Sergiu > I mean, this one does not provoke any warnings: > > if True > then putStrLn "X" > else putStrLn "Y" > > but is limited to two branches. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 487 bytes Desc: not available URL: From lemming at henning-thielemann.de Wed Nov 29 11:03:57 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 29 Nov 2017 12:03:57 +0100 (CET) Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: <87k1y9pdpz.fsf@colimite.fr> References: <87k1y9pdpz.fsf@colimite.fr> Message-ID: On Wed, 29 Nov 2017, Sergiu Ivanov wrote: > Hi Henning, > > Maybe you can factor out the implementations of different branches into > separate functions, like in: > > case 0 :: Int of > 0 -> putStrLn "A" > 1 -> handleOne1 > where > handleOne1 :: Int -> IO () > handleOne1 = putStrLn "B" > > handleOne1 :: Int -> IO () > handleOne2 = putStrLn "C" I had something similar in mind and found it too complicated. I could also omit 'case' completely, and directly call handleOne1 and prefix unused handleOne's with an underscore. Maybe it is the best I can do for now. > To me, you are creating overlapping patterns in the case statements, so > having unused branches and _not_ having warnings about them kind of > breaks the point of this type of warning (personal opinion). Not quite. We can silence "unused" warnings for variables by prepending an underscore. Something similar might work for case patterns. From sylvain at haskus.fr Wed Nov 29 12:13:21 2017 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 29 Nov 2017 13:13:21 +0100 Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: References: Message-ID: <852a0717-8cd6-478d-0c86-5f1f2079b430@haskus.fr> > I thought that "redundant" means that the first two cases overlap with '_'. But if I replace '_' by '2' I get not only the non-exhaustive patterns warning but an additional redundancy warning on pattern '2'. I think it's a bug of the PM check instead: it doesn't correctly detect redundant Int alternatives ("1" and "_" in your example). Could you report it as a bug? Note that it works as expected with Integer: "case 0 :: Integer of" reports "1 ->..." and "_ -> ..." as redundant. A solution to avoid the warning is:    let choosePut = 0 :: Int    case choosePut of       0 -> putStrLn "A"       1 -> putStrLn "B"       _ -> putStrLn "C" -Sylvain On 29/11/2017 11:04, Henning Thielemann wrote: > > Occasionally I have multiple implementations of the same task and want > to choose one quickly but statically. I do not want to out-comment > unused branches because they shall still be type checked. So far I > used this scheme: > >    case 0::Int of >       0 -> putStrLn "A" >       1 -> putStrLn "B" >       _ -> putStrLn "C" > > With ghc-8.0.2 and ghc-8.2.2 I get these warnings: > > RedundantCase.hs:4:7: warning: [-Woverlapping-patterns] >     Pattern match is redundant >     In a case alternative: 0 -> ... > > RedundantCase.hs:5:7: warning: [-Woverlapping-patterns] >     Pattern match is redundant >     In a case alternative: 1 -> ... > > I thought that "redundant" means that the first two cases overlap with > '_'. But if I replace '_' by '2' I get not only the non-exhaustive > patterns warning but an additional redundancy warning on pattern '2'. > > Is there a nice way to tell GHC that the unused branches are intended, > without generally disabling overlapping patterns warning? > > I mean, this one does not provoke any warnings: > >    if True >      then putStrLn "X" >      else putStrLn "Y" > > but is limited to two branches. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 doug at cs.dartmouth.edu Wed Nov 29 13:33:52 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 29 Nov 2017 08:33:52 -0500 Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches Message-ID: <201711291333.vATDXq8S000738@coolidge.cs.Dartmouth.EDU> Surely GHC is too clever by half in asserting that just 1 of two impossible branches is redundant in the code > case 0::Int of > 0 -> putStrLn "A" > 1 -> putStrLn "B" > _ -> putStrLn "C" The assertion suggests that GHC code optimization would leave some useless vestige of the third case, The long-range solution to Thielmann's quandry is a bug report. Doug From ben at well-typed.com Wed Nov 29 14:49:38 2017 From: ben at well-typed.com (Ben Gamari) Date: Wed, 29 Nov 2017 09:49:38 -0500 Subject: [Haskell-cafe] ghc-8.2.2 downloads: missing checksums In-Reply-To: <20171127151321.GJ23883@omphalos.singularity> References: <20171127151321.GJ23883@omphalos.singularity> Message-ID: <87o9nl87i8.fsf@ben-laptop.smart-cactus.org> Jeremy Henty writes: > The SHA1SUMS and SHA256SUMS files in https://downloads.haskell.org/~ghc/8.2.2/ > do not have checksums for ghc-8.2.2-x86_64-unknown-linux.tar.xz . > Thanks for noticing this. Fixed. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From olf at aatal-apotheke.de Wed Nov 29 18:32:32 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 29 Nov 2017 19:32:32 +0100 Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches Message-ID: <6F13150B-EE9D-44C2-9BA8-7F7287E61B1A@aatal-apotheke.de> Henning, how about putting the branches into their own variables. Admittedly this pollutes the namespace but is much more readable IMHO. workflow = new_workflow where new_workflow = putStrLn "A" old_workflow = putStrLn "B" I suppose GHC complains neither about unused where clauses nor about unused top-level bindings. At least with GHCi 7.8.3 the above code produces no warnings. Olaf From lemming at henning-thielemann.de Wed Nov 29 19:13:19 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 29 Nov 2017 20:13:19 +0100 (CET) Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: <6F13150B-EE9D-44C2-9BA8-7F7287E61B1A@aatal-apotheke.de> References: <6F13150B-EE9D-44C2-9BA8-7F7287E61B1A@aatal-apotheke.de> Message-ID: On Wed, 29 Nov 2017, Olaf Klinke wrote: > Henning, > > how about putting the branches into their own variables. Admittedly this pollutes the namespace but is much more readable IMHO. > > workflow = new_workflow where > new_workflow = putStrLn "A" > old_workflow = putStrLn "B" > > I suppose GHC complains neither about unused where clauses nor about > unused top-level bindings. At least with GHCi 7.8.3 the above code > produces no warnings. It complains with -Wall, which is a good thing. But in this case I can suppress the warning individually by prepending an underscore. From lemming at henning-thielemann.de Thu Nov 30 09:28:52 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 30 Nov 2017 10:28:52 +0100 (CET) Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: <87k1y9pdpz.fsf@colimite.fr> References: <87k1y9pdpz.fsf@colimite.fr> Message-ID: On Wed, 29 Nov 2017, Sergiu Ivanov wrote: > Thus quoth Henning Thielemann on Wed Nov 29 2017 at 11:04 (+0100): >> Occasionally I have multiple implementations of the same task and want to >> choose one quickly but statically. I do not want to out-comment unused >> branches because they shall still be type checked. So far I used this >> scheme: >> >> case 0::Int of >> 0 -> putStrLn "A" >> 1 -> putStrLn "B" >> _ -> putStrLn "C" I have filed a GHC ticket: https://ghc.haskell.org/trac/ghc/ticket/14546 From mail at joachim-breitner.de Thu Nov 30 16:06:09 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Nov 2017 11:06:09 -0500 Subject: [Haskell-cafe] out-commented code vs. case with redundant pattern matches In-Reply-To: References: Message-ID: <1512057969.6605.2.camel@joachim-breitner.de> Hi, Am Mittwoch, den 29.11.2017, 11:04 +0100 schrieb Henning Thielemann: > Occasionally I have multiple implementations of the same task and want to > choose one quickly but statically. I do not want to out-comment unused > branches because they shall still be type checked. So far I used this > scheme: > > case 0::Int of > 0 -> putStrLn "A" > 1 -> putStrLn "B" > _ -> putStrLn "C" You can write case id (0::Int) of 0 -> putStrLn "A" 1 -> putStrLn "B" _ -> putStrLn "C" instead. > I mean, this one does not provoke any warnings: > > if True > then putStrLn "X" > else putStrLn "Y" > > but is limited to two branches. It looks like a but that it warns for Int, but not for Bool… freel free to report that (https://ghc.haskell.org/trac/ghc/wiki/ReportABug). Joachim -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: