From simon at joyful.com Sat Apr 1 01:32:29 2017 From: simon at joyful.com (Simon Michael) Date: Fri, 31 Mar 2017 18:32:29 -0700 Subject: [Haskell-cafe] ANN: hledger 1.2 Message-ID: I'm pleased to announce hledger 1.2, on schedule. Thank you to release contributors Peter Simons, Stefano Rodighiero, Moritz Kiefer, Pia Mancini, Bryan Richter, Steven R. Baker, Hans-Peter Deifel, Joshua Chia, Joshua Kehn, Michael Walker, and especially Mykola Orliuk and Justin Le! Notable user-visible changes in this release: new commands list, more powerful balancesheet/incomestatement/cashflow commands, more parseable print output, better --pivot, basic automated postings and periodic transactions support, more and easier addons, bugfixes. Full release notes: http://hledger.org/release-notes#hledger-1.2 The next major release is scheduled for June 30. hledger (http://hledger.org) is a dependable, precise, cross-platform program for tracking money, time, or any other commodity, using double-entry accounting and a simple plain text file format. It is a haskell reimplementation of Ledger, provides command-line, curses and web interfaces, and aims to be a robust, practical tool for daily use. To install this release: Get stack, eg from http://haskell-lang.org/get-started $ stack install --resolver=nightly hledger [hledger-ui] [hledger-web] [hledger-api] $ ~/.local/bin/hledger or see http://hledger.org/download for more installation options. Our IRC channel is #hledger on Freenode, and you can find out more at http://hledger.org. I hope you enjoy hledger and that it helps you achieve your goals. If you have benefitted from hledger, please give back and make it stronger! Donate using one of the funding links on the home page, give feedback, report bugs, send pull requests, write about it, etc. Best! -Simon From lysxia at gmail.com Sat Apr 1 01:44:29 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 31 Mar 2017 21:44:29 -0400 Subject: [Haskell-cafe] Suggestion on how to solve a type issue with Numeric.AD In-Reply-To: References: Message-ID: Hi Frederic, As you have already noticed, it is best not to change the representation of the numerals in a function you pass to grad, as this destroys the metadata built up by the ad framework to compute derivatives. Revert ExprTreeToListFun. Having derived Functor for ExprTree, convert your tree and parameters using auto before applying exprTreeToListFun. This leaves grad free to pick the right type. gradList = AD.grad (exprTreeToListFun (fmap auto tree) (fmap auto paramDict)) varVals Cheers, Li-yao On 03/31/2017 08:33 AM, Frederic Cogny wrote: > Hello Café > > *Issue: * > I'm having trouble using the AD package presumably due to a wrong use of > types (Sorry I know it's a bit vague) > Any help or pointer on how to solve this would be greatly appreciated. > Thanks in advance > > *Background: * > I've implemented a symbolic expression tree [full code here: > https://pastebin.com/FDpSFuRM] > -- | Expression Tree > data ExprTree a = Const a -- ^ number > | ParamNode ParamName -- ^ parameter > | VarNode VarName -- ^ variable > | UnaryNode MonoOp (ExprTree a) -- ^ operator of > arity 1 > | BinaryNode DualOp (ExprTree a) (ExprTree a) -- ^ operator > of arity 2 > | CondNode (Cond a) (ExprTree a) (ExprTree a) -- ^ > conditional node > deriving (Eq,Show, Generic) > > An evaluation function on it > -- | evaluates an Expression Tree on its Context (Map ParamName a, Map > VarName a) > evaluate :: (Eq a, Ord a, Floating a) => ExprTree a -> Context a -> a > > And a few instances on it: > instance Num a => Default (ExprTree a) where ... > instance Num a => Num (ExprTree a) where ... > instance Fractional a => Fractional (ExprTree a) where ... > instance Floating a => Floating (ExprTree a) where ... > instance (Arbitrary a) => Arbitrary (ExprTree a) where ... > > This allows me to easily create (using derivation rules) the derivative(s) > of such a tree with respect to its variable(s): > diff :: (Eq a, Floating a) => ExprTree a -> VarName -> ExprTree a > grad :: (Eq a, Floating a) => ExprTree a -> Map VarName (ExprTree a) > hessian :: (Eq a, Floating a) => ExprTree a -> Map VarName (Map VarName > (ExprTree a)) > > So far, so good ... > > Now, to gain assurance in my implementation I wanted to check the > derivatives against the Numeric.AD module > so I create the two following > -- | helper for AD usage > exprTreeToListFun :: (RealFloat a) > => ExprTree a -- ^ tree > -> Map ParamName a -- ^ paramDict > -> ([a] -> a) -- fun from var values to their > evaluation > exprTreeToListFun tree paramDict vals = res > where > res = evaluate tree (paramDict, varDict) > varDict = Map.fromList $ zip (getVarNames tree) vals > > > gradThroughAD :: RealFloat a => ExprTree a -> Context a -> Map VarName a > gradThroughAD tree (paramDict, varDict) = res > where > varNames = Map.keys varDict > varVals = Map.elems varDict > gradList = AD.grad (exprTreeToListFun tree paramDict) varVals > res = Map.fromList $ zip varNames gradList > > > it unfortunately does not type check with message: > • Couldn't match type ‘a’ with ‘Numeric.AD.Internal.Reverse.Reverse s a’ ‘a’ > is a rigid type variable bound by the type signature for: gradThroughAD :: > forall a. RealFloat a => ExprTree a -> Context a -> Map VarName a at src/ > SymbolicExpression.hs:452:18 Expected type: [Numeric.AD.Internal.Reverse. > Reverse s a] -> Numeric.AD.Internal.Reverse.Reverse s a Actual type: [a] -> > a • In the first argument of ‘AD.grad’, namely ‘(exprTreeToListFun tree > paramDict)’ In the expression: AD.grad (exprTreeToListFun tree paramDict) > varVals In an equation for ‘gradList’: gradList = AD.grad (exprTreeToListFun > tree paramDict) varVals • Relevant bindings include gradList :: [a] (bound > at src/SymbolicExpression.hs:457:5) varVals :: [a] (bound at src/ > SymbolicExpression.hs:456:5) varDict :: Map VarName a (bound at > src/SymbolicExpression.hs:453:32) paramDict :: Map ParamName a (bound at > src/SymbolicExpression.hs:453:21) tree :: ExprTree a (bound at src/ > SymbolicExpression.hs:453:15) gradThroughAD :: ExprTree a -> Context a -> > Map VarName a (bound at src/SymbolicExpression.hs:453:1) > > > I was a bit surprised (I guess naively) by this, since to me, 'a' is > polymorphic with RealFloat as type constraint and that is "supposed" to > work with AD > > So anyway, I tried to modify as follow: > {-# LANGUAGE Rank2Types #-} > > -- | helper for AD usage > exprTreeToListFun :: (RealFloat a) > => ExprTree a -- ^ tree > -> Map ParamName a -- ^ paramDict > -> *(RealFloat b => *[b] -> b) -- fun from var > values to their evaluation > exprTreeToListFun tree paramDict vals = res > where > res = *realToFrac* $ evaluate tree (paramDict, varDict) > varDict = Map.fromList $ zip (getVarNames tree) *$ map > realToFrac *vals > > This now typechecks and runs but going through AD returns me *all > derivatives as zero* as if treating the variables (that passed through > *realToFrac*) as constants, so not that much helpful either. > > Any idea how this can be solved ? > > Apologies if this is a question that already has an answer somewhere but poking > around SO It > looks like I'm not the only one having similar issues and unfortunately > none of the answers I found really helped me, if anything it confirms the > same issue of null derivatives: > http://stackoverflow.com/questions/36878083/ad-type-unification-error-with-constrained-type-vector > > Thanks again > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 trevor.mcdonell at gmail.com Sat Apr 1 02:04:20 2017 From: trevor.mcdonell at gmail.com (Trevor McDonell) Date: Sat, 01 Apr 2017 02:04:20 +0000 Subject: [Haskell-cafe] [accelerate-haskell] [ANN] Accelerate 1.0 In-Reply-To: References: Message-ID: Yep, it is just hard coded, but to be fair there have been very few new Accelerate backends. It does pull in extra dependencies though, if you forget to add the appropriate `-f-X` flag. The type class approach you mention sounds like how the LLVM-based packages are architected. -Trev On Fri, 31 Mar 2017 at 20:46 Henning Thielemann < googlegroups at henning-thielemann.de> wrote: > > On Fri, 31 Mar 2017, Trevor McDonell wrote: > > > * accelerate-fft: FFI bindings to discrete Fourier transforms (FFTW > and cuFFT) > > (https://hackage.haskell.org/package/accelerate-fft) > > I was curious how you solved the problem of addressing target specific > implementations of functions like the FFT. Looking at the source code it > looks like you have hard-coded a selection of back-ends. I hoped that we > would be able to specify back-end capabilities via a type-class. This way > the user could add more back-ends with their respective FFT > implementations. Maybe that's stuff to be defered to Accelerate-2.0. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Apr 1 05:00:29 2017 From: gershomb at gmail.com (Gershom B) Date: Sat, 1 Apr 2017 01:00:29 -0400 Subject: [Haskell-cafe] ANN: Haskell World News Message-ID: Fellow Haskellers, Over the years, a number of newsletters have been produced on news and developments in the Haskell world. There has been the venerable Haskell Weekly News, under multiple editors. More recently, the Haskell Weekly was started. These have been great publications. Nonetheless, in some ways they have been too ambitious, and in other ways, not ambitious enough. Too ambitious in seeking to publish weekly -- a grueling schedule, doomed to sporadic lapses. Insufficiently ambitious in being just roundups of articles by others. The Haskell world is maturing, and it needs a publication that can reflect that, with in-depth reporting, original research, and feature stories. That takes time to produce, and resources. I'm happy to announce the launch of Haskell World News, a subscription-only PDF newsletter with exclusive content that will break new stories and cover the world of Haskell programming in a manner that befits its emerging commercial success. Why subscription-only, you may ask? Because print media, and subscription media, is serious media. Fly-by-night weblogs report false theorems all the time. The wave of the future is not bite-sized tweets and open-letters on medium. It's shoe leather reporting that gets to the real stories. To give just one example of the sorts of things we hope to cover -- everyone agrees Elvis Presley would have been a Functional Programmer. But would he have used Haskell, or OCaml? It takes time and resources to contract a medium to hold a seance and ask his spirit. And those are the resources that Haskell World News will bring to bear. More details will be forthcoming shortly - but for now here's a sneak preview of the cover of the first issue: http://gbaz.github.io/haskell-world-news-1.jpg Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions as to some of the topics covered. Regards, The Haskell World News Team "Well Typed News Doesn't Break" ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell-world-news.jpg Type: image/jpeg Size: 62932 bytes Desc: not available URL: From atrudyjane at protonmail.com Sat Apr 1 05:22:55 2017 From: atrudyjane at protonmail.com (Atrudyjane) Date: Sat, 01 Apr 2017 01:22:55 -0400 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: That sounds like a great idea. As a beginner just starting a first project, piecing together bite sized info from weblogs all over the place does take a lot of time. Would this publication be useful for beginners as well? Regards, Andrea Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: [Haskell-cafe] ANN: Haskell World News Local Time: April 1, 2017 12:00 AM UTC Time: April 1, 2017 5:00 AM From: gershomb at gmail.com To: haskell-cafe Fellow Haskellers, Over the years, a number of newsletters have been produced on news and developments in the Haskell world. There has been the venerable Haskell Weekly News, under multiple editors. More recently, the Haskell Weekly was started. These have been great publications. Nonetheless, in some ways they have been too ambitious, and in other ways, not ambitious enough. Too ambitious in seeking to publish weekly -- a grueling schedule, doomed to sporadic lapses. Insufficiently ambitious in being just roundups of articles by others. The Haskell world is maturing, and it needs a publication that can reflect that, with in-depth reporting, original research, and feature stories. That takes time to produce, and resources. I'm happy to announce the launch of Haskell World News, a subscription-only PDF newsletter with exclusive content that will break new stories and cover the world of Haskell programming in a manner that befits its emerging commercial success. Why subscription-only, you may ask? Because print media, and subscription media, is serious media. Fly-by-night weblogs report false theorems all the time. The wave of the future is not bite-sized tweets and open-letters on medium. It's shoe leather reporting that gets to the real stories. To give just one example of the sorts of things we hope to cover -- everyone agrees Elvis Presley would have been a Functional Programmer. But would he have used Haskell, or OCaml? It takes time and resources to contract a medium to hold a seance and ask his spirit. And those are the resources that Haskell World News will bring to bear. More details will be forthcoming shortly - but for now here's a sneak preview of the cover of the first issue: http://gbaz.github.io/haskell-world-news-1.jpg Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions as to some of the topics covered. Regards, The Haskell World News Team "Well Typed News Doesn't Break" -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell-world-news.jpg Type: image/jpeg Size: 62932 bytes Desc: not available URL: From abela at chalmers.se Sat Apr 1 11:08:59 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 13:08:59 +0200 Subject: [Haskell-cafe] GHCI says we all drink left-handed Message-ID: GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> data Handed = Handed Prelude> let drink beer = beer Prelude> all drink (Left Handed) True -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From monkleyon at gmail.com Sat Apr 1 11:36:31 2017 From: monkleyon at gmail.com (MarLinn) Date: Sat, 1 Apr 2017 13:36:31 +0200 Subject: [Haskell-cafe] GHCI says we all drink left-handed In-Reply-To: References: Message-ID: <2d0deb91-f6ab-e929-d45d-c82ff66cd11f@gmail.com> You are right. But it gets worse! At first I assumed GHCi might just be saying "All left-handed people should be allowed to drink" but now I'm convinced it's biased. Following your definitions: Prelude> any (<3) (Left Handed) Prelude> False Ouch! No love for left-handed people at all! On 2017-04-01 13:08, Andreas Abel wrote: > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > From evincarofautumn at gmail.com Sat Apr 1 11:36:09 2017 From: evincarofautumn at gmail.com (Jon Purdy) Date: Sat, 1 Apr 2017 04:36:09 -0700 Subject: [Haskell-cafe] GHCI says we all drink left-handed In-Reply-To: References: Message-ID: If we assume that you drink beer: let drink beer = True Then we can conclude that it doesn’t matter which hand you drink with: all drink (Left Handed) == all drink (Right Handed) == True On Sat, Apr 1, 2017 at 4:08 AM, Andreas Abel wrote: > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abela at chalmers.se Sat Apr 1 12:17:25 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 14:17:25 +0200 Subject: [Haskell-cafe] GHCI says we all drink left-handed In-Reply-To: References: Message-ID: <89f8f0d2-f671-6c70-4d88-597c49608cce@chalmers.se> Indeed. But all (const True) _ == True does not really come as surprise. Not really usable as a joke, the element of surprise is lacking! On 01.04.2017 13:36, Jon Purdy wrote: > If we assume that you drink beer: > > let drink beer = True > > Then we can conclude that it doesn’t matter which hand you drink with: > > all drink (Left Handed) == all drink (Right Handed) == True > > On Sat, Apr 1, 2017 at 4:08 AM, Andreas Abel > wrote: > > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From jan.loewenstein at gmail.com Sat Apr 1 13:34:30 2017 From: jan.loewenstein at gmail.com (=?UTF-8?Q?Jan_von_L=C3=B6wenstein?=) Date: Sat, 01 Apr 2017 13:34:30 +0000 Subject: [Haskell-cafe] typeclass for rest resource clients Message-ID: Hi, for a project of mine I want to abstract away the rest resources (client side) and provide a stub implementation of the backend that I can use for testing. I thought about a StateT based stub instance, however one of the methods besides the usual crud stuff should be `waitFor` so that I can wait for resources to reach a certain state. Very concretely I want to create kubernetes pods and have my code wait until the pod is `Running`. What would I have to throw into the mix in order to have a stub that creates a pod and only later changes the status to `Running`? Any thoughts, advice or hint? Best Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Sat Apr 1 13:43:38 2017 From: michael at orlitzky.com (Michael Orlitzky) Date: Sat, 1 Apr 2017 09:43:38 -0400 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: <2645a6e8-502b-c30c-9bea-003d42c51d5c@orlitzky.com> On 04/01/2017 01:22 AM, Atrudyjane via Haskell-Cafe wrote: > Would this publication be useful for beginners as well? It will be equally useful to beginners and experienced haskellers. From mantkiew at gsd.uwaterloo.ca Sat Apr 1 13:51:24 2017 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Sat, 01 Apr 2017 09:51:24 -0400 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: <20170401135124.6893648.46268.13697@gsd.uwaterloo.ca> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell-world-news.jpg Type: image/jpeg Size: 62932 bytes Desc: not available URL: From hjgtuyl at chello.nl Sat Apr 1 15:32:14 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 01 Apr 2017 17:32:14 +0200 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: It seems to me that beginners can also profit from this newsletter. Thanks for the initiative, Haskell World News Team! I hope to see some articles about Monadology[0], infinitely diluted bugs[1] and CAD (Clairvoyance Assisted Debugging). Regards, Henk-Jan van Tuyl [0] https://en.wikipedia.org/wiki/Monadology [1] http://www.skepticnorth.com/2012/06/homeopathic-insect-repellent-is-there-anything-the-natural-health-products-directorate-wont-approve/ On Sat, 01 Apr 2017 07:22:55 +0200, Atrudyjane via Haskell-Cafe wrote: > That sounds like a great idea. As a beginner just starting a first > project, piecing together bite sized info from weblogs all over the > place does take a lot of time. Would this publication be useful for > beginners as well? > > Regards, > Andrea > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > -------- Original Message -------- > Subject: [Haskell-cafe] ANN: Haskell World News > Local Time: April 1, 2017 12:00 AM > UTC Time: April 1, 2017 5:00 AM > From: gershomb at gmail.com > To: haskell-cafe > > Fellow Haskellers, > > Over the years, a number of newsletters have been produced on news and > developments in the Haskell world. There has been the venerable Haskell > Weekly News, under multiple editors. More recently, the Haskell Weekly > was started. These have been great publications. Nonetheless, in some > ways they have been too ambitious, and in other ways, not ambitious > enough. Too ambitious in seeking to publish weekly -- a grueling > schedule, doomed to sporadic lapses. Insufficiently ambitious in being > just roundups of articles by others. The Haskell world is maturing, and > it needs a publication that can reflect that, with in-depth reporting, > original research, and feature stories. That takes time to produce, and > resources. I'm happy to announce the launch of Haskell World News, a > subscription-only PDF newsletter with exclusive content that will break > new stories and cover the world of Haskell programming in a manner that > befits its emerging commercial success. > > Why subscription-only, you may ask? Because print media, and > subscription media, is serious media. Fly-by-night weblogs report false > theorems all the time. The wave of the future is not bite-sized tweets > and open-letters on medium. It's shoe leather reporting that gets to the > real stories. > > To give just one example of the sorts of things we hope to cover -- > everyone agrees Elvis Presley would have been a Functional Programmer. > But would he have used Haskell, or OCaml? It takes time and resources to > contract a medium to hold a seance and ask his spirit. And those are the > resources that Haskell World News will bring to bear. > > More details will be forthcoming shortly - but for now here's a sneak > preview of the cover of the first issue: > > http://gbaz.github.io/haskell-world-news-1.jpg > > Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions as > to some of the topics covered. > > Regards, > The Haskell World News Team > "Well Typed News Doesn't Break" -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From oleg.grenrus at iki.fi Sat Apr 1 17:14:40 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 1 Apr 2017 20:14:40 +0300 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: <297667e3-9749-36e1-5ff4-5f44e9ded13a@iki.fi> Great news! We (at Futurice) have been thinking of filling the gap between academic publications and weblogs too! There're even a small article being written (with ACM styles for now, sorry for that). http://oleg.fi/gists/images/BeautifulTrees.png - Oleg, from Futurice, Grenrus On 01.04.2017 08:00, Gershom B wrote: > Fellow Haskellers, > > Over the years, a number of newsletters have been produced on news and > developments in the Haskell world. There has been the venerable > Haskell Weekly News, under multiple editors. More recently, the > Haskell Weekly was started. These have been great publications. > Nonetheless, in some ways they have been too ambitious, and in other > ways, not ambitious enough. Too ambitious in seeking to publish weekly > -- a grueling schedule, doomed to sporadic lapses. Insufficiently > ambitious in being just roundups of articles by others. The Haskell > world is maturing, and it needs a publication that can reflect that, > with in-depth reporting, original research, and feature stories. That > takes time to produce, and resources. I'm happy to announce the launch > of Haskell World News, a subscription-only PDF newsletter with > exclusive content that will break new stories and cover the world of > Haskell programming in a manner that befits its emerging commercial > success. > > Why subscription-only, you may ask? Because print media, and > subscription media, is serious media. Fly-by-night weblogs report > false theorems all the time. The wave of the future is not bite-sized > tweets and open-letters on medium. It's shoe leather reporting that > gets to the real stories. > > To give just one example of the sorts of things we hope to cover -- > everyone agrees Elvis Presley would have been a Functional Programmer. > But would he have used Haskell, or OCaml? It takes time and resources > to contract a medium to hold a seance and ask his spirit. And those > are the resources that Haskell World News will bring to bear. > > More details will be forthcoming shortly - but for now here's a sneak > preview of the cover of the first issue: > > > > http://gbaz.github.io/haskell-world-news-1.jpg > > > Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions > as to some of the topics covered. > > Regards, > The Haskell World News Team > "Well Typed News Doesn't Break" > ​ > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: BeautifulTrees.png Type: image/png Size: 192068 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From frederic.cogny at gmail.com Sat Apr 1 17:51:28 2017 From: frederic.cogny at gmail.com (Frederic Cogny) Date: Sat, 01 Apr 2017 17:51:28 +0000 Subject: [Haskell-cafe] Suggestion on how to solve a type issue with Numeric.AD In-Reply-To: References: Message-ID: Thanks a lot. This worked perfectly. I saw the auto function but as the documentation says "embed a constant" I thought (as opposed to a variable) that it will not derive against it. Thanks again for the prompt and complete answer On Sat, Apr 1, 2017, 03:44 Li-yao Xia wrote: > Hi Frederic, > > As you have already noticed, it is best not to change the representation > of the numerals in a function you pass to grad, as this destroys the > metadata built up by the ad framework to compute derivatives. Revert > ExprTreeToListFun. Having derived Functor for ExprTree, convert your > tree and parameters using auto before applying exprTreeToListFun. This > leaves grad free to pick the right type. > > gradList = AD.grad (exprTreeToListFun (fmap auto tree) (fmap auto > paramDict)) varVals > > Cheers, > Li-yao > > > On 03/31/2017 08:33 AM, Frederic Cogny wrote: > > Hello Café > > > > *Issue: * > > I'm having trouble using the AD package presumably due to a wrong use of > > types (Sorry I know it's a bit vague) > > Any help or pointer on how to solve this would be greatly appreciated. > > Thanks in advance > > > > *Background: * > > I've implemented a symbolic expression tree [full code here: > > https://pastebin.com/FDpSFuRM] > > -- | Expression Tree > > data ExprTree a = Const a -- ^ number > > | ParamNode ParamName -- ^ parameter > > | VarNode VarName -- ^ variable > > | UnaryNode MonoOp (ExprTree a) -- ^ operator of > > arity 1 > > | BinaryNode DualOp (ExprTree a) (ExprTree a) -- ^ > operator > > of arity 2 > > | CondNode (Cond a) (ExprTree a) (ExprTree a) -- ^ > > conditional node > > deriving (Eq,Show, Generic) > > > > An evaluation function on it > > -- | evaluates an Expression Tree on its Context (Map ParamName a, Map > > VarName a) > > evaluate :: (Eq a, Ord a, Floating a) => ExprTree a -> Context a -> a > > > > And a few instances on it: > > instance Num a => Default (ExprTree a) where ... > > instance Num a => Num (ExprTree a) where ... > > instance Fractional a => Fractional (ExprTree a) where ... > > instance Floating a => Floating (ExprTree a) where ... > > instance (Arbitrary a) => Arbitrary (ExprTree a) where ... > > > > This allows me to easily create (using derivation rules) the > derivative(s) > > of such a tree with respect to its variable(s): > > diff :: (Eq a, Floating a) => ExprTree a -> VarName -> ExprTree a > > grad :: (Eq a, Floating a) => ExprTree a -> Map VarName (ExprTree a) > > hessian :: (Eq a, Floating a) => ExprTree a -> Map VarName (Map VarName > > (ExprTree a)) > > > > So far, so good ... > > > > Now, to gain assurance in my implementation I wanted to check the > > derivatives against the Numeric.AD module > > so I create the two following > > -- | helper for AD usage > > exprTreeToListFun :: (RealFloat a) > > => ExprTree a -- ^ tree > > -> Map ParamName a -- ^ paramDict > > -> ([a] -> a) -- fun from var values to their > > evaluation > > exprTreeToListFun tree paramDict vals = res > > where > > res = evaluate tree (paramDict, varDict) > > varDict = Map.fromList $ zip (getVarNames tree) vals > > > > > > gradThroughAD :: RealFloat a => ExprTree a -> Context a -> Map VarName a > > gradThroughAD tree (paramDict, varDict) = res > > where > > varNames = Map.keys varDict > > varVals = Map.elems varDict > > gradList = AD.grad (exprTreeToListFun tree paramDict) varVals > > res = Map.fromList $ zip varNames gradList > > > > > > it unfortunately does not type check with message: > > • Couldn't match type ‘a’ with ‘Numeric.AD.Internal.Reverse.Reverse s a’ > ‘a’ > > is a rigid type variable bound by the type signature for: gradThroughAD > :: > > forall a. RealFloat a => ExprTree a -> Context a -> Map VarName a at src/ > > SymbolicExpression.hs:452:18 Expected type: [Numeric.AD.Internal.Reverse. > > Reverse s a] -> Numeric.AD.Internal.Reverse.Reverse s a Actual type: [a] > -> > > a • In the first argument of ‘AD.grad’, namely ‘(exprTreeToListFun tree > > paramDict)’ In the expression: AD.grad (exprTreeToListFun tree paramDict) > > varVals In an equation for ‘gradList’: gradList = AD.grad > (exprTreeToListFun > > tree paramDict) varVals • Relevant bindings include gradList :: [a] > (bound > > at src/SymbolicExpression.hs:457:5) varVals :: [a] (bound at src/ > > SymbolicExpression.hs:456:5) varDict :: Map VarName a (bound at > > src/SymbolicExpression.hs:453:32) paramDict :: Map ParamName a (bound at > > src/SymbolicExpression.hs:453:21) tree :: ExprTree a (bound at src/ > > SymbolicExpression.hs:453:15) gradThroughAD :: ExprTree a -> Context a -> > > Map VarName a (bound at src/SymbolicExpression.hs:453:1) > > > > > > I was a bit surprised (I guess naively) by this, since to me, 'a' is > > polymorphic with RealFloat as type constraint and that is "supposed" to > > work with AD > > > > So anyway, I tried to modify as follow: > > {-# LANGUAGE Rank2Types #-} > > > > -- | helper for AD usage > > exprTreeToListFun :: (RealFloat a) > > => ExprTree a -- ^ tree > > -> Map ParamName a -- ^ paramDict > > -> *(RealFloat b => *[b] -> b) -- fun from var > > values to their evaluation > > exprTreeToListFun tree paramDict vals = res > > where > > res = *realToFrac* $ evaluate tree (paramDict, varDict) > > varDict = Map.fromList $ zip (getVarNames tree) *$ map > > realToFrac *vals > > > > This now typechecks and runs but going through AD returns me *all > > derivatives as zero* as if treating the variables (that passed through > > *realToFrac*) as constants, so not that much helpful either. > > > > Any idea how this can be solved ? > > > > Apologies if this is a question that already has an answer somewhere but > poking > > around SO > It > > looks like I'm not the only one having similar issues and unfortunately > > none of the answers I found really helped me, if anything it confirms the > > same issue of null derivatives: > > > http://stackoverflow.com/questions/36878083/ad-type-unification-error-with-constrained-type-vector > > > > Thanks again > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -- Frederic Cogny +33 7 83 12 61 69 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Apr 1 18:53:18 2017 From: david.feuer at gmail.com (David Feuer) Date: Sat, 1 Apr 2017 14:53:18 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Sat Apr 1 20:10:14 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Sat, 1 Apr 2017 16:10:14 -0400 Subject: [Haskell-cafe] Suggestion on how to solve a type issue with Numeric.AD In-Reply-To: References: Message-ID: <000b886e-3c9a-85e9-0cbb-7d6950fb8269@gmail.com> Hi Frederic, For the purposes of the gradient computation, the values contained in the tree and the parameters are actually considered constants, hence the use of auto. You are differentiating only with respect to the variables, which are passed to grad separately. Regards, Li-yao On 04/01/2017 01:51 PM, Frederic Cogny wrote: > Thanks a lot. This worked perfectly. > I saw the auto function but as the documentation says "embed a constant" I > thought (as opposed to a variable) that it will not derive against it. > Thanks again for the prompt and complete answer > > On Sat, Apr 1, 2017, 03:44 Li-yao Xia wrote: > >> Hi Frederic, >> >> As you have already noticed, it is best not to change the representation >> of the numerals in a function you pass to grad, as this destroys the >> metadata built up by the ad framework to compute derivatives. Revert >> ExprTreeToListFun. Having derived Functor for ExprTree, convert your >> tree and parameters using auto before applying exprTreeToListFun. This >> leaves grad free to pick the right type. >> >> gradList = AD.grad (exprTreeToListFun (fmap auto tree) (fmap auto >> paramDict)) varVals >> >> Cheers, >> Li-yao >> >> >> On 03/31/2017 08:33 AM, Frederic Cogny wrote: >>> Hello Café >>> >>> *Issue: * >>> I'm having trouble using the AD package presumably due to a wrong use of >>> types (Sorry I know it's a bit vague) >>> Any help or pointer on how to solve this would be greatly appreciated. >>> Thanks in advance >>> >>> *Background: * >>> I've implemented a symbolic expression tree [full code here: >>> https://pastebin.com/FDpSFuRM] >>> -- | Expression Tree >>> data ExprTree a = Const a -- ^ number >>> | ParamNode ParamName -- ^ parameter >>> | VarNode VarName -- ^ variable >>> | UnaryNode MonoOp (ExprTree a) -- ^ operator of >>> arity 1 >>> | BinaryNode DualOp (ExprTree a) (ExprTree a) -- ^ >> operator >>> of arity 2 >>> | CondNode (Cond a) (ExprTree a) (ExprTree a) -- ^ >>> conditional node >>> deriving (Eq,Show, Generic) >>> >>> An evaluation function on it >>> -- | evaluates an Expression Tree on its Context (Map ParamName a, Map >>> VarName a) >>> evaluate :: (Eq a, Ord a, Floating a) => ExprTree a -> Context a -> a >>> >>> And a few instances on it: >>> instance Num a => Default (ExprTree a) where ... >>> instance Num a => Num (ExprTree a) where ... >>> instance Fractional a => Fractional (ExprTree a) where ... >>> instance Floating a => Floating (ExprTree a) where ... >>> instance (Arbitrary a) => Arbitrary (ExprTree a) where ... >>> >>> This allows me to easily create (using derivation rules) the >> derivative(s) >>> of such a tree with respect to its variable(s): >>> diff :: (Eq a, Floating a) => ExprTree a -> VarName -> ExprTree a >>> grad :: (Eq a, Floating a) => ExprTree a -> Map VarName (ExprTree a) >>> hessian :: (Eq a, Floating a) => ExprTree a -> Map VarName (Map VarName >>> (ExprTree a)) >>> >>> So far, so good ... >>> >>> Now, to gain assurance in my implementation I wanted to check the >>> derivatives against the Numeric.AD module >>> so I create the two following >>> -- | helper for AD usage >>> exprTreeToListFun :: (RealFloat a) >>> => ExprTree a -- ^ tree >>> -> Map ParamName a -- ^ paramDict >>> -> ([a] -> a) -- fun from var values to their >>> evaluation >>> exprTreeToListFun tree paramDict vals = res >>> where >>> res = evaluate tree (paramDict, varDict) >>> varDict = Map.fromList $ zip (getVarNames tree) vals >>> >>> >>> gradThroughAD :: RealFloat a => ExprTree a -> Context a -> Map VarName a >>> gradThroughAD tree (paramDict, varDict) = res >>> where >>> varNames = Map.keys varDict >>> varVals = Map.elems varDict >>> gradList = AD.grad (exprTreeToListFun tree paramDict) varVals >>> res = Map.fromList $ zip varNames gradList >>> >>> >>> it unfortunately does not type check with message: >>> • Couldn't match type ‘a’ with ‘Numeric.AD.Internal.Reverse.Reverse s a’ >> ‘a’ >>> is a rigid type variable bound by the type signature for: gradThroughAD >> :: >>> forall a. RealFloat a => ExprTree a -> Context a -> Map VarName a at src/ >>> SymbolicExpression.hs:452:18 Expected type: [Numeric.AD.Internal.Reverse. >>> Reverse s a] -> Numeric.AD.Internal.Reverse.Reverse s a Actual type: [a] >> -> >>> a • In the first argument of ‘AD.grad’, namely ‘(exprTreeToListFun tree >>> paramDict)’ In the expression: AD.grad (exprTreeToListFun tree paramDict) >>> varVals In an equation for ‘gradList’: gradList = AD.grad >> (exprTreeToListFun >>> tree paramDict) varVals • Relevant bindings include gradList :: [a] >> (bound >>> at src/SymbolicExpression.hs:457:5) varVals :: [a] (bound at src/ >>> SymbolicExpression.hs:456:5) varDict :: Map VarName a (bound at >>> src/SymbolicExpression.hs:453:32) paramDict :: Map ParamName a (bound at >>> src/SymbolicExpression.hs:453:21) tree :: ExprTree a (bound at src/ >>> SymbolicExpression.hs:453:15) gradThroughAD :: ExprTree a -> Context a -> >>> Map VarName a (bound at src/SymbolicExpression.hs:453:1) >>> >>> >>> I was a bit surprised (I guess naively) by this, since to me, 'a' is >>> polymorphic with RealFloat as type constraint and that is "supposed" to >>> work with AD >>> >>> So anyway, I tried to modify as follow: >>> {-# LANGUAGE Rank2Types #-} >>> >>> -- | helper for AD usage >>> exprTreeToListFun :: (RealFloat a) >>> => ExprTree a -- ^ tree >>> -> Map ParamName a -- ^ paramDict >>> -> *(RealFloat b => *[b] -> b) -- fun from var >>> values to their evaluation >>> exprTreeToListFun tree paramDict vals = res >>> where >>> res = *realToFrac* $ evaluate tree (paramDict, varDict) >>> varDict = Map.fromList $ zip (getVarNames tree) *$ map >>> realToFrac *vals >>> >>> This now typechecks and runs but going through AD returns me *all >>> derivatives as zero* as if treating the variables (that passed through >>> *realToFrac*) as constants, so not that much helpful either. >>> >>> Any idea how this can be solved ? >>> >>> Apologies if this is a question that already has an answer somewhere but >> poking >>> around SO >> It >>> looks like I'm not the only one having similar issues and unfortunately >>> none of the answers I found really helped me, if anything it confirms the >>> same issue of null derivatives: >>> >> http://stackoverflow.com/questions/36878083/ad-type-unification-error-with-constrained-type-vector >>> Thanks again >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> -- > Frederic Cogny > +33 7 83 12 61 69 > From svenpanne at gmail.com Sat Apr 1 22:09:08 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 2 Apr 2017 00:09:08 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: 2017-04-01 20:53 GMT+02:00 David Feuer : > It's come to my attention that Stackage doesn't have the latest and > greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just > released 0.5.10.2. It'd be nice to get that fixed, but the containers > maintainers do not have the time to take responsibility for Stackage > curation. Could whoever's responsible please take care of it? > If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC. That's at least my understanding... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Apr 1 23:23:52 2017 From: david.feuer at gmail.com (David Feuer) Date: Sat, 1 Apr 2017 19:23:52 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake. On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: > 2017-04-01 20:53 GMT+02:00 David Feuer : > >> It's come to my attention that Stackage doesn't have the latest and >> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >> released 0.5.10.2. It'd be nice to get that fixed, but the containers >> maintainers do not have the time to take responsibility for Stackage >> curation. Could whoever's responsible please take care of it? >> > > If I see this correctly, there is nothing to take care of: Stackage > nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. > When a new GHC is released and that ships with a new version of containers, > it will be on Stackage. Apart from that, there is nothing you can do: > Stackage is there to have a consistent set of packages, so containers is > not even in https://github.com/fpco/stackage/blob/master/build- > constraints.yaml, because it ships with GHC. > > That's at least my understanding... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvillanustre at gmail.com Sat Apr 1 23:28:43 2017 From: fvillanustre at gmail.com (Flavio Villanustre) Date: Sat, 1 Apr 2017 19:28:43 -0400 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: Ahem, let's see... What day is today? Is it already April 1st? And isn't that the same as April fool's day? Must confess that I almost liked the idea too... :) Flavio On Apr 1, 2017 01:45, "Atrudyjane via Haskell-Cafe" < haskell-cafe at haskell.org> wrote: That sounds like a great idea. As a beginner just starting a first project, piecing together bite sized info from weblogs all over the place does take a lot of time. Would this publication be useful for beginners as well? Regards, Andrea Sent with ProtonMail Secure Email. -------- Original Message -------- Subject: [Haskell-cafe] ANN: Haskell World News Local Time: April 1, 2017 12:00 AM UTC Time: April 1, 2017 5:00 AM From: gershomb at gmail.com To: haskell-cafe Fellow Haskellers, Over the years, a number of newsletters have been produced on news and developments in the Haskell world. There has been the venerable Haskell Weekly News, under multiple editors. More recently, the Haskell Weekly was started. These have been great publications. Nonetheless, in some ways they have been too ambitious, and in other ways, not ambitious enough. Too ambitious in seeking to publish weekly -- a grueling schedule, doomed to sporadic lapses. Insufficiently ambitious in being just roundups of articles by others. The Haskell world is maturing, and it needs a publication that can reflect that, with in-depth reporting, original research, and feature stories. That takes time to produce, and resources. I'm happy to announce the launch of Haskell World News, a subscription-only PDF newsletter with exclusive content that will break new stories and cover the world of Haskell programming in a manner that befits its emerging commercial success. Why subscription-only, you may ask? Because print media, and subscription media, is serious media. Fly-by-night weblogs report false theorems all the time. The wave of the future is not bite-sized tweets and open-letters on medium. It's shoe leather reporting that gets to the real stories. To give just one example of the sorts of things we hope to cover -- everyone agrees Elvis Presley would have been a Functional Programmer. But would he have used Haskell, or OCaml? It takes time and resources to contract a medium to hold a seance and ask his spirit. And those are the resources that Haskell World News will bring to bear. More details will be forthcoming shortly - but for now here's a sneak preview of the cover of the first issue: http://gbaz.github.io/haskell-world-news-1.jpg Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions as to some of the topics covered. Regards, The Haskell World News Team "Well Typed News Doesn't Break" _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell-world-news.jpg Type: image/jpeg Size: 62932 bytes Desc: not available URL: From atrudyjane at protonmail.com Sun Apr 2 03:25:11 2017 From: atrudyjane at protonmail.com (Atrudyjane) Date: Sat, 01 Apr 2017 23:25:11 -0400 Subject: [Haskell-cafe] ANN: Haskell World News In-Reply-To: References: Message-ID: Say it isn't so! : ) Andrea Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [Haskell-cafe] ANN: Haskell World News Local Time: April 1, 2017 6:28 PM UTC Time: April 1, 2017 11:28 PM From: fvillanustre at gmail.com To: Atrudyjane Gershom B , haskell-cafe Ahem, let's see... What day is today? Is it already April 1st? And isn't that the same as April fool's day? Must confess that I almost liked the idea too... :) Flavio On Apr 1, 2017 01:45, "Atrudyjane via Haskell-Cafe" wrote: That sounds like a great idea. As a beginner just starting a first project, piecing together bite sized info from weblogs all over the place does take a lot of time. Would this publication be useful for beginners as well? Regards, Andrea Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: [Haskell-cafe] ANN: Haskell World News Local Time: April 1, 2017 12:00 AM UTC Time: April 1, 2017 5:00 AM From: gershomb at gmail.com To: haskell-cafe Fellow Haskellers, Over the years, a number of newsletters have been produced on news and developments in the Haskell world. There has been the venerable Haskell Weekly News, under multiple editors. More recently, the Haskell Weekly was started. These have been great publications. Nonetheless, in some ways they have been too ambitious, and in other ways, not ambitious enough. Too ambitious in seeking to publish weekly -- a grueling schedule, doomed to sporadic lapses. Insufficiently ambitious in being just roundups of articles by others. The Haskell world is maturing, and it needs a publication that can reflect that, with in-depth reporting, original research, and feature stories. That takes time to produce, and resources. I'm happy to announce the launch of Haskell World News, a subscription-only PDF newsletter with exclusive content that will break new stories and cover the world of Haskell programming in a manner that befits its emerging commercial success. Why subscription-only, you may ask? Because print media, and subscription media, is serious media. Fly-by-night weblogs report false theorems all the time. The wave of the future is not bite-sized tweets and open-letters on medium. It's shoe leather reporting that gets to the real stories. To give just one example of the sorts of things we hope to cover -- everyone agrees Elvis Presley would have been a Functional Programmer. But would he have used Haskell, or OCaml? It takes time and resources to contract a medium to hold a seance and ask his spirit. And those are the resources that Haskell World News will bring to bear. More details will be forthcoming shortly - but for now here's a sneak preview of the cover of the first issue: http://gbaz.github.io/haskell-world-news-1.jpg Credit to James Deikun, Jason Dagit, and Edward Kmett for suggestions as to some of the topics covered. Regards, The Haskell World News Team "Well Typed News Doesn't Break" _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: haskell-world-news.jpg Type: image/jpeg Size: 62932 bytes Desc: not available URL: From adam at bergmark.nl Sun Apr 2 10:47:20 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 02 Apr 2017 10:47:20 +0000 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: Hi David, As far as I know stackage doesn't have a mechanism to say "this might cause version mismatches but I promise it won't", is there even a way to do that with Cabal (which stackage uses)? Cheers, Adam On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: > The fact that GHC needs to have its own containers shouldn't prevent a > consistent package set from using a different one. The only hypothetical > problem would be if the GHC API leaked containers types, but I'm pretty > sure it doesn't: they're all wrapped up in newtypes and exported > abstractly, unless someone's made a mistake. > > On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: > > 2017-04-01 20:53 GMT+02:00 David Feuer : > > It's come to my attention that Stackage doesn't have the latest and > greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just > released 0.5.10.2. It'd be nice to get that fixed, but the containers > maintainers do not have the time to take responsibility for Stackage > curation. Could whoever's responsible please take care of it? > > > If I see this correctly, there is nothing to take care of: Stackage > nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. > When a new GHC is released and that ships with a new version of containers, > it will be on Stackage. Apart from that, there is nothing you can do: > Stackage is there to have a consistent set of packages, so containers is > not even in > https://github.com/fpco/stackage/blob/master/build-constraints.yaml, > because it ships with GHC. > > That's at least my understanding... > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Apr 2 16:24:21 2017 From: david.feuer at gmail.com (David Feuer) Date: Sun, 2 Apr 2017 12:24:21 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: What I'm suggesting is a bit narrower: I think stack should probably just ignore GHC boot packages altogether, aside from the necessary ones (I think just ghc-prim, ghc, base, and array, but you'd have to check the full GHC API to be sure). Never use them, and pretend they don't exist. On Apr 2, 2017 6:47 AM, "Adam Bergmark" wrote: > Hi David, > > As far as I know stackage doesn't have a mechanism to say "this might > cause version mismatches but I promise it won't", is there even a way to do > that with Cabal (which stackage uses)? > > Cheers, > Adam > > > On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: > >> The fact that GHC needs to have its own containers shouldn't prevent a >> consistent package set from using a different one. The only hypothetical >> problem would be if the GHC API leaked containers types, but I'm pretty >> sure it doesn't: they're all wrapped up in newtypes and exported >> abstractly, unless someone's made a mistake. >> >> On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: >> >> 2017-04-01 20:53 GMT+02:00 David Feuer : >> >> It's come to my attention that Stackage doesn't have the latest and >> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >> released 0.5.10.2. It'd be nice to get that fixed, but the containers >> maintainers do not have the time to take responsibility for Stackage >> curation. Could whoever's responsible please take care of it? >> >> >> If I see this correctly, there is nothing to take care of: Stackage >> nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. >> When a new GHC is released and that ships with a new version of containers, >> it will be on Stackage. Apart from that, there is nothing you can do: >> Stackage is there to have a consistent set of packages, so containers is >> not even in https://github.com/fpco/stackage/blob/master/build- >> constraints.yaml, because it ships with GHC. >> >> That's at least my understanding... >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Apr 2 20:26:33 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 2 Apr 2017 22:26:33 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: 2017-04-02 18:24 GMT+02:00 David Feuer : > What I'm suggesting is a bit narrower: I think stack should probably just > ignore GHC boot packages altogether, aside from the necessary ones (I think > just ghc-prim, ghc, base, and array, but you'd have to check the full GHC > API to be sure). Never use them, and pretend they don't exist. > My personal understanding of Stackage is: It's a collection of packages with *exactly* one version of each package, and all those versions are guaranteed to work together. (<= Well, at least in the eyes of the resolver, not necessarily in a semantic way) So: As long as GHC exposes its "non-necessary" packages, whatever that means in detail, I doubt that there will be other versions of them on Stackage. That's what Hackage is for... Again: That's at least my understanding... -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Sun Apr 2 23:58:24 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 02 Apr 2017 19:58:24 -0400 Subject: [Haskell-cafe] formal treatment of module dependencies In-Reply-To: <0c3fc4d0-38b6-85b3-cfaa-d560bcfaf662@ucdavis.edu> References: <0c3fc4d0-38b6-85b3-cfaa-d560bcfaf662@ucdavis.edu> Message-ID: <1491177471-sup-2699@sabre> Arguably, more sophisticated package-level module systems like Backpack are attempting to handle this problem, but we haven't tackled this particular incarnation directly. Excerpts from Dimitri DeFigueiredo's message of 2017-03-08 12:16:00 -0700: > It seems to me that specifying and solving module dependencies is a > ubiquitous problem in software development. > All the languages that I know try to make the problem go away by using > version numbers and maximizing backward compatibility. > > Does anyone know of references that formalize this problem for Haskell? > > Thanks, > > Dimitri > From mihai.maruseac at gmail.com Mon Apr 3 00:41:33 2017 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Sun, 2 Apr 2017 17:41:33 -0700 Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, May 2017 edition (32nd edition) Message-ID: Dear all, We would like to collect contributions for the 32nd edition (10000th edition) of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 30 April 2017 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac FAQ: Q: What format should I write in? A: The usual format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/05-2017/template.tex There is also a LaTeX style file at http://haskell.org/communities/05-2017/hcar.sty that you can use to preview your entry. If you do not know LaTeX or don't want to use it or don't have time to translate your entry into it, then please use plain text, it is better to have an entry in plain-text which we will translate than not have it at all. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then. PNG is preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachments are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From ekmett at gmail.com Mon Apr 3 05:58:20 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 3 Apr 2017 01:58:20 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: That doesn't work if you link against ghc the library. If I run ghc-pkg describe ghc on my slightly old install, it shows depends: array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1 containers-0.5.7.1 directory-1.2.6.2 filepath-1.4.1.0 ghc-boot-8.0.1 ghci-8.0.1 hoopl-3.10.2.1 hpc-0.6.0.3 process-1.4.2.0 template-haskell-2.11.0.0 time-1.6.0.1 transformers-0.5.2.0 unix-2.7.2.0 If any of these are upgraded independently of ghc then every package that depends on both ghc will start to fail to build due to needing to link two versions of the same dependency. Examples of packages that depend on ghc with wide distribution that lots of folks depend on in at least one configuration of their builds? doctest This makes this a fairly crippling distribution hazard for something like stackage that runs the unit tests that comes with the packages it provides. =) Back in the day ghc used to maintain its own forks of many of its dependencies to avoid some of these sorts of issues. It doesn't do so any more. -Edward On Sun, Apr 2, 2017 at 12:24 PM, David Feuer wrote: > What I'm suggesting is a bit narrower: I think stack should probably just > ignore GHC boot packages altogether, aside from the necessary ones (I think > just ghc-prim, ghc, base, and array, but you'd have to check the full GHC > API to be sure). Never use them, and pretend they don't exist. > > On Apr 2, 2017 6:47 AM, "Adam Bergmark" wrote: > >> Hi David, >> >> As far as I know stackage doesn't have a mechanism to say "this might >> cause version mismatches but I promise it won't", is there even a way to do >> that with Cabal (which stackage uses)? >> >> Cheers, >> Adam >> >> >> On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: >> >>> The fact that GHC needs to have its own containers shouldn't prevent a >>> consistent package set from using a different one. The only hypothetical >>> problem would be if the GHC API leaked containers types, but I'm pretty >>> sure it doesn't: they're all wrapped up in newtypes and exported >>> abstractly, unless someone's made a mistake. >>> >>> On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: >>> >>> 2017-04-01 20:53 GMT+02:00 David Feuer : >>> >>> It's come to my attention that Stackage doesn't have the latest and >>> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >>> released 0.5.10.2. It'd be nice to get that fixed, but the containers >>> maintainers do not have the time to take responsibility for Stackage >>> curation. Could whoever's responsible please take care of it? >>> >>> >>> If I see this correctly, there is nothing to take care of: Stackage >>> nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. >>> When a new GHC is released and that ships with a new version of containers, >>> it will be on Stackage. Apart from that, there is nothing you can do: >>> Stackage is there to have a consistent set of packages, so containers is >>> not even in https://github.com/fpco/stackage/blob/master/build-constrain >>> ts.yaml, because it ships with GHC. >>> >>> That's at least my understanding... >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 hvriedel at gmail.com Mon Apr 3 08:17:56 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 03 Apr 2017 10:17:56 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: (David Feuer's message of "Sat, 1 Apr 2017 19:23:52 -0400") References: Message-ID: <871st9c3bf.fsf@gmail.com> Hi, On 2017-04-02 at 01:23:52 +0200, David Feuer wrote: > The fact that GHC needs to have its own containers shouldn't prevent a > consistent package set from using a different one. The only hypothetical > problem would be if the GHC API leaked containers types, but I'm pretty > sure it doesn't: they're all wrapped up in newtypes and exported > abstractly, unless someone's made a mistake. Fwiw, I just opened up the GHC api haddocks and arbitrarily picked a module and sure enough I was able to find a use of an exposed container type rightaway, specificially `IntMap`: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.0.1/HscTypes.html#t:ModBreaks I'd expect to easily find more leaked types from containers and other dependencies. Relatedly, I don't think it's a good idea to implement support for internal/private dependencies at this point yet w/o first having the tools to verify that types that are supposed to stay hidden don't leak through the exposed API. Otoh, tools for doing this kind of static analysis are also needed to verify the existing API versioning contract we already use now. And once we have such go-to tooling, it should be easy to build on top of that. However, if we wanted to decouple `ghc` from `containers` (and possibly other packages, such as process/transformers/unix/bytestring/binary) by declaring the use of its `container` types private/internal to `ghc`'s API, we could just go back to do what we did years ago (e.g. in GHC 7.0.4) by using renamed packages like `ghc-binary` (but also revisit the reasons why we don't do this anymore...). Another approach would be to make the `ghc` package recompilable by `cabal`. I briefly tried that[1] but got side-tracked, and I still believe it should be possible to get the `ghc` package to the point where it's an ordinary `cabal`-buildable package. [1]: Not the least, so I could upload it to Hackage and have its Haddocks being generated without too much magic; but more importantly so that cabal would be less constrained when solving for install-plans when `ghc` is involved, as well as GHC HQ being able to more easily pick up new dependencies for `ghc` w/o having to introduce yet another congestion point in terms of dependency constraints (i.e. packages depended upon by `ghc` are effectively frozen to those picked by a given GHC release once `ghc` enters an install-plan). From electreg at list.ru Mon Apr 3 14:15:08 2017 From: electreg at list.ru (=?UTF-8?B?QWxleGV5IEVnb3Jvdg==?=) Date: Mon, 03 Apr 2017 17:15:08 +0300 Subject: [Haskell-cafe] =?utf-8?q?stack_ignores_my_config=2Eyaml=3F?= Message-ID: <1491228908.504603315@f203.i.mail.ru> Hello haskellers, I'm trying to use stack scripting capabilities, but it gives me an error (and suggestion to fix it by adding some lines to extra-deps in config.yaml). However, adding this lines to config.yaml doesn't change anything. My script and config are here -  https://pastebin.com/PyRMQtqw   Any help would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robstewart57 at gmail.com Mon Apr 3 15:39:55 2017 From: robstewart57 at gmail.com (Rob Stewart) Date: Mon, 03 Apr 2017 15:39:55 +0000 Subject: [Haskell-cafe] Fwd: Call for Papers: 16th ACM SIGPLAN Erlang Workshop 2017 In-Reply-To: <8943246A3F40B240BE533CA3011C0461628C85D3@CMS08-02.campus.gla.ac.uk> References: <8943246A3F40B240BE533CA3011C0461628C85B0@CMS08-02.campus.gla.ac.uk> <8943246A3F40B240BE533CA3011C0461628C85D3@CMS08-02.campus.gla.ac.uk> Message-ID: Please consider submitting papers to the Erlang Workshop, co-located with ICFP in Oxford, UK, on 8th September. The call for papers is below. ---------- Forwarded message --------- From: Natalia Chechina Date: Mon, 13 Mar 2017 at 13:00 Subject: [Spls] Call for Papers: 16th ACM SIGPLAN Erlang Workshop 2017 To: spls at dcs.gla.ac.uk CALL FOR PAPERS =============== Sixteenth ACM SIGPLAN Erlang Workshop http://erlang.org/workshop/2017/ ----------------------------------------------------------- Oxford, United Kingdom, 8 September 2017 Satellite event of the 22nd ACM SIGPLAN International Conference on Functional Programming (ICFP 2017) 3 - 9 September, 2017 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang, Erlang-like languages, functional programming, distribution, concurrency etc. We invite three types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). The maximum length for technical papers is restricted to 12 pages. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages. Note that this is a maximum length; we welcome shorter papers also, and the program committee will evaluate all papers on an equal basis independent of their lengths. 3. Poster presentations describing topics related to the workshop goals. Each includes a maximum of 2 pages of the abstract and summary. Presentations in this category will be given an hour of shared simultaneous demonstration time. Workshop Co-Chairs ------------------ Scott Lystig Fritchie, VMware, USA Natalia Chechina, Glasgow University, UK Program Committee ----------------------------- (Note: the Workshop Co-Chairs are also committee members) Clara Benac Earle, Universidad Politecnica de Madrid, Spain Richard Carlsson, Klarna, Sweden Laura M. Castro, University of A Coruna, Spain Viktoria Fördős, Erlang Solutions, Hungary James S. Larson, Google, USA Important Dates ----------------------- Submission deadline: Fri May 26, 2017 Author notification: Fri June 23, 2017 Final submission for the publisher: Sat July 15, 2017 Workshop date: Fri September 8, 2017 Instructions to authors -------------------------------- Papers must be submitted online via EasyChair (via the "Erlang2017" event). The submission page is https://www.easychair.org/conferences/?conf=erlang2017 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details ------------------------------------------ For registration, please see the ICFP 2017 web site at: http://icfp17.sigplan.org/ Related Links -------------------- ICFP 2017 web site: http://icfp17.sigplan.org/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ EasyChair submission site: https://www.easychair.org/conferences/?conf=erlang2017 Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Atendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ -- You received this message because you are subscribed to the Google Groups "erlang-workshop-sc" group. To unsubscribe from this group and stop receiving emails from it, send an email to erlang-workshop-sc+unsubscribe at googlegroups.com. To post to this group, send email to erlang-workshop-sc at googlegroups.com . Visit this group at https://groups.google.com/group/erlang-workshop-sc. For more options, visit https://groups.google.com/d/optout. _______________________________________________ SPLS mailing list SPLS at mailhost.dcs.gla.ac.uk https://mr1.dcs.gla.ac.uk/mailman/listinfo/spls -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Mon Apr 3 16:04:15 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Mon, 03 Apr 2017 16:04:15 +0000 Subject: [Haskell-cafe] stack ignores my config.yaml? In-Reply-To: <1491228908.504603315@f203.i.mail.ru> References: <1491228908.504603315@f203.i.mail.ru> Message-ID: I assumed that would work, but you can also specify the packages on your `-- stack [..]` line in imap.hs I may be overrlooking something. HTH, Adam On Mon, 3 Apr 2017 at 16:17 Alexey Egorov via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hello haskellers, > > I'm trying to use stack scripting capabilities, but it gives me an error > (and suggestion to fix it by adding some lines to extra-deps in > config.yaml). > However, adding this lines to config.yaml doesn't change anything. My > script and config are here - https://pastebin.com/PyRMQtqw > > Any help would be appreciated. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jan.loewenstein at gmail.com Mon Apr 3 16:06:04 2017 From: jan.loewenstein at gmail.com (=?UTF-8?Q?Jan_von_L=C3=B6wenstein?=) Date: Mon, 03 Apr 2017 16:06:04 +0000 Subject: [Haskell-cafe] HSpec & Monads Message-ID: Hi, I have got a typeclass (MonadResource) that represents a client side rest resource and encapsulates http interaction with a server. Inside a `runResource` I want to do arbitrary calls to the server. I have a separate implementation running in `runResourceStub` that is a fake implementation allowing for tests that don't need a real server. I am unsure how to (best) integrate that with HSpec. ``` it "can create related backend resources" $ do runResourceStub $ do pod <- createPod "my-pod" ... secret <- createSecret... (getPod secret) `shouldBe` pod ``` That is what I would like to do. How do I do it? What else should I consider doing? Best Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Apr 3 16:08:59 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 3 Apr 2017 19:08:59 +0300 Subject: [Haskell-cafe] stack ignores my config.yaml? In-Reply-To: References: <1491228908.504603315@f203.i.mail.ru> Message-ID: The new script command was explicitly designed to ignore local configuration files to allow for complete reproducibility, which has historically been quite difficult with `runghc`. If instead you _do_ want to respect local config, you should use the previous `runghc` command approach. On Mon, Apr 3, 2017 at 7:04 PM, Adam Bergmark wrote: > I assumed that would work, but you can also specify the packages on your > `-- stack [..]` line in imap.hs > > I may be overrlooking something. > > HTH, > Adam > > > On Mon, 3 Apr 2017 at 16:17 Alexey Egorov via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Hello haskellers, >> >> I'm trying to use stack scripting capabilities, but it gives me an error >> (and suggestion to fix it by adding some lines to extra-deps in >> config.yaml). >> However, adding this lines to config.yaml doesn't change anything. My >> script and config are here - https://pastebin.com/PyRMQtqw >> >> Any help would be appreciated. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 electreg at list.ru Mon Apr 3 16:32:20 2017 From: electreg at list.ru (=?UTF-8?B?QWxleGV5IEVnb3Jvdg==?=) Date: Mon, 03 Apr 2017 19:32:20 +0300 Subject: [Haskell-cafe] =?utf-8?q?stack_ignores_my_config=2Eyaml=3F?= In-Reply-To: References: <1491228908.504603315@f203.i.mail.ru> Message-ID: <1491237140.312043635@f341.i.mail.ru> So what is preferred way to use packages together with script command? I'm added all this packages to stack arguments, and now it prints: > Local packages are not allowed when using the script command >Понедельник, 3 апреля 2017, 21:09 +05:00 от Michael Snoyman : > >The new script command was explicitly designed to ignore local configuration files to allow for complete reproducibility, which has historically been quite difficult with `runghc`. If instead you _do_ want to respect local config, you should use the previous `runghc` command approach. > >On Mon, Apr 3, 2017 at 7:04 PM, Adam Bergmark < adam at bergmark.nl > wrote: >>I assumed that would work, but you can also specify the packages on your `-- stack [..]` line in imap.hs >> >>I may be overrlooking something. >> >>HTH, >>Adam >> >> >>On Mon, 3 Apr 2017 at 16:17 Alexey Egorov via Haskell-Cafe < haskell-cafe at haskell.org > wrote: >>>Hello haskellers, >>> >>>I'm trying to use stack scripting capabilities, but it gives me an error (and suggestion to fix it by adding some lines to extra-deps in config.yaml). >>>However, adding this lines to config.yaml doesn't change anything. My script and config are here -  https://pastebin.com/PyRMQtqw   >>> >>>Any help would be appreciated. _______________________________________________ >>>Haskell-Cafe mailing list >>>To (un)subscribe, modify options or view 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 michael at snoyman.com Mon Apr 3 16:33:53 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 3 Apr 2017 19:33:53 +0300 Subject: [Haskell-cafe] stack ignores my config.yaml? In-Reply-To: <1491237140.312043635@f341.i.mail.ru> References: <1491228908.504603315@f203.i.mail.ru> <1491237140.312043635@f341.i.mail.ru> Message-ID: The error message is misleading. The script command only allows you to use packages that exist in a snapshot. If you want to include additional packages, reverting to the runghc command is the right approach. On Mon, Apr 3, 2017 at 7:32 PM, Alexey Egorov wrote: > So what is preferred way to use packages together with script command? > I'm added all this packages to stack arguments, and now it prints: > > Local packages are not allowed when using the script command > > > Понедельник, 3 апреля 2017, 21:09 +05:00 от Michael Snoyman < > michael at snoyman.com>: > > > The new script command was explicitly designed to ignore local > configuration files to allow for complete reproducibility, which has > historically been quite difficult with `runghc`. If instead you _do_ want > to respect local config, you should use the previous `runghc` command > approach. > > On Mon, Apr 3, 2017 at 7:04 PM, Adam Bergmark wrote: > > I assumed that would work, but you can also specify the packages on your > `-- stack [..]` line in imap.hs > > I may be overrlooking something. > > HTH, > Adam > > > On Mon, 3 Apr 2017 at 16:17 Alexey Egorov via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > > Hello haskellers, > > I'm trying to use stack scripting capabilities, but it gives me an error > (and suggestion to fix it by adding some lines to extra-deps in > config.yaml). > However, adding this lines to config.yaml doesn't change anything. My > script and config are here - https://pastebin.com/PyRMQtqw > > Any help would be appreciated. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 michael at snoyman.com Mon Apr 3 16:35:42 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 3 Apr 2017 19:35:42 +0300 Subject: [Haskell-cafe] stack ignores my config.yaml? In-Reply-To: References: <1491228908.504603315@f203.i.mail.ru> <1491237140.312043635@f341.i.mail.ru> Message-ID: Sorry, to clarify: I meant that the _original_ error message was misleading, the new error message about "Local packages are not allowed" is correct. On Mon, Apr 3, 2017 at 7:33 PM, Michael Snoyman wrote: > The error message is misleading. The script command only allows you to use > packages that exist in a snapshot. If you want to include additional > packages, reverting to the runghc command is the right approach. > > On Mon, Apr 3, 2017 at 7:32 PM, Alexey Egorov wrote: > >> So what is preferred way to use packages together with script command? >> I'm added all this packages to stack arguments, and now it prints: >> > Local packages are not allowed when using the script command >> >> >> Понедельник, 3 апреля 2017, 21:09 +05:00 от Michael Snoyman < >> michael at snoyman.com>: >> >> >> The new script command was explicitly designed to ignore local >> configuration files to allow for complete reproducibility, which has >> historically been quite difficult with `runghc`. If instead you _do_ want >> to respect local config, you should use the previous `runghc` command >> approach. >> >> On Mon, Apr 3, 2017 at 7:04 PM, Adam Bergmark wrote: >> >> I assumed that would work, but you can also specify the packages on your >> `-- stack [..]` line in imap.hs >> >> I may be overrlooking something. >> >> HTH, >> Adam >> >> >> On Mon, 3 Apr 2017 at 16:17 Alexey Egorov via Haskell-Cafe < >> haskell-cafe at haskell.org> wrote: >> >> Hello haskellers, >> >> I'm trying to use stack scripting capabilities, but it gives me an error >> (and suggestion to fix it by adding some lines to extra-deps in >> config.yaml). >> However, adding this lines to config.yaml doesn't change anything. My >> script and config are here - https://pastebin.com/PyRMQtqw >> >> Any help would be appreciated. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 sandeepcr2 at gmail.com Tue Apr 4 00:48:57 2017 From: sandeepcr2 at gmail.com (Sandeep Cr) Date: Tue, 4 Apr 2017 06:18:57 +0530 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? Message-ID: Hello all, What is a good data type for storing and manipulating monetary values in a typical web application with payment processing? What are the pros and cons of various options like Data.Scientific, Rational and Decimal? -------------- next part -------------- An HTML attachment was scrubbed... URL: From targen at gmail.com Tue Apr 4 05:05:36 2017 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Tue, 4 Apr 2017 02:05:36 -0300 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: On Mon, Apr 3, 2017 at 9:50 PM Sandeep Cr wrote: > What is a good data type for storing and manipulating monetary values in a typical web application with payment processing? What are the pros and cons of various options like Data.Scientific, Rational and Decimal? It depends on what sort of computation you'll be doing upon those monetary values and on the expectations of your users. It's typical that payment processing applications sacrifice precision and instead prefer to deal in exact quantities, in which case you probably want some fixed-precision type with cents, and you'll want to be quite careful about your arithmetic. I insist that this is not necessarily what you want depending on the expectations of your users and I would recommend reviewing the usual go-to piece of literature on the hazards of numerical computing: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html I would say you ought to pick your semantics first, and then find the types that match, which is indeed secondary. Avoid any universal nuance-free advice like "never use floating point" or "use integers for cents" as conventional wisdom on this topic is often wrong for many applications. Check whether regulatory compliance affects your choice of semantics. From saurabhnanda at gmail.com Tue Apr 4 11:21:02 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Tue, 4 Apr 2017 16:51:02 +0530 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: Hi Manuel, Thank you for your reply. Some clarifications below... > It depends on what sort of computation you'll be doing upon those > monetary values and on the expectations of your users. It's typical > that payment processing applications sacrifice precision and instead > prefer to deal in exact quantities Is there a document which explains common use-cases for monetary values and best-practices for dealing with them? Any guidelines for which **Haskell** data-types to use for what kind of monetary calculations? Here is what we are doing in our app: * Powering web-based e-commerce checkout flows * Allowing store owners to input tax rates * Allowing end-customers to see product prices in different currencies (so, currency conversion) * Various reports to see total sales, total receivables, and total payables (basically a **very** small subset of small-business accounting) * Exporting data to full-fledged accounting systems, like Quickbooks and Xero. Based on this use-case, which Haskell data-type would you suggest? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simons at nospf.cryp.to Tue Apr 4 11:50:19 2017 From: simons at nospf.cryp.to (Peter Simons) Date: Tue, 04 Apr 2017 13:50:19 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? References: Message-ID: <87k270ie84.fsf@write-only.cryp.to> Hi Saurabh, a good place to start might be the "Amount" type provided by the hleder-lib package: http://hackage.haskell.org/package/hledger-lib-1.2/docs/Hledger-Data-Types.html#t:Amount It is based on 'Decimal': http://hackage.haskell.org/package/Decimal Best regards, Peter From dct25-561bs at mythic-beasts.com Tue Apr 4 12:58:30 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Tue, 4 Apr 2017 13:58:30 +0100 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: On 4 Apr 2017 13:57, "David Turner" wrote: > It's the currency conversions that will provide the most interesting > challenges in that list. If you were only working in a single currency then > something based on `Integer` would, I think, be fine. Perhaps `Int` or > `Int64` if you needed the extra speed. > > There are a number of different ways to implement multiple currencies > depending on your desired semantics and applicable accounting rules and > regulations. Peter Selinger has a good tutorial covering this at > http://www.mathstat.dal.ca/~selinger/accounting/tutorial.html > > One thing to watch out for: do you want to be able to do arithmetic on > amounts from different currencies? As in, do you want £5 + $5 to have a > meaningful result? If you can avoid this, life will be much simpler. > > > > On 4 Apr 2017 12:22, "Saurabh Nanda" wrote: > >> Hi Manuel, >> >> Thank you for your reply. Some clarifications below... >> >> >>> It depends on what sort of computation you'll be doing upon those >>> monetary values and on the expectations of your users. It's typical >>> that payment processing applications sacrifice precision and instead >>> prefer to deal in exact quantities >> >> >> Is there a document which explains common use-cases for monetary values >> and best-practices for dealing with them? Any guidelines for which >> **Haskell** data-types to use for what kind of monetary calculations? >> >> Here is what we are doing in our app: >> >> * Powering web-based e-commerce checkout flows >> * Allowing store owners to input tax rates >> * Allowing end-customers to see product prices in different currencies >> (so, currency conversion) >> * Various reports to see total sales, total receivables, and total >> payables (basically a **very** small subset of small-business accounting) >> * Exporting data to full-fledged accounting systems, like Quickbooks and >> Xero. >> >> Based on this use-case, which Haskell data-type would you suggest? >> >> -- Saurabh. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Tue Apr 4 13:46:55 2017 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 4 Apr 2017 15:46:55 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: 2017-04-04 7:05 GMT+02:00 Manuel Gómez : > [...] Check whether regulatory compliance affects your choice of > semantics. > This is the most important advice: You'll probably run into legal trouble if you choose e.g. the wrong rounding mode, and for a good reason: If you handle millions of transactions in your system and sneakily always round cents "into your own pocket", you'll be a rich man. That's the reason behind the tons of rounding modes in e.g. http://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html. Ask your local lawyer which is the right one. ;-) I have serious doubts that you can handle such things with a floating point representation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Tue Apr 4 14:00:35 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Tue, 4 Apr 2017 19:30:35 +0530 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: > > > This is the most important advice: You'll probably run into legal trouble > if you choose e.g. the wrong rounding mode, and for a good reason: If you > handle millions of transactions in your system and sneakily always round > cents "into your own pocket", you'll be a rich man. That's the reason > behind the tons of rounding modes in e.g. http://docs.oracle.com/javase/ > 8/docs/api/java/math/BigDecimal.html. Ask your local lawyer which is the > right one. ;-) I have serious doubts that you can handle such things with a > floating point representation. > That's an important point you raise. Leaving aside the legal aspects of this, what would be Haskell's equivalent of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at kazik.de Tue Apr 4 14:13:00 2017 From: alex at kazik.de (ALeX Kazik) Date: Tue, 4 Apr 2017 16:13:00 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: > Leaving aside the legal aspects of this, what would be Haskell's equivalent > of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? Rational? ALeX. From dct25-561bs at mythic-beasts.com Tue Apr 4 14:44:14 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Tue, 4 Apr 2017 15:44:14 +0100 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: `Data.Decimal.Decimal` is quite close to Java's `BigDecimal` in intent but not quite the same: Java's `BigDecimal` has a 32-bit signed exponent whereas Haskell's `Decimal`'s exponent is 8-bit and unsigned. The difference shouldn't matter for the purposes of tracking money since accountancy rules are generally designed to prefer (carefully specified) rounding over keeping track of numbers with hundreds of decimal places. On 4 April 2017 at 15:13, ALeX Kazik wrote: > > Leaving aside the legal aspects of this, what would be Haskell's > equivalent > > of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? > > Rational? > > 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 jo at durchholz.org Tue Apr 4 14:50:15 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 4 Apr 2017 16:50:15 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Am 04.04.2017 um 16:13 schrieb ALeX Kazik: >> Leaving aside the legal aspects of this, what would be Haskell's equivalent >> of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? > > Rational? You'd be constantly be doing explicit calculations to get back to a denominator of 100. Plus you'd have to deal with those cases where the denominator is a divisor of 100, and you'd need explicit nonstandard conversion to strings. From dct25-561bs at mythic-beasts.com Tue Apr 4 15:10:46 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Tue, 4 Apr 2017 16:10:46 +0100 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> References: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Message-ID: On 4 April 2017 at 15:50, Joachim Durchholz wrote: > Am 04.04.2017 um 16:13 schrieb ALeX Kazik: > >> Leaving aside the legal aspects of this, what would be Haskell's >>> equivalent >>> of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? >>> >> >> Rational? >> > > You'd be constantly be doing explicit calculations to get back to a > denominator of 100. Plus you'd have to deal with those cases where the > denominator is a divisor of 100, and you'd need explicit nonstandard > conversion to strings. The same sort of fiddling-the-denominator problems also occur if you use `Decimal` - it's not normally useful to be able to represent things smaller than £0.01 (or whatever the smallest unit of your local currency is); I'd even go as far as to say it's useful to be able to be sure that you _can't_ represent such things (in the domain of basic accounting at least - more complex things may deal with smaller fractions of currency, so YMMV etc). Cheers, > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saurabhnanda at gmail.com Tue Apr 4 15:11:22 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Tue, 4 Apr 2017 20:41:22 +0530 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> References: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Message-ID: Curious to know what StanChart is using to represent monetary values in its Haskell code. -- Saurabh. On Tue, Apr 4, 2017 at 8:20 PM, Joachim Durchholz wrote: > Am 04.04.2017 um 16:13 schrieb ALeX Kazik: > >> Leaving aside the legal aspects of this, what would be Haskell's >>> equivalent >>> of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? >>> >> >> Rational? >> > > You'd be constantly be doing explicit calculations to get back to a > denominator of 100. Plus you'd have to deal with those cases where the > denominator is a divisor of 100, and you'd need explicit nonstandard > conversion to strings. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- http://www.saurabhnanda.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Apr 4 15:20:12 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 4 Apr 2017 11:20:12 -0400 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Message-ID: On Tue, Apr 4, 2017 at 11:10 AM, David Turner wrote: > it's not normally useful to be able to represent things smaller than £0.01 > (or whatever the smallest unit of your local currency is) Currency conversion was specifically mentioned, and from what I have seen the convention there is to go to tenths of the local smallest unit of currency. Going to the smallest unit itself in the presence of currency conversions is problematic. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Tue Apr 4 15:34:34 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 4 Apr 2017 17:34:34 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Message-ID: Am 04.04.2017 um 17:10 schrieb David Turner: > On 4 April 2017 at 15:50, Joachim Durchholz > wrote: > > Am 04.04.2017 um 16:13 schrieb ALeX Kazik: > > Rational? > > You'd be constantly be doing explicit calculations to get back to a > denominator of 100. Plus you'd have to deal with those cases where > the denominator is a divisor of 100, and you'd need explicit > nonstandard conversion to strings. > > > > The same sort of fiddling-the-denominator problems also occur if you use > `Decimal` - it's not normally useful to be able to represent things > smaller than £0.01 (or whatever the smallest unit of your local currency > is); I'd even go as far as to say it's useful to be able to be sure that > you _can't_ represent such things (in the domain of basic accounting at > least - more complex things may deal with smaller fractions of currency, > so YMMV etc). Decimal has a roundTo function, Rational does not. From jo at durchholz.org Tue Apr 4 15:53:23 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 4 Apr 2017 17:53:23 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: Am 04.04.2017 um 15:46 schrieb Sven Panne: > 2017-04-04 7:05 GMT+02:00 Manuel Gómez >: > > [...] Check whether regulatory compliance affects your choice of > semantics. > > > This is the most important advice: You'll probably run into legal > trouble if you choose e.g. the wrong rounding mode, I have yet to hear about *any* case where that led to legal issues. Most cases would be laughed out of court anyway - nobody litigates for 0.5 cents. The PR backlash could be much worse. > and for a good > reason: If you handle millions of transactions in your system and > sneakily always round cents "into your own pocket", you'll be a rich > man. Actually they're insignificant unless you're doing very specialized stuff (microtransactions, long-running debt repayment plans). E.g. for currency conversion, you set a spread which is typically way above any round-off profit you could make. I.e. from a business perspective, it's pointless to try that under most circumstances. > That's the reason behind the tons of rounding modes in e.g. > http://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html. I think these rounding modes have two origins, one of them in the IEEE standard for floating-point numbers, the other is financial calculations. Note that it doesn't matter much which of the modes you use as long as it's reasonable (that's why some countries have "banker's rounding"). You *might* still run into regulations, of course, but I'm pretty sure that if you stick with a specific rounding mode it's essentially okay. Otherwise it would be pretty difficult to run a business with branches in Europe and America, after all. > I have serious doubts that > you can handle such things with a floating point representation. Yeah, floating point is a no-go for monetary values. They can be the right tool when combining percentages, or actualy any factor that is supposed to be multiplied with a monetary value. From frederic.cogny at gmail.com Tue Apr 4 16:21:21 2017 From: frederic.cogny at gmail.com (Frederic Cogny) Date: Tue, 04 Apr 2017 16:21:21 +0000 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <1964bc13-804c-d8b7-a946-804f8f6dd328@durchholz.org> Message-ID: >From memory: At StanChart the Haskell library is mostly used in Financial Market for derivatives pricing, the accounting and actual payment processing is done by other back-office softwares. So Double was used to represent "simulated" values (the price of a derivative being the NPV of expected cash flows) and for computing actual payments rounding rules are used with the relevant decimal (based on ISO 4217 tables). On Tue, Apr 4, 2017 at 5:16 PM Saurabh Nanda wrote: > Curious to know what StanChart is using to represent monetary values in > its Haskell code. > > -- Saurabh. > > > On Tue, Apr 4, 2017 at 8:20 PM, Joachim Durchholz > wrote: > > Am 04.04.2017 um 16:13 schrieb ALeX Kazik: > > Leaving aside the legal aspects of this, what would be Haskell's equivalent > of the BigDecimal format in Java (or Ruby)? Decimal (as used by hledger)? > > > Rational? > > > You'd be constantly be doing explicit calculations to get back to a > denominator of 100. Plus you'd have to deal with those cases where the > denominator is a divisor of 100, and you'd need explicit nonstandard > conversion to strings. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > > -- > http://www.saurabhnanda.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Frederic Cogny +33 7 83 12 61 69 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at n-heptane.com Wed Apr 5 00:31:44 2017 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Tue, 4 Apr 2017 19:31:44 -0500 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: I once implemented a decimal library based around this PEP, https://www.python.org/dev/peps/pep-0327/ Not sure if that is a good idea or not -- but it seemed like a good idea at the time. - jeremy On Mon, Apr 3, 2017 at 7:48 PM, Sandeep Cr wrote: > Hello all, > > What is a good data type for storing and manipulating monetary values in a > typical web application with payment processing? What are the pros and cons > of various options like Data.Scientific, Rational and Decimal? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ok at cs.otago.ac.nz Wed Apr 5 03:14:37 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 5 Apr 2017 15:14:37 +1200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> > On 4/04/2017, at 11:21 PM, Saurabh Nanda wrote: > Is there a document which explains common use-cases for monetary values and best-practices for dealing with them? Any guidelines for which **Haskell** data-types to use for what kind of monetary calculations? I think you may need to talk to an accountant to find out what rounding rules are required for your application. As long as you are just adding and subtracting amounts of money, integer numbers of cents work fine. As soon as you start multiplying by percentages (to compute discounts, penalties, or taxes -- hello VAT, GST, &c -- it gets trickier. > > Here is what we are doing in our app: > > * Powering web-based e-commerce checkout flows > * Allowing store owners to input tax rates Ah. There you go. A 15% GST on $1.37 is 20.55 cents. We used to have a 12.5% GST, and 12.5% of $1.36 is 17.125 cents. > * Allowing end-customers to see product prices in different currencies (so, currency conversion) > * Various reports to see total sales, total receivables, and total payables (basically a **very** small subset of small-business accounting) There are Haskell data types that will let you compute sums and differences of money times percentages exactly. For final reporting, you will need to round. The rounding rule is *probably* the one you learned in school, but you really should check with a friendly accountant. > * Exporting data to full-fledged accounting systems, like Quickbooks and Xero. > > Based on this use-case, which Haskell data-type would you suggest? Data.Decimal doesn't do a lot, but it probably does almost everything you need. What it *doesn't* offer is operations with controlled rounding or much in the way of rounding methods (if I recall correctly IEEE decimal floats offer seven different rounding modes and the extra three, compared with binary floats, were added to support commercial calculations). It's not going to be terribly hard to program whatever rounding you need. From ok at cs.otago.ac.nz Wed Apr 5 03:20:17 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 5 Apr 2017 15:20:17 +1200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: > On 5/04/2017, at 3:53 AM, Joachim Durchholz wrote: > > Yeah, floating point is a no-go for monetary values. > They can be the right tool when combining percentages, or actualy any factor that is supposed to be multiplied with a monetary value. *Binary* floats, yes. But IEEE *decimal* floats were specifically designed to support commercial calculations, and the current COBOL standard offers decimal floats as one of three interpretations of COBOL fixed-point arithmetic. It helps to have hardware that supports decimal floats, of course. Probably no surprise that current z/Series and Power machines do, most others don't (yet). From jo at durchholz.org Wed Apr 5 05:08:23 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 5 Apr 2017 07:08:23 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: Message-ID: <516c619e-9199-6214-0113-e9c791d68011@durchholz.org> Am 05.04.2017 um 05:20 schrieb Richard A. O'Keefe: > >> On 5/04/2017, at 3:53 AM, Joachim Durchholz wrote: >> >> Yeah, floating point is a no-go for monetary values. >> They can be the right tool when combining percentages, or actualy any factor that is supposed to be multiplied with a monetary value. > > *Binary* floats, yes. But IEEE *decimal* floats Ah, right, I forgot about these. > were specifically designed to support > commercial calculations, and the current COBOL standard offers decimal floats as one > of three interpretations of COBOL fixed-point arithmetic. What languages besides Cobol actually make use of them? > It helps to have hardware that supports decimal floats, of course. Probably no > surprise that current z/Series and Power machines do, most others don't (yet). Are there any plans by Intel or AMD to support them? I'm not aware of any, but you never know. From P.Achten at cs.ru.nl Wed Apr 5 07:16:14 2017 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 5 Apr 2017 09:16:14 +0200 Subject: [Haskell-cafe] 2nd call for papers: Trends in Functional Programming, 19-21 june 2017, University of Kent, Canterbury Message-ID: <4636b658-a896-b301-7e37-1c68e5e505e6@cs.ru.nl> ----------------------------- C A L L F O R P A P E R S ----------------------------- ======== TFP 2017 =========== 18th Symposium on Trends in Functional Programming 19-21 June, 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/events/tfp17/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. TFP 2017 will be the main event of a pair of functional programming events. TFP 2017 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on 22 June. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * Soesterberg (The Netherlands) in 2014; * Inria Sophia-Antipolis (France) in 2015; * and Maryland (USA) in 2016. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2017 program chairs, Scott Owens and Meng Wang. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp17 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == INVITED SPEAKERS == Conor McBride University of Strathclyde (UK) Cătălin Hriţcu INRIA Paris (FR) == IMPORTANT DATES == Submission of draft papers: 5 May, 2017 Notification: 12 May, 2017 Registration: 11 June, 2017 TFP Symposium: 19-21 June, 2017 Student papers feedback: 29 June, 2017 Submission for formal review: 2 August, 2017 Notification of acceptance: 3 November, 2017 Camera ready paper: 2 December, 2017 == PROGRAM COMMITTEE == Co-Chairs Meng Wang University of Kent (UK) Scott Owens University of Kent (UK) PC Jeremy Yallop University of Cambridge (UK) Nicolas Wu University of Bristol (UK) Laura Castro University of A Coruña (ES) Gabriel Scherer Northeastern University (US) Edwin Brady University of St Andrews (UK) Janis Voigtländer Radboud University Nijmegen (NL) Peter Achten Radboud University Nijmegen (NL) Tom Schrijvers KU Leuven (BE) Matthew Fluet Rochester Institute of Technology (US) Mauro Jaskelioff CIFASIS/Universidad Nacional de Rosario (AG) Patricia Johann Appalachian State University (US) Bruno Oliveira The University of Hong Kong (HK) Rita Loogen Philipps-Universität Marburg (GE) David Van Horn University of Marylan (US) Soichiro Hidaka Hosei University (JP) Michał Pałka Chalmers University of Technology (SE) Sandrine Blazy University of Rennes 1 - IRISA (FR) From nikivazou at gmail.com Wed Apr 5 19:17:28 2017 From: nikivazou at gmail.com (Niki Vazou) Date: Wed, 5 Apr 2017 15:17:28 -0400 Subject: [Haskell-cafe] Getting ready for Summer of Haskell 2017 Message-ID: We are happy to announce that Summer of Haskell 2017 will host at least 8 students, funded from the Haskell community and corporate sponsors. You can find all information (including the timeline) at the Summer of Haskell new webpage: https://summer.haskell.org/ Students can submit applications from April 25th until the May 6th. We recommend that interested students start thinking about their proposals and brainstorm with potential mentors. In case you would like to participate as a student, but you have no idea what to work on, we have a page dedicated to ideas here: https://summer.haskell.org/ideas.html Teachers of FP courses at universities around the world are strongly encouraged to share this announcement with their students. Mentors, as well as everyone from the community, are encouraged to contribute ideas by sending pull requests to the Summer of Haskell repository (or contacting us): https://github.com/haskell-org/summer-of-haskell Sponsors are still welcome, as we can add more slots if the necessary funds become available. Combining our current individual donations with partial sponsors, we only need $2000 more to fund an additional student. Please consider making a small donation towards that goal. If you would like to contribute do not hesitate to contact us or donate directly: https://wiki.haskell.org/Donate_to_Haskell.org We’d like to thank our current sponsors for making this Summer of Haskell possible: haskell.org kicked things off this year by funding a student and organizing the Summer of Haskell 2017 after a successful Summer of Haskell 2016 . Asahi Net is a Japanese Internet service provider that has been running stable systems for over 25 years. They are a proud sponsor of the Summer of Haskell, and contribute to the Japanese Haskell community. Awake Networks is building a next generation network security and analytics platform. They are a proud sponsor of the Summer of Haskell and contribute broadly to the Haskell community. CodeWorld is an educational project that blends mathematics and Haskell programming into a visual playground. Chris Smith has volunteered to fund two students to work on CodeWorld in particular. Facebook uses Haskell in its anti-abuse infrastructure , and as part of that effort we open-sourced the Haxl framework which is being used at scale in production to automatically parallelise data-fetching code. We're delighted to be able to support the Haskell community's efforts by sponsoring a student for this year's Summer of Haskell. Fugue Inc. radically simplifies cloud operations with its software-defined system for dynamically orchestrating and enforcing cloud infrastructure at scale. Fugue uses Haskell in its product and is proud to sponsor a student to improve the ecosystem. Galois applies cutting-edge computer science and applied mathematics to solve difficult technological problems, delivering practical solutions tailored to our clients’ needs. Haskell and other functional programming languages are key tools we use in providing these solutions. Tweag I/O is a network of software innovation labs across Europe. We develop novel solutions and products for our clients around the world. Haskell is key to delivering fast, correct and maintainable code. We have shipped Haskell in anything from tiny web services to large high-performance compute clusters with custom hardware. We're particularly keen to help the community grow Haskell into the strongest systems programming language and ecosystem out there. We're very proud to sponsor a student this summer to help make it happen. Finally, Davean has volunteered to fund a student expressly to work on the Hadrian build system for GHC . Feel free to contact us at (nvazou at cs.umd.edu and m at jaspervdj.be) if want to help or if you have any ideas, questions, or concerns. Best, Niki Vazou & Jasper Van der Jeugt for the Haskell.org Committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Wed Apr 5 22:18:00 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 6 Apr 2017 10:18:00 +1200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: <516c619e-9199-6214-0113-e9c791d68011@durchholz.org> References: <516c619e-9199-6214-0113-e9c791d68011@durchholz.org> Message-ID: <4C703973-1E59-436F-9748-D221580A8BCB@cs.otago.ac.nz> > On 5/04/2017, at 5:08 PM, Joachim Durchholz wrote: > > What languages besides Cobol actually make use of [decimal floats]? Aside from obvious things like PL/I and ABAP, there is an official way to use decimal floats in C, if you have them. gcc is *part* of the way there. https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html Having used gcc on a machine with no hardware binary floats, where binary floats were emulated, I'd rather like to use decimal floats on my Macs. However gcc 5.3.0 on my laptop *recognises* decimal floats but just says that it's not supported on this target. The decNumber library's licences are perfectly compatible with gcc. Solaris Studio supports decimal floats on SPARCX[+] processors, for some value of "support" strictly between 0 and 1. (It knows the _Decimal64 type but you have to call special intrinsics to get the arithmetic instructions, though you _do_ get them.) > > Are there any plans by Intel or AMD to support them? > I'm not aware of any, but you never know. Perhaps if Microsoft realised that _Decimal128 is exactly what they want for Excel, and put pressure on Intel? Intel do provide a decimal floating point *library* https://software.intel.com/en-us/articles/intel-decimal-floating-point-math-library http://www.netlib.org/misc/intel/ so in *some* sense they already support decimal floats. The date in the README file is "August 15, 2011", so we've had an "official" decimal floating point library for Intel systems for nearly 8 years (first release in 2009). [Amusingly, the only difference between LIBRARY/RUNOSX and LIBRARY/RUNLINUX is that the OSX version has a space after "./linuxbuild".] The code is in C and has support for big-endian machines, and eula.txt is very permissive, so it looks very much as though nobody needs to go without. From dct25-561bs at mythic-beasts.com Thu Apr 6 06:32:39 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Thu, 6 Apr 2017 07:32:39 +0100 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> References: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> Message-ID: On 5 Apr 2017 04:15, "Richard A. O'Keefe" wrote: > On 4/04/2017, at 11:21 PM, Saurabh Nanda wrote: > * Allowing end-customers to see product prices in different currencies (so, currency conversion) > * Various reports to see total sales, total receivables, and total payables (basically a **very** small subset of small-business accounting) There are Haskell data types that will let you compute sums and differences of money times percentages exactly. For final reporting, you will need to round. Careful here. I've worked on systems where one of the fundamental requirements is that any sums of columns of numbers representing amounts of money _must_ add up precisely. In a situation where you apply different tax rates to different items you could either calculate the tax on each one (and round it to £0.01) or group the items together into subtotals that all had the same tax rate, then calculate the tax on the subtotal (and round it to £0.01). What you couldn't do was keep track of the precise amount of tax on each item and round it at the very end for reporting purposes only, because you had to show the tax breakdown (using numbers rounded to £0.01) and if your working calculation was more precise then the numbers in the report wouldn't always quite add up, which would upset the auditors. This is why it's frequently recommended to use an integral type representing multiples of your smallest reporting unit for representing money. The rounding rule is *probably* the one you learned in school, but you really should check with a friendly accountant. The actual rounding rule in question seemed relatively unimportant compared with the requirement that numbers in reports must add up precisely, although I also agree that you should check with an accountant. They may not even mention the columns-of-numbers-must-add-up thing because that's so fundamental it almost goes without saying. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Thu Apr 6 09:35:34 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 6 Apr 2017 11:35:34 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> Message-ID: <4138a2a5-5845-efe5-07bf-e38df35d2ba7@durchholz.org> Am 06.04.2017 um 08:32 schrieb David Turner: > They may not even mention the columns-of-numbers-must-add-up > thing because that's so fundamental it almost goes without saying. I have seen very different policies on that. From "it must be exact" to "don't worry if the difference is less than 0.5*number-of-summands because then it could be a round-off error". It all depends on whether there's somebody who wants to double-check. For taxes calculations (any percentages actually), round-off errors are unavoidable. People tend to shift them around to minimize that error - that's why taxes are typically applied to sums, not to individual summands; the per-summand tax breakdowns are then taken to be purely informative and need not add up. And then there's "creative accounting" where these differences are larger than just a round-off error - that's what auditors are trying to find, and they don't want your numbers to add up because that in itself is relevant, they want your numbers to add up because it makes their jobs easier. From amindfv at gmail.com Thu Apr 6 14:04:02 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 6 Apr 2017 09:04:02 -0500 Subject: [Haskell-cafe] [Haskell] Haskell Tools In-Reply-To: <58E60715.4090203@caesar.elte.hu> References: <58E5E82C.6060600@caesar.elte.hu> <58E60715.4090203@caesar.elte.hu> Message-ID: Moving this conversation to haskell-cafe! > El 6 abr 2017, a las 04:15, Boldizsár Németh escribió: > > Thanks for asking, I just added a note that you need to install the haskell-tools-daemon package to use the Atom plugin for Haskell Tools. > > If you want to run refactorings from a script or just without an editor, you can use haskell-tools-cli as well. > >> On 2017.04.06. 10:40, Ivan Lazar Miljenovic wrote: >> Is there support for anything except Atom at this time? >> >> I'm also unsure of what I need to install on my local machine if I >> want to try it out (do I need the daemon? or is the cli tool >> sufficient?). >> >>> On 6 April 2017 at 17:03, Boldizsár Németh wrote: >>> Dear Haskellers, >>> >>> I'm happy to announce a new tool for refactoring Haskell source code. >>> Check it out: http://haskelltools.org/ >>> >>> Best Regards, >>> Boldizsár Németh >>> _______________________________________________ >>> Haskell mailing list >>> Haskell at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell From litchard.michael at gmail.com Thu Apr 6 15:23:48 2017 From: litchard.michael at gmail.com (Michael Litchard) Date: Thu, 6 Apr 2017 08:23:48 -0700 Subject: [Haskell-cafe] Downsides of the Prompt Monad Message-ID: Could someone outline for me the downsides of using the Prompt monad? -------------- next part -------------- An HTML attachment was scrubbed... URL: From esz at posteo.de Thu Apr 6 16:18:41 2017 From: esz at posteo.de (Ertugrul =?utf-8?Q?S=C3=B6ylemez?=) Date: Thu, 06 Apr 2017 18:18:41 +0200 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: References: Message-ID: <878tnda4ri.fsf@posteo.de> > Could someone outline for me the downsides of using the Prompt monad? For one thing I find its definition to be overcomplicated for what it does. For another the same can be achieved with free monads in a more transparent and flexible manner: import Control.Monad.Free.Class data PromptF a b x = PromptF (b -> x) a deriving (Functor) prompt :: (MonadFree (PromptF a b) m) => a -> m b prompt = liftF . PromptF id Now the kinds of extra effects that you allow depends on which free monad implementation you use. If you use F, you get the equivalent of Prompt, if you use FT, you get PromptT. In the F case the iter function corresponds to runPrompt, iterM corresponds to runPromptM. In the FT case there are iterT and iterTM. Greets ertes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bertram.felgenhauer at googlemail.com Thu Apr 6 17:53:50 2017 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu, 6 Apr 2017 19:53:50 +0200 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <878tnda4ri.fsf@posteo.de> References: <878tnda4ri.fsf@posteo.de> Message-ID: <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Ertugrul Söylemez wrote: > > Could someone outline for me the downsides of using the Prompt monad? > > For one thing I find its definition to be overcomplicated for what it > does. I'm assuming that this is referring to the MonadPrompt package... If you mean the type, it's essentially the same as http://hackage.haskell.org/package/free-4.12.4/docs/src/Control-Monad-Free-Church.html#F after plugging in PromptF' p (see below). The point is to make left associative use of >=> efficient. > For another the same can be achieved with free monads in a more > transparent and flexible manner: > > import Control.Monad.Free.Class > > data PromptF a b x = PromptF (b -> x) a > deriving (Functor) More accurately, data PromptF' p x = forall a. PromptF (a -> x) (p a) (with the obvious Functor instance). The existential highlights an important design idea of the Prompt monad, namely that a monadic DSL would be specified by a GADT (p a), where `a` represents the result type of the corresponding operation. So, for a state monad, one would use data PromptState s a where Get :: PromptState s s Put :: s -> PromptState s () which defines a "get" operation without arguments that returns a value of type s, and a "put" operation that takes a value of type s, but returns nothing. This is slightly less expressive than free monads (the main loss, I believe, is that a prompt GADT cannot express that an operation is necessarily a leaf of computations; while free monads can also express non-determinism, that does not give rise to any useful guarantees for the resulting behavior, as far as I can see). I would argue that prompt GADTs are sufficient for many applications, and that thinking in terms of interfaces is more natural to many programmers than thinking in terms of unfolding computations. Cheers, Bertram P.S. it may be worth noting that MonadPrompt predates the advent of free monads in the Haskell community. From romanandreg at gmail.com Thu Apr 6 18:53:46 2017 From: romanandreg at gmail.com (=?UTF-8?B?Um9tw6FuIEdvbnrDoWxleg==?=) Date: Thu, 06 Apr 2017 18:53:46 +0000 Subject: [Haskell-cafe] [ANN] etc-0.0.0 Declarative configuration spec for Haskell projects Message-ID: Is my pleasure to announce a new library for managing configuration values on Haskell projects. Some features: * Have a versioned spec of all values your application can accept * Provides an API for gathering values from multiple sources (files, overwrite files, cli arguments, environment variables) and then composing them into a single configuration map * Gives a sane precedence over sources of the configuration value sources * Provides inspection utilities to understand why the configuration is the way it is * Provides an API that abstracts away the source of configuration values and allows easy casting into record types your application or other libraries understand * Supports both configuration files in JSON or YAML (when cabal flags are used) * Dynamically generates CLI inputs from spec configuration file Any feedback, or comments feel free to create a ticket or send me a tweet over at @romanandreg Cheers. Roman Gonzalez.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Apr 6 22:35:13 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 7 Apr 2017 10:35:13 +1200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> Message-ID: > On 6/04/2017, at 6:32 PM, David Turner wrote: > Careful here. I've worked on systems where one of the fundamental requirements is that any sums of columns of numbers representing amounts of money _must_ add up precisely. In a situation where you apply different tax rates to different items you could either calculate the tax on each one (and round it to £0.01) or group the items together into subtotals that all had the same tax rate, then calculate the tax on the subtotal (and round it to £0.01). What you couldn't do was keep track of the precise amount of tax on each item and round it at the very end for reporting purposes only, because you had to show the tax breakdown (using numbers rounded to £0.01) and if your working calculation was more precise then the numbers in the report wouldn't always quite add up, which would upset the auditors. For what it's worth, there are rounding algorithms that work on a whole bunch of numbers at once, ensuring that the total of the rounded numbers is equal to the total of the unrounded numbers. From spam at scientician.net Thu Apr 6 22:42:02 2017 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 7 Apr 2017 00:42:02 +0200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> Message-ID: On 2017-04-07 00:35, Richard A. O'Keefe wrote: > >> On 6/04/2017, at 6:32 PM, David Turner wrote: >> Careful here. I've worked on systems where one of the fundamental requirements is that any sums of columns of numbers representing amounts of money _must_ add up precisely. In a situation where you apply different tax rates to different items you could either calculate the tax on each one (and round it to £0.01) or group the items together into subtotals that all had the same tax rate, then calculate the tax on the subtotal (and round it to £0.01). What you couldn't do was keep track of the precise amount of tax on each item and round it at the very end for reporting purposes only, because you had to show the tax breakdown (using numbers rounded to £0.01) and if your working calculation was more precise then the numbers in the report wouldn't always quite add up, which would upset the auditors. > > For what it's worth, there are rounding algorithms that work on a whole bunch of numbers > at once, ensuring that the total of the rounded numbers is equal to the total of the > unrounded numbers. REFERENCES TO LITERATURE, PLEASE! (I'm not being sarcastic -- this would be very useful to almost anyone dealing with monetary amounts... anywhere.) Cheers, From heraldhoi at gmail.com Thu Apr 6 22:50:43 2017 From: heraldhoi at gmail.com (Geraldus) Date: Thu, 06 Apr 2017 22:50:43 +0000 Subject: [Haskell-cafe] [ANN] etc-0.0.0 Declarative configuration spec for Haskell projects In-Reply-To: References: Message-ID: Román González: > Was too excited delivering the newspaper that I forgot to add it to the > email: > > Github repo: https://github.com/roman/Haskell-etc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heraldhoi at gmail.com Thu Apr 6 22:52:15 2017 From: heraldhoi at gmail.com (Geraldus) Date: Thu, 06 Apr 2017 22:52:15 +0000 Subject: [Haskell-cafe] [Haskell] Haskell Tools In-Reply-To: References: <58E5E82C.6060600@caesar.elte.hu> <58E60715.4090203@caesar.elte.hu> Message-ID: Another cool thing in last few days! Thanks! чт, 6 апр. 2017 г. в 18:04, : > Moving this conversation to haskell-cafe! > > > El 6 abr 2017, a las 04:15, Boldizsár Németh > escribió: > > > > Thanks for asking, I just added a note that you need to install the > haskell-tools-daemon package to use the Atom plugin for Haskell Tools. > > > > If you want to run refactorings from a script or just without an editor, > you can use haskell-tools-cli as well. > > > >> On 2017.04.06. 10:40, Ivan Lazar Miljenovic wrote: > >> Is there support for anything except Atom at this time? > >> > >> I'm also unsure of what I need to install on my local machine if I > >> want to try it out (do I need the daemon? or is the cli tool > >> sufficient?). > >> > >>> On 6 April 2017 at 17:03, Boldizsár Németh > wrote: > >>> Dear Haskellers, > >>> > >>> I'm happy to announce a new tool for refactoring Haskell source code. > >>> Check it out: http://haskelltools.org/ > >>> > >>> Best Regards, > >>> Boldizsár Németh > >>> _______________________________________________ > >>> Haskell mailing list > >>> Haskell at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > > > _______________________________________________ > > Haskell mailing list > > Haskell at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Apr 6 23:36:13 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 7 Apr 2017 11:36:13 +1200 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values? In-Reply-To: References: <774E51B2-1A66-4674-B4F8-259164D2D2D2@cs.otago.ac.nz> Message-ID: <44C515D1-51AC-422C-B5FC-91FED2C77480@cs.otago.ac.nz> > On 7/04/2017, at 10:42 AM, Bardur Arantsson wrote: > > On 2017-04-07 00:35, Richard A. O'Keefe wrote: >> For what it's worth, there are rounding algorithms that work on a whole bunch of numbers >> at once, ensuring that the total of the rounded numbers is equal to the total of the >> unrounded numbers. > > REFERENCES TO LITERATURE, PLEASE! > > (I'm not being sarcastic -- this would be very useful to almost anyone > dealing with monetary amounts... anywhere.) I first saw mention of such an algorithm in a journal about 40 years ago. I have a more recent memory of a paper by Knuth in a volume of his collected papers that I cannot at the moment locate, but I believe this is the article: Two-Way Rounding Author: Donald E. Knuth Published in: · Journal SIAM Journal on Discrete Mathematics archive Volume 8 Issue 2, May 1995 Pages 281 - 290 Society for Industrial and Applied Mathematics Philadelphia, PA, USA table of contents doi>10.1137/S0895480194264757 Ah, FOUND IT. Selected Papers on Design of Algorithms Donald E. Knuth CSL Lecture Notes Number 191 CSLI Publications, Stanford, California. ISBN-13: 978-1-57586-582-9 ISBN-10: 1-57686-582-3 Chapter 16, pp 219-234 "Two-Way Rounding" "Given n real numbers 0 <= x1 < 1, ..., 0 <= xn < 1, and a permutation \sigma of {1,...,n}, we can always find integers x'1 \in {0,1}, ..., x'n \in {0,1} so that the partial sums x'1+...+x'k and x'\sigma[1]+...+x'\sigma[k] differ from the unrounded values x1+...+xk and x\sigma[1...+x\sigma[k] by at most n/(n+1) for 1 <= k <= n. The latter bound is the best possible." Section 1, An Application "Sometimes it is desirable to round "spreadsheet" data to larger units while preserving row and column totals and the grand total." This application to matrices has been studied by others. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.421.2051&rep=rep1&type=pdf Rounding of Sequences and Matrices, with Applications "We show that any real matrix can be rounded to an integer matrix in such a way that the rounding errors of all row sums are less than one, and the rounding errors of all column sums as well as all sums of consecutive row entries are less than two. Such roundings can be computed in linear time." http://people.mpi-inf.mpg.de/~doerr/papers/unbimatround.pdf Unbiased Matrix Rounding "We show several ways to round a real matrix to an integer one such that the rounding errors in all rows and columns as well as the whole matrix are less than one. ... our roundings also have a rounding error of less than one in all initial intervals of rows and columns. Consequently, arbitrary intervals have an error of at most two. ... The same result can be obtained via (dependent) randomized rounding. This has the additional advantage that the rounding is unbiased." Here's a bunch of less formal discussions of the 1D case. http://stackoverflow.com/questions/32544646/round-vector-of-numerics-to-integer-while-preserving-their-sum http://stackoverflow.com/questions/792460/how-to-round-floats-to-integers-while-preserving-their-sum https://explainextended.com/2009/09/21/rounding-numbers-preserving-their-sum/ https://biostatmatt.com/archives/2902 From whosekiteneverfly at gmail.com Fri Apr 7 00:28:44 2017 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Fri, 7 Apr 2017 09:28:44 +0900 Subject: [Haskell-cafe] [ANN] etc-0.0.0 Declarative configuration spec for Haskell projects In-Reply-To: References: Message-ID: Awesome! This may be the one I've wanted for a long time. As you I've often felt it's very tedious to manage the source of configurations (from the file? CLI argument? etc.). I'm going to read it in detail later, but I have one question after the first look: Why is it configured in YAML? When I tried to make a similar library, I thought it was a monadic DSL in Haskell that matches the need best. I'm interested in the reason! Thanks for the interesting library! 2017/04/07 午前3:56 "Román González" : > Is my pleasure to announce a new library for managing configuration values > on Haskell projects. > > Some features: > > * Have a versioned spec of all values your application can accept > > * Provides an API for gathering values from multiple sources (files, > overwrite files, cli arguments, environment variables) and then composing > them into a single configuration map > > * Gives a sane precedence over sources of the configuration value sources > > * Provides inspection utilities to understand why the configuration is the > way it is > > * Provides an API that abstracts away the source of configuration values > and allows easy casting into record types your application or other > libraries understand > > * Supports both configuration files in JSON or YAML (when cabal flags are > used) > > * Dynamically generates CLI inputs from spec configuration file > > Any feedback, or comments feel free to create a ticket or send me a tweet > over at @romanandreg > > Cheers. > > Roman Gonzalez.- > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at zednenem.com Fri Apr 7 04:28:24 2017 From: dave at zednenem.com (David Menendez) Date: Fri, 7 Apr 2017 00:28:24 -0400 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <878tnda4ri.fsf@posteo.de> <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: On Thu, Apr 6, 2017 at 1:53 PM, Bertram Felgenhauer via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Ertugrul Söylemez wrote: > > > Could someone outline for me the downsides of using the Prompt monad? > > > > For one thing I find its definition to be overcomplicated for what it > > does. > > I'm assuming that this is referring to the MonadPrompt package... > If you mean the type, it's essentially the same as > > http://hackage.haskell.org/package/free-4.12.4/docs/src/ > Control-Monad-Free-Church.html#F > > after plugging in PromptF' p (see below). The point is to make left > associative use of >=> efficient. > > > For another the same can be achieved with free monads in a more > > transparent and flexible manner: > > > > import Control.Monad.Free.Class > > > > data PromptF a b x = PromptF (b -> x) a > > deriving (Functor) > > More accurately, > > data PromptF' p x = forall a. PromptF (a -> x) (p a) > > (with the obvious Functor instance). > > The existential highlights an important design idea of the Prompt monad, > namely that a monadic DSL would be specified by a GADT (p a), where `a` > represents the result type of the corresponding operation. So, for a > state monad, one would use > > data PromptState s a where > Get :: PromptState s s > Put :: s -> PromptState s () > > which defines a "get" operation without arguments that returns a value > of type s, and a "put" operation that takes a value of type s, but > returns nothing. > > This is slightly less expressive than free monads (the main loss, I > believe, is that a prompt GADT cannot express that an operation is > necessarily a leaf of computations; while free monads can also express > non-determinism, that does not give rise to any useful guarantees for > the resulting behavior, as far as I can see). I would argue that prompt > GADTs are sufficient for many applications, and that thinking in terms > of interfaces is more natural to many programmers than thinking in terms > of unfolding computations. > > It’s worth noting that Prompt p is the free monad for a type constructor p, just as Free f is the free monad for a Functor f. As such, when p is a Functor, they are isomorphic. data Free f a = Var a | Wrap (f (Free f a)) newtype Prompt p a = Prompt { unPrompt :: forall b. (forall i. p i -> (i -> b) -> b) -> (a -> b) -> b } -- equivalently, Prompt p a = Done a | forall i. Prompt (p i) (i -> Prompt p a) prompt :: p a -> Prompt p a prompt p = Prompt $ \c -> c p promptFree :: Free f a -> Prompt f a promptFree (Var a) = return a promptFree (Wrap f) = prompt f >>= promptFree freePrompt :: Functor f => Prompt f a -> Free f a freePrompt m = unPrompt m (\f k -> Wrap (fmap k f)) Var Thus, it’s entirely possible to do non-determinism and halting with Prompt. Just to have a concrete example, here’s an interface that prints strings and has non-determinism. data W a where Print :: String -> W () End :: W a Choose :: a -> a -> W a Note that End and Choose are fully polymorphic. This means that an interpreter has to pass one of the two provided values to the continuation when it receives Choose, and it can’t call the continuation when it receives End. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Fri Apr 7 06:51:41 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 7 Apr 2017 09:51:41 +0300 Subject: [Haskell-cafe] Package maintainership takeover: quickcheck-instances Message-ID: The quickcheck-instances provides QuickCheck type-classes' instances for Haskell Platform packages. Unfortunately, author and current maintainer Antoine Latter is quite unresponsive. There is handful of PR open [2], and I had to use Hackage Trustee powers to allow new versions of dependencies (to keep e.g. Stackage nightly going on). I have tried to contact him to offer a co-maintainership help (at 14.12.2016). Cheers, Oleg Grenrus - [1]: http://hackage.haskell.org/package/quickcheck-instances - [2]: https://github.com/aslatter/qc-instances/pulls -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From polux2001 at gmail.com Fri Apr 7 08:42:07 2017 From: polux2001 at gmail.com (Paul Brauner) Date: Fri, 07 Apr 2017 08:42:07 +0000 Subject: [Haskell-cafe] Does this function have a name? Message-ID: Hello Haskell Cafe, I had to write the following function and I was wondering if it (or its generalization to Alternative or Traversable) was exposed by some library under a different name: first [] = Nothing first (t:ts) = fmap (:ts) (s t) <|> fmap (t:) (first ts) Somehow it is to "traverse" as "any" is to "all". Cheers, Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From polux2001 at gmail.com Fri Apr 7 08:57:23 2017 From: polux2001 at gmail.com (Paul Brauner) Date: Fri, 07 Apr 2017 08:57:23 +0000 Subject: [Haskell-cafe] Does this function have a name? In-Reply-To: References: Message-ID: Oops, there's a free variable in there, let me fix it: first f [] = Nothing first f (x:xs) = fmap (:xs) (f x) <|> fmap (x:) (first f xs) Paul On Fri, Apr 7, 2017 at 10:42 AM Paul Brauner wrote: > Hello Haskell Cafe, > > I had to write the following function and I was wondering if it (or its > generalization to Alternative or Traversable) was exposed by some library > under a different name: > > first [] = Nothing > first (t:ts) = fmap (:ts) (s t) <|> fmap (t:) (first ts) > > Somehow it is to "traverse" as "any" is to "all". > > Cheers, > Paul > -------------- next part -------------- An HTML attachment was scrubbed... URL: From esz at posteo.de Fri Apr 7 12:41:35 2017 From: esz at posteo.de (Ertugrul =?utf-8?Q?S=C3=B6ylemez?=) Date: Fri, 07 Apr 2017 14:41:35 +0200 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <878tnda4ri.fsf@posteo.de> <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <8760ig9yps.fsf@posteo.de> >> For another the same can be achieved with free monads in a more >> transparent and flexible manner: >> >> import Control.Monad.Free.Class >> >> data PromptF a b x = PromptF (b -> x) a >> deriving (Functor) > > More accurately, > > data PromptF' p x = forall a. PromptF (a -> x) (p a) > > (with the obvious Functor instance). Are we talking about the same PromptT here? I was assuming this one: . Even if not, it seems to me that it should be an abstraction layer above free monads. It could be a very thin layer around F/FT. That would facilitate reuse. Greets ertes -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From doug at cs.dartmouth.edu Fri Apr 7 13:30:52 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Fri, 07 Apr 2017 09:30:52 -0400 Subject: [Haskell-cafe] What is a safe Haskell data type to store and manipulate Money values Message-ID: <201704071330.v37DUqGp063701@tahoe.cs.Dartmouth.EDU> > REFERENCES TO LITERATURE PLEASE Another domain with pertinent literature is proportional representation in legislative bodies. Sorry, I have no particular references to offer. Doug From bertram.felgenhauer at googlemail.com Fri Apr 7 16:03:07 2017 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri, 7 Apr 2017 18:03:07 +0200 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <8760ig9yps.fsf@posteo.de> References: <878tnda4ri.fsf@posteo.de> <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <8760ig9yps.fsf@posteo.de> Message-ID: <20170407160307.GB20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Ertugrul Söylemez wrote: > >> For another the same can be achieved with free monads in a more > >> transparent and flexible manner: > >> > >> import Control.Monad.Free.Class > >> > >> data PromptF a b x = PromptF (b -> x) a > >> deriving (Functor) > > > > More accurately, > > > > data PromptF' p x = forall a. PromptF (a -> x) (p a) > > > > (with the obvious Functor instance). > > Are we talking about the same PromptT here? I was assuming this one: > . No, I'm talking about https://hackage.haskell.org/package/MonadPrompt-1.0.0.5/docs/src/Control-Monad-Prompt.html#Prompt (FWIW, I did mention the package name in my mail.) The type in the prompt package does not seem to offer the main benefit I mentioned, namely that the prompt value encodes the type of the return value of the `prompt` action; indeed, `prompt` in the prompt package has type prompt :: MonadPrompt a b m => a -> m b in contrast to prompt :: MonadPrompt p m => p a -> m a in MonadPrompt. > Even if not, it seems to me that it should be an abstraction layer above > free monads. It could be a very thin layer around F/FT. That would > facilitate reuse. MonadPrompt is a very thin standalone package... I would be quite sad to lose that property. Cheers, Bertram From bertram.felgenhauer at googlemail.com Fri Apr 7 17:01:05 2017 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Fri, 7 Apr 2017 19:01:05 +0200 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <8760ig9yps.fsf@posteo.de> References: <878tnda4ri.fsf@posteo.de> <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> <8760ig9yps.fsf@posteo.de> Message-ID: <20170407170105.GC20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Ertugrul Söylemez wrote: > >> For another the same can be achieved with free monads in a more > >> transparent and flexible manner: > >> > >> import Control.Monad.Free.Class > >> > >> data PromptF a b x = PromptF (b -> x) a > >> deriving (Functor) > > > > More accurately, > > > > data PromptF' p x = forall a. PromptF (a -> x) (p a) > > > > (with the obvious Functor instance). > > Are we talking about the same PromptT here? I was assuming this one: > . I've looked a bit more closely at the difference between the prompt and MonadPrompt packages. PromptT a b t r from the prompt package is a newtype for forall m. Monad m => (a -> m (t b)) -> m (t r) using the "universal" Cont/Codensity monad, this becomes forall x. (a -> (t b -> x) -> x) -> (t r -> x) -> x) which is quite similar to the Prompt type from MonadPrompt: forall x. (p a -> (a -> x) -> x) -> (r -> x) -> x) The main innovation in prompt seems to be the 't' argument, which according to the package's readme, can be used for short-circuiting evaluation and nondeterminism (branching computations). As I explained in my previous email, the 'p' argument in MonadPrompt is meant to describe the API of a monadic DSL. It appears that the two ideas could be combined in a single type, forall x. (p a -> (t a -> x) -> x) -> (t r -> x) -> x) or forall m. Monad m => (p a -> m (t a)) -> m (t r) or, using the free monad defined by the functor data PromptF a b x = forall a. PromptF (t a -> x) (p a) Perhaps this is worth investigating further. Cheers, Bertram From romanandreg at gmail.com Fri Apr 7 17:43:55 2017 From: romanandreg at gmail.com (=?UTF-8?B?Um9tw6FuIEdvbnrDoWxleg==?=) Date: Fri, 07 Apr 2017 17:43:55 +0000 Subject: [Haskell-cafe] [ANN] etc-0.0.0 Declarative configuration spec for Haskell projects In-Reply-To: References: Message-ID: > Why is it configured in YAML? When I tried to make a similar library, I thought it was a monadic DSL in Haskell that matches the need best. > I'm interested in the reason! Hey Yuji, The reason I picked JSON/YAML to declare the spec to be able to re-implement it in other languages we use at my current work, so the abstraction is shared among many different languages. There could be a potential to have a Builder DSL in Haskell to create the ConfigSpec record, however this puts your app config on *codeland* rather than *dataland* which may remove some flexibility. Thanks for the feedback, and hope you find the library useful. On Thu, Apr 6, 2017 at 5:28 PM Yuji Yamamoto wrote: > Awesome! > This may be the one I've wanted for a long time. > As you I've often felt it's very tedious to manage the source of > configurations (from the file? CLI argument? etc.). > > I'm going to read it in detail later, but I have one question after the > first look: > Why is it configured in YAML? When I tried to make a similar library, I > thought it was a monadic DSL in Haskell that matches the need best. > I'm interested in the reason! > > Thanks for the interesting library! > > 2017/04/07 午前3:56 "Román González" : > > Is my pleasure to announce a new library for managing configuration values > on Haskell projects. > > Some features: > > * Have a versioned spec of all values your application can accept > > * Provides an API for gathering values from multiple sources (files, > overwrite files, cli arguments, environment variables) and then composing > them into a single configuration map > > * Gives a sane precedence over sources of the configuration value sources > > * Provides inspection utilities to understand why the configuration is the > way it is > > * Provides an API that abstracts away the source of configuration values > and allows easy casting into record types your application or other > libraries understand > > * Supports both configuration files in JSON or YAML (when cabal flags are > used) > > * Dynamically generates CLI inputs from spec configuration file > > Any feedback, or comments feel free to create a ticket or send me a tweet > over at @romanandreg > > Cheers. > > Roman Gonzalez.- > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 makos999 at gmail.com Fri Apr 7 19:51:31 2017 From: makos999 at gmail.com (Akos Marton) Date: Fri, 7 Apr 2017 18:51:31 -0100 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. Message-ID: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> Dear Haskellers, The setup: Having a binary compiled on either x86 or x64 system (same installation, utilizing stack) in order to preserve compatibility against x64 systems. Actually, not to have 2 separate executable for each, that would be the overall goal. However it surprises me when running the x86 .exe utilizing Win32-2.5.4.1 package with ghc-8.0.2, reading out a registry key fails on x64 system with the following:/ / /me.exe: RegOpenKey: invalid argument (The system cannot find the file specified.)/ That would be fine, however the key does exists. When same code, same system, but the .exe built to be x64 it runs like a charm. A couple of question, which some of them eventually will not make sense, but still: - Can it be ghc code optimization issue? - but this is a runtime check in IO, if so, how? - Yes, I could use a built-in windows system command and parse the input of that; unless absolutely necessary I would not introduce another dependency (system package). Would love to solve it with the currently utilized weapons. - the issue just puzzles me... I would know the answer if possible. - Is it more library (Win32), ghc, binary I generate, issue? What library can I use to detect a system's architecture which works in this scenario? Another thing which convoluted in the issue... The function, /getSystemInfo :: IO SYSTEM_INFO, /can read out the underlying architecture. When compiled on x86 and run on x64 it would tell me: "I am running on x86". That's failure. Most importantly: what is the obvious I am missing? Thank you for your insights! Best, Akos Ps.: Would you/we need sample code to puzzle about I can quickly weld one. - not sure if necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arjenvanweelden at gmail.com Fri Apr 7 18:08:39 2017 From: arjenvanweelden at gmail.com (Arjen) Date: Fri, 07 Apr 2017 20:08:39 +0200 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. In-Reply-To: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> References: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> Message-ID: <1491588519.2165.1.camel@gmail.com> On Fri, 2017-04-07 at 18:51 -0100, Akos Marton wrote: > Dear Haskellers,  > The setup: > Having a binary compiled on either x86 or x64 system (same > installation, utilizing stack) in order to preserve compatibility > against x64 systems. Actually, not to have 2 separate executable for > each, that would be the overall goal. However it surprises me when > running the x86 .exe utilizing Win32-2.5.4.1 package with ghc-8.0.2, > reading out a registry key fails on x64 system with the following: > me.exe: RegOpenKey: invalid argument (The system cannot find the file > specified.) > That would be fine, however the key does exists. When same code, same > system, but the .exe built to be x64 it runs like a charm.  32bit and 64bit Windows executables read different keys using the same registry path. The 64bit executable can read keys from the 32bit part of the registry, but is has to use the WOW6432Node path. Maybe this will help: https://support.microsoft.com/en-us/help/305097/h ow-to-view-the-system-registry-by-using-64-bit-versions-of-windows > A couple of question, which some of them eventually will not make > sense, but still: > - Can it be ghc code optimization issue? > - but this is a runtime check in IO, if so, how? > - Yes, I could use a built-in windows system command and parse the > input of that; unless absolutely necessary I would not introduce > another dependency (system package). Would love to solve it with the > currently utilized weapons.  > - the issue just puzzles me... I would know the answer if possible. > - Is it more library (Win32), ghc, binary I generate, issue?  > What library can I use to detect a system's architecture which works > in this scenario?  > Another thing which convoluted in the issue... > The function, getSystemInfo :: IO SYSTEM_INFO, can read out the > underlying architecture. When compiled on x86 and run on x64 it would > tell me: "I am running on x86". That's failure. > > Most importantly: what is the obvious I am missing? > > Thank you for your insights!  > Best, Akos > > > > Ps.: Would you/we need sample code to puzzle about I can quickly weld > one. - not sure if necessary. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From allbery.b at gmail.com Fri Apr 7 18:09:54 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 7 Apr 2017 14:09:54 -0400 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. In-Reply-To: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> References: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> Message-ID: On Fri, Apr 7, 2017 at 3:51 PM, Akos Marton wrote: > *me.exe: RegOpenKey: invalid argument (The system cannot find the file > specified.)* > > That would be fine, however the key does exists. When same code, same > system, but the .exe built to be x64 it runs like a charm. > My guess is that the FFI call has an incorrect type somewhere and therefore passes garbage. Another thing which convoluted in the issue... > The function, *getSystemInfo :: IO SYSTEM_INFO, *can read out the > underlying architecture. When compiled on x86 and run on x64 it would tell > me: "I am running on x86". That's failure. > You can blame Windows for that one: if you run an x86 binary on x86_64, it launches the WoW subsystem emulating an x86 processor, so you will get the emulated processor reported back. There may be a different API to get the actual host --- but given that WoW exists to minimize incompatibilities for x86 software, it is likely well hidden if it exists at all. -- 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 parsonsmatt at gmail.com Fri Apr 7 18:53:39 2017 From: parsonsmatt at gmail.com (Matt) Date: Fri, 7 Apr 2017 12:53:39 -0600 Subject: [Haskell-cafe] Does this function have a name? In-Reply-To: References: Message-ID: I think you're looking at the Monoid instance for First: λ> import Data.Monoid λ> let first f = getFirst . foldMap (First . f) λ> first (\x -> guard (x > 2) *> pure x) [1..10] Just 3 Matt Parsons On Fri, Apr 7, 2017 at 2:57 AM, Paul Brauner wrote: > Oops, there's a free variable in there, let me fix it: > > first f [] = Nothing > first f (x:xs) = fmap (:xs) (f x) <|> fmap (x:) (first f xs) > > Paul > > On Fri, Apr 7, 2017 at 10:42 AM Paul Brauner wrote: > >> Hello Haskell Cafe, >> >> I had to write the following function and I was wondering if it (or its >> generalization to Alternative or Traversable) was exposed by some library >> under a different name: >> >> first [] = Nothing >> first (t:ts) = fmap (:ts) (s t) <|> fmap (t:) (first ts) >> >> Somehow it is to "traverse" as "any" is to "all". >> >> Cheers, >> Paul >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 polux2001 at gmail.com Fri Apr 7 19:24:12 2017 From: polux2001 at gmail.com (Paul Brauner) Date: Fri, 07 Apr 2017 19:24:12 +0000 Subject: [Haskell-cafe] Does this function have a name? In-Reply-To: References: Message-ID: Hi Matt, this isn't exactly the same thing I think. My function replaces the first element in the list for which f returns (Just x) by x, and leaves the rest of the list untouched. Paul On Fri, Apr 7, 2017, 20:53 Matt wrote: > I think you're looking at the Monoid instance for First: > > λ> import Data.Monoid > λ> let first f = getFirst . foldMap (First . f) > λ> first (\x -> guard (x > 2) *> pure x) [1..10] > Just 3 > > > > Matt Parsons > > On Fri, Apr 7, 2017 at 2:57 AM, Paul Brauner wrote: > > Oops, there's a free variable in there, let me fix it: > > first f [] = Nothing > first f (x:xs) = fmap (:xs) (f x) <|> fmap (x:) (first f xs) > > Paul > > On Fri, Apr 7, 2017 at 10:42 AM Paul Brauner wrote: > > Hello Haskell Cafe, > > I had to write the following function and I was wondering if it (or its > generalization to Alternative or Traversable) was exposed by some library > under a different name: > > first [] = Nothing > first (t:ts) = fmap (:ts) (s t) <|> fmap (t:) (first ts) > > Somehow it is to "traverse" as "any" is to "all". > > Cheers, > Paul > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Fri Apr 7 21:00:31 2017 From: david.feuer at gmail.com (David Feuer) Date: Fri, 7 Apr 2017 17:00:31 -0400 Subject: [Haskell-cafe] Downsides of the Prompt Monad In-Reply-To: <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <878tnda4ri.fsf@posteo.de> <20170406175350.GA20206@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: On Thu, Apr 6, 2017 at 1:53 PM, Bertram Felgenhauer via Haskell-Cafe wrote: > data PromptF' p x = forall a. PromptF (a -> x) (p a) This PromptF' is just Coyoneda. I don't know about your fancier version as yet. David From salas.sb at gmail.com Fri Apr 7 22:39:50 2017 From: salas.sb at gmail.com (Salas Sanchez-Bennasar) Date: Fri, 7 Apr 2017 16:39:50 -0600 Subject: [Haskell-cafe] LambdaConf standard registration opens Message-ID: http://lambdaconf.us/events/2017/lcusc.html LambdaConf is one of the largest functional programming conferences in the world, focused on foundational concepts (such as lambda calculus, type theory, category theory), functional programming languages (Haskell, Scala, PureScript, F#, Clojure, Elixir, and more), new languages and approaches in functional programming, functional programming libraries, and related areas such as dependent types, proof systems, parallel array programming, functional GPU processing, and more. Standard registration is now open at Eventbrite: https://www.eventbrite.com/e/lambdaconf-2017-registration-29839799644 A complete list of sessions is online, including the following highlights: * 6 keynotes, including one on using Haskell to model life on the blockchain, one on how programmers brains work, and one on the axes of abstraction; * 8 leap workshops, including an in-depth workshop on category theory, one on optics, and one on building front-ends using PureScript Halogen; * 12 hop workshops, including one introducing Coq, another diving into recursion schemes, and another teaching functional data processing; * 9 de novo sessions, including on one formally specified digital logic, one on algebraic and monadic composability for distributed computing, and one on type-level REST programming; * 21 educational sessions, including one on Free monads, one on high-performance Haskell, one on codata and corecursion, one on FP on Android using Frege, and another on dependently-typed programming in Haskell; * 21 inspire sessions, including one on dependent-pairs, one on generative design, and one on type singletons. This is more than 110 hours of content, with enough variety and difficulty level for everyone. Speakers are book authors, contributors to open source libraries, researchers, and practicing functional programmers. The conference takes place in Boulder, Colorado, from May 25 - 27, at the University of Colorado Boulder in the foothills of the Rocky Mountains. Conference registration includes all sessions (including workshops), locally-catered breakfast and lunch on Thursday, Friday, and Saturday; a conference dinner on Friday night; a choice from a variety of networking activities on Sunday; free childcare and STEM workshops for children; all-gender restrooms and handicapped-accessible venues. Videos from some previous events can be found here: https://www.youtube.com/ channel/UCEtohQeDqMSebi2yvLMUItg; and here: https://www.youtube.com/ watch?v=JxC1ExlLjgw&list=PLE7tQUdRKcybh21_zOg8_y4f2oMKDHpUS The conference is preceded by commercial training opportunities on Monday - Tuesday, including: * Up & Running with Elixir & Phoenix, by Brooklyn Zelenka * Applied Haskell, by Michael Snoyman * Advanced FP in Scala, by John A. De Goes * Introduction to FP, by David Koontz * Mastering Apache Spark, by Pawel Szulc * Mastering Elm, by Isaac Shapira On Wednesday, several free mini-conferences are co-located with LambdaConf: * PureScript Conf 2017 * Introduction to FP with Haskell For more information on LambdaConf, the commercial training workshops, or the mini-conferences, please visit the website: http://lambdaconf.us/events/2017/lcusc.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From p75213 at gmail.com Sat Apr 8 01:44:08 2017 From: p75213 at gmail.com (p75213 at gmail.com) Date: Sat, 8 Apr 2017 11:44:08 +1000 Subject: [Haskell-cafe] State monad exit Message-ID: <2d5c27d4-ec2a-66a2-76ae-9d750433c347@gmail.com> Hi, I am playing around with the State monad and queues. At the moment I have the following code: {-# LANGUAGE ViewPatterns, FlexibleContexts #-} module Main where import Criterion.Main import Control.Monad.State.Lazy import Data.Maybe (fromJust) import Data.Sequence ((<|), ViewR ((:>))) import qualified Data.Sequence as S -------------------------------------------------------- data Queue a = Queue { enqueue :: [a], dequeue :: [a] } deriving (Eq, Show) -- adds an item push :: a -> Queue a -> Queue a push a q = Queue (a:enqueue q) (dequeue q) pop :: Queue a -> Maybe (a, Queue a) pop q = if null (dequeue q) then go $ Queue [] (reverse (enqueue q)) else go q where go (Queue _ []) = Nothing go (Queue en (x:de)) = Just (x, Queue en de) queueTst :: Int -> Queue Int -> Queue Int queueTst 0 q = q queueTst n q | even n = queueTst (n - 1) (push (100 + n) q) | otherwise = queueTst (n - 1) (if popped == Nothing then q else snd (fromJust popped)) where popped = pop q ------------------------------------------------------------- pushS :: a -> S.Seq a -> S.Seq a pushS a s = a <| s pushS' :: a -> State (S.Seq a) (Maybe a) pushS' a = do s <- get put (a <| s) return Nothing pushS'' :: a -> State (S.Seq a) (Maybe a) pushS'' a = get >>= (\g -> put (a <| g)) >> return Nothing popS :: S.Seq a -> Maybe (a, S.Seq a) popS (S.viewr -> S.EmptyR) = Nothing popS (S.viewr -> s:>r) = Just (r,s) popS' :: State (S.Seq a) (Maybe a) popS' = do se <- get let sl = popS'' se put $ snd sl return $ fst sl where popS'' (S.viewr -> S.EmptyR) = (Nothing, S.empty) popS'' (S.viewr -> beg:>r) = (Just r, beg) queueTstS :: Int -> S.Seq Int -> S.Seq Int queueTstS 0 s = s queueTstS n s | even n = queueTstS (n - 1) (pushS (100 + n) s) | otherwise = queueTstS (n - 1) (if popped == Nothing then s else snd (fromJust popped)) where popped = popS s queueTstST :: Int -> State (S.Seq Int) (Maybe Int) queueTstST n = if (n > 0) then if even n then pushS' (100 + n) >> queueTstST (n - 1) else popS' >> queueTstST (n - 1) else return Nothing main1 :: IO () main1 = defaultMain [ bench "Twin Queue" $ whnf (queueTst 550) (Queue [500,499..1] []) , bench "Sequence Queue" $ whnf (queueTstS 550) (S.fromList [500,499..1]) , bench "State Queue" $ whnf (runState (queueTstST 550)) (S.fromList [500,499..1]) ] -------------------------------------------------------------------------------------------------------------------------------------------------- In the function "queueTstST" is there a way to exit while retaining the last "Maybe value" rather than with "Nothing"? From timotej.tomandl at gmail.com Sat Apr 8 04:03:00 2017 From: timotej.tomandl at gmail.com (Timotej Tomandl) Date: Sat, 8 Apr 2017 06:03:00 +0200 Subject: [Haskell-cafe] Eliminating phantom type Message-ID: Hi, I have stumbled upon the Control-Monad-ST2 package by Kevin Backhouse, I have decided to expand the code with a run function and replace IO with ST s; and as of now I have removed the functions working on arrays and conversion to IO for the sake of simplicity. Here is the code in its modified form with newtype wrappers removed: {-# LANGUAGE RankNTypes #-} {-# LANGUAGE DeriveFunctor #-} -- Copyright 2013 Kevin Backhouse. -- Copyright 2017 Timotej Tomandl. Modifications import Data.STRef import Control.Monad.ST import Control.Applicative import Control.Monad newtype ST2 r w s a = ST2 { unwrapST2 :: ST s a } deriving (Functor) instance Monad (ST2 r w s) where return x = ST2 $ return x (ST2 m) >>= f = ST2 $ do x <- m unwrapST2 (f x) instance Applicative (ST2 r w s) where pure = return (<*>) = ap -- | This function checks that the sub-computation is polymorphic in -- both type parameters. This means that the sub-computation does not -- read or write any state from the enclosing context. {-# INLINE pureST2 #-} pureST2 :: (forall r w. ST2 r w s a) -> ST2 r' w' s a pureST2 m = m -- | This function checks that the computation is polymorphic in -- both parameters and then returns a pure value {-# INLINE runST2 #-} runST2 :: (forall r w s. ST2 r w s a) -> a runST2 m=runST $ unwrapST2 m -- | This function checks that the sub-computation is polymorphic in -- the @w@ type parameter. This means that the sub-computation does -- not write any state from the enclosing context (but read-only -- operations are permitted). {-# inline readOnlyST2 #-} readOnlyST2 :: (forall w. ST2 r w s a) -> ST2 r w' s a readOnlyST2 m = m -- | Mutable reference. 'ST2Ref' is actually just a newtype of an -- 'STRef', but the @r@ and @w@ type parameters allow the read and -- write dependencies to be tracked by the type system. newtype ST2Ref r w s a = ST2Ref (STRef s a) -- | Create a new reference. The @r@ and @w@ type parameters of the -- reference are unified with the 'ST2' monad to indicate that new -- state is created in the enclosing context. {-# INLINE newST2Ref #-} newST2Ref :: a -> ST2 r w s (ST2Ref r w s a) newST2Ref x = ST2 $ do r <- newSTRef x >>= \ var -> return var return (ST2Ref r) -- | Read a reference. The @w@ type parameter of the reference is not -- unified with the 'ST2' monad to indicate that this access is -- read-only. {-# INLINE readST2Ref #-} readST2Ref :: ST2Ref r w s a -> ST2 r w' s a readST2Ref (ST2Ref r) = ST2 $ readSTRef r -- | Write to a reference. The @w@ type parameter of the reference is -- unified with the 'ST2' monad to indicate that state is written in -- the enclosing context. {-# INLINE writeST2Ref #-} writeST2Ref :: ST2Ref r w s a -> a -> ST2 r w s () writeST2Ref (ST2Ref r) x = ST2 $ writeSTRef r x -- | Modify a reference. {-# INLINE modifyST2Ref #-} modifyST2Ref :: ST2Ref r w s a -> (a -> a) -> ST2 r w s () modifyST2Ref (ST2Ref r) f = ST2 $ modifySTRef r f But as you can see, now all my types got tainted by s even though sharing the same r or w implies sharing the same s. Is there a way how to hide s from the type signatures, but still preserve an ability to write runST2 without resorting to IO/RealWorld? I have tried writing such a function and failed. Timotej Tomandl -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Sat Apr 8 11:55:23 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Sat, 8 Apr 2017 07:55:23 -0400 Subject: [Haskell-cafe] Eliminating phantom type In-Reply-To: References: Message-ID: <15a0c7dd-29a4-89a9-aad0-26ed5a9310cf@gmail.com> Hi Timotej, It seems you can merge r and s. This solution seems to rely on features that are very specific to the set of effects you want to model, but I couldn't pinpoint what these are. newtype ST2 r w a = ST2 { unwrapST2 :: ST r a } Li-yao From monkleyon at gmail.com Sat Apr 8 11:57:01 2017 From: monkleyon at gmail.com (MarLinn) Date: Sat, 8 Apr 2017 13:57:01 +0200 Subject: [Haskell-cafe] Eliminating phantom type In-Reply-To: References: Message-ID: <15c718ca-35ce-d5c4-71bf-d7c8257297f7@gmail.com> Hi Timotej, I must admit I haven't fully analyzed the problem, but this type of question intuitively sounds like a job for… *drumroll* Type Families! (or his sidekick, functional dependencies) > newtype ST2 r w s a = ST2 { unwrapST2 :: ST s a } > deriving (Functor) > > But as you can see, now all my types got tainted by s even though > sharing the same r or w implies sharing the same s. Is there a way how > to hide s from the type signatures, but still preserve an ability to > write runST2 without resorting to IO/RealWorld? I have tried writing > such a function and failed. As I said, I have almost no idea what I'm doing, but maybe you could get somewhere along the lines of type family StateSupporting reading writing :: * newtype ST2 r w a = ST2 { unwrapST2 :: ST (StateSupporting r w) a } ? Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Sat Apr 8 21:20:49 2017 From: johnw at newartisans.com (John Wiegley) Date: Sat, 08 Apr 2017 14:20:49 -0700 Subject: [Haskell-cafe] Does this function have a name? In-Reply-To: (Paul Brauner's message of "Fri, 07 Apr 2017 08:57:23 +0000") References: Message-ID: >>>>> "PB" == Paul Brauner writes: PB> Oops, there's a free variable in there, let me fix it: PB> first f [] = Nothing PB> first f (x:xs) = fmap (:xs) (f x) <|> fmap (x:) (first f xs) If you break up the test from the modification (instead of fusing the operation into 'f'), this sort of thing becomes quite easy to express using lens: [1..10] & partsOf (traverse.filtered (>2))._head +~ 3 If the list has no elements >2, the operation is a no-op. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From timotej.tomandl at gmail.com Sun Apr 9 12:10:23 2017 From: timotej.tomandl at gmail.com (Timotej Tomandl) Date: Sun, 9 Apr 2017 14:10:23 +0200 Subject: [Haskell-cafe] Eliminating phantom type In-Reply-To: <15a0c7dd-29a4-89a9-aad0-26ed5a9310cf@gmail.com> References: <15a0c7dd-29a4-89a9-aad0-26ed5a9310cf@gmail.com> Message-ID: Hi, yes that seems to fix the issue. Thank you very much. Timotej Tomandl On 8 April 2017 at 13:55, Li-yao Xia wrote: > Hi Timotej, > > It seems you can merge r and s. This solution seems to rely on features > that are very specific to the set of effects you want to model, but I > couldn't pinpoint what these are. > > newtype ST2 r w a = ST2 { unwrapST2 :: ST r a } > > Li-yao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From polux2001 at gmail.com Mon Apr 10 08:07:28 2017 From: polux2001 at gmail.com (Paul Brauner) Date: Mon, 10 Apr 2017 08:07:28 +0000 Subject: [Haskell-cafe] Does this function have a name? In-Reply-To: References: Message-ID: Hi John, this is a nice way of expressing it! I was hoping there would be some more fundamental function that I would have missed though. By fundamental I mean that I was hoping there was some function of a "core" typeclass like Alternative that I had missed that was a general case of my function. Thanks anyway, I learned about lens' partsOf :) Paul On Sat, Apr 8, 2017 at 11:20 PM John Wiegley wrote: > >>>>> "PB" == Paul Brauner writes: > > PB> Oops, there's a free variable in there, let me fix it: > PB> first f [] = Nothing > PB> first f (x:xs) = fmap (:xs) (f x) <|> fmap (x:) (first f xs) > > If you break up the test from the modification (instead of fusing the > operation into 'f'), this sort of thing becomes quite easy to express > using lens: > > [1..10] & partsOf (traverse.filtered (>2))._head +~ 3 > > If the list has no elements >2, the operation is a no-op. > > -- > John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F > http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at jaspervdj.be Mon Apr 10 12:31:38 2017 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Mon, 10 Apr 2017 14:31:38 +0200 Subject: [Haskell-cafe] Call for Presentations: CUFP 2017, September 7-9, Oxford, UK Message-ID: <20170410123138.GA13457@colony6> This CFP and the form for submitting presentations proposals can be found at: http://cufp.org/2017/call-for-presentations.html ------------------------------------------------------------------------ 2017 Call for Presentations Workshop for Commercial Users of Functional Programming 2017 Sponsored by SIGPLAN CUFP 2017 Co-located with ICFP 2017 Oxford, UK September 7-9 Talk Proposal Submission Deadline: 9 June 2017 The annual CUFP event is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. ------------------------------------------------------------------------ Giving a CUFP Talk If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the event. We're looking for two kinds of talks: Retrospective reports are typically 25 minutes long. Now that CUFP has run for more than a decade, we intend to invite past speakers to share what they’ve learned after a decade spent as commercial users of functional programming. We will favour experience reports that include technical content. Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers. We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our ission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy: http://www.sigplan.org/Resources/Policies/Anti-harassment If you are interested in offering a talk, or nominating someone to do so, please submit your presentation before 09 June 2017 via the CUFP 2017 Presentation Submission Form: https://goo.gl/forms/KPloANxHHwdiaoVj2 You do not need to submit a paper, just a short proposal for your talk. There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more of a discussion forum than a technical interchange. Nevertheless, presentations will be recorded and presenters will be expected to sign an ACM copyright release form. Note that we will need presenters to register for the CUFP workshop and travel to Oxford at their own expense. There are some funds available to would-be presenters who require assistance in this respect. ------------------------------------------------------------------------ Program Committee Alex Lang (Tsuru Capital), co-chair Rachel Reese (Mulberry Labs), co-chair Garrett Smith (Guild AI) Danielle Sucher (Jane Street) Jasper Van der Jeugt (Fugue) Yukitoshi Suzuki (Ziosoft) Evelina Gabasova (University of Cambridge) Brian Mitchell (Jet.com) ------------------------------------------------------------------------ More information For more information on CUFP, including videos of presentations from previous years, take a look at the CUFP website at http://cufp.org. Note that presenters, like other attendees, will need to register for the event. Acceptance and rejection letters will be sent out by July 15th. Guidance on giving a great CUFP talk Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits. Setting: FP is pretty well-established in some areas, including formal verification, financial processing, and server-side web services. An unusual setting can be a source of interest. If you're deploying FP-based mobile UIs or building servers on oil rigs, then the challenges of that scenario are worth focusing on. Did FP help or hinder in adapting to the setting? Technology: The CUFP audience is hungry to learn about how FP techniques work in practice. What design patterns have you applied, and to what areas? Did you use functional reactive programming for user interfaces, or DSLs for playing chess, or fault-tolerant actors for large-scale geological data processing? Teach us something about the techniques you used, and why we should consider using them ourselves. Getting things done: How did you deal with large-scale software development in the absence of pre-existing support tools that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community? Don't just be a cheerleader: It's easy to write a rah-rah talk about how well FP worked for you, but CUFP is more interesting when the talks also cover what doesn't work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly. From lanablack at amok.cc Mon Apr 10 12:44:54 2017 From: lanablack at amok.cc (Lana Black) Date: Mon, 10 Apr 2017 12:44:54 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue Message-ID: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Hello, I'm working on a Haskell plugin (a shared library) for a C program. When I load the plugin, I get the following error: > ./open dlopen() failed: /usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so: undefined symbol: stg_thawArrayzh open is just a testing wrapper around dlopen(). I found out that stg_thawArrayzh symbol is exported by the rts, and my library isn't linked to it, and neither is ghc-prim. How do I fix that? Adding -lHSrts-ghc8.0.2 to ld-options doesn't seem to have any effect. Thanks. From mail at nh2.me Mon Apr 10 13:50:34 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Mon, 10 Apr 2017 15:50:34 +0200 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: I'm not sure if it's the solution to your problem already, but there's a Cabal bug that makes it not pass cc-options and ld-options to GHC as ghc-options correctly: https://github.com/haskell/cabal/issues/4435 You need to additionally pass these options as `ghc-options: "-optl -lyourlib"` if you want to be sure. Further, looking at an example I have around, my cabal `library` output (say I have mypackage.cabal with a "library" in there, it's called "dist/build/libHSmypackage-...so") link against things like libHSghc-prim, but not against the RTS (libHSrts...so). I think this makes sense, because as far as I can tell, the RTS is only linked in when you compile the final executable, and which RTS .so file is chosen depends on whether you link in the standard runtime, the -threaded runtime, the debug runtime, etc. So I believe that when loading Haskell from C you will have to dlopen() the RTS you want explicitly, before loading your own .so file. You probably also need to load the RTS with the RTLD_GLOBAL dlopen flag so that when you later load your .so, it can see the RTS symbols. An alternative is probably to add HSrts-ghc-VERSION to `extra-libraries`, like I do here: https://github.com/nh2/call-haskell-from-anything/blob/0ba6737ea17a45e59704dfdc21c971fe10b7d692/detect-ghc-buildinfo.py#L25. That links it explicitly like you planned to do. According to https://github.com/nh2/call-haskell-from-anything/issues/19#issuecomment-263688677 there is now a `foreign-library` stanza in Cabal that is supposed to free you of manually having to link/load the RTS. I haven't tried it yet, since at the time that comment was written, it wasn't released yet. Now it might be. Detail documentation of that feature: https://github.com/haskell/cabal/blob/db26fa21cba92097d9fdeb580ddf797c35af8ed0/Cabal/doc/developing-packages.rst#foreign-libraries Hope this helps! Niklas From lanablack at amok.cc Mon Apr 10 14:16:09 2017 From: lanablack at amok.cc (Lana Black) Date: Mon, 10 Apr 2017 14:16:09 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: On 10/04/17 13:50, Niklas Hambüchen wrote: > I'm not sure if it's the solution to your problem already, but there's a > Cabal bug that makes it not pass cc-options and ld-options to GHC as > ghc-options correctly: > > https://github.com/haskell/cabal/issues/4435 > > You need to additionally pass these options as `ghc-options: "-optl > -lyourlib"` if you want to be sure. > > Further, looking at an example I have around, my cabal `library` output > (say I have mypackage.cabal with a "library" in there, it's called > "dist/build/libHSmypackage-...so") link against things like > libHSghc-prim, but not against the RTS (libHSrts...so). I think this > makes sense, because as far as I can tell, the RTS is only linked in > when you compile the final executable, and which RTS .so file is chosen > depends on whether you link in the standard runtime, the -threaded > runtime, the debug runtime, etc. > > So I believe that when loading Haskell from C you will have to dlopen() > the RTS you want explicitly, before loading your own .so file. You > probably also need to load the RTS with the RTLD_GLOBAL dlopen flag so > that when you later load your .so, it can see the RTS symbols. > > An alternative is probably to add HSrts-ghc-VERSION to > `extra-libraries`, like I do here: > https://github.com/nh2/call-haskell-from-anything/blob/0ba6737ea17a45e59704dfdc21c971fe10b7d692/detect-ghc-buildinfo.py#L25. > That links it explicitly like you planned to do. > > According to > https://github.com/nh2/call-haskell-from-anything/issues/19#issuecomment-263688677 > there is now a `foreign-library` stanza in Cabal that is supposed to > free you of manually having to link/load the RTS. I haven't tried it > yet, since at the time that comment was written, it wasn't released yet. > Now it might be. > > Detail documentation of that feature: > https://github.com/haskell/cabal/blob/db26fa21cba92097d9fdeb580ddf797c35af8ed0/Cabal/doc/developing-packages.rst#foreign-libraries > > Hope this helps! > > Niklas > Unfortunately, adding rts to extra-libraries section doesn't help. Now I get a build error from cabal: Process exited with code: ExitFailure 1 Logs have been written to: /home/void/dev/hs/test/.stack-work/logs/test-0.1.log Configuring test-0.1... Cabal-simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2: Missing dependency on a foreign library: * Missing C library: HSrts-ghc8.0.2 This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. Relevant cabal file options: extra-lib-dirs: /usr/lib/ghc-8.0.2/rts extra-libraries: HSrts-ghc8.0.2 ghc-options: -Wall -Werror -shared -fPIC -dynamic Note that this is a library, not an executable as in call-haskell-from-anything. From makos999 at gmail.com Mon Apr 10 18:09:43 2017 From: makos999 at gmail.com (Akos Marton) Date: Mon, 10 Apr 2017 17:09:43 -0100 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. In-Reply-To: <1491588519.2165.1.camel@gmail.com> References: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> <1491588519.2165.1.camel@gmail.com> Message-ID: On 04/07/2017 05:08 PM, Arjen wrote: >> That would be fine, however the key does exists. When same code, same >> system, but the .exe built to be x64 it runs like a charm. > 32bit and 64bit Windows executables read different keys using the same > registry path. The 64bit executable can read keys from the 32bit part > of the registry, but is has to use the WOW6432Node path. > Maybe this will help:https://support.microsoft.com/en-us/help/305097/h > ow-to-view-the-system-registry-by-using-64-bit-versions-of-windows > That's okay: for other reasons also related to registry reading I need to deal with it. The interesting thing is really, the registry-key which I wish to read exists on the system and the key is the same on x86 and x64. The key must be related to /getSystemInfo :: IO SYSTEM_INFO. / -------------- next part -------------- An HTML attachment was scrubbed... URL: From makos999 at gmail.com Mon Apr 10 18:17:44 2017 From: makos999 at gmail.com (Akos Marton) Date: Mon, 10 Apr 2017 17:17:44 -0100 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. In-Reply-To: References: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> Message-ID: <1748a685-e227-4bf4-ce37-fc5199846cc8@gmail.com> On 04/07/2017 05:09 PM, Brandon Allbery wrote: > On Fri, Apr 7, 2017 at 3:51 PM, Akos Marton wrote: > >> *me.exe: RegOpenKey: invalid argument (The system cannot find the file >> specified.)* >> >> That would be fine, however the key does exists. When same code, same >> system, but the .exe built to be x64 it runs like a charm. >> > My guess is that the FFI call has an incorrect type somewhere and therefore > passes garbage. My fear is that, even if digging into the code of win32 package, underlying details seems to be hidden how certain values are read out. - at least for me. Can it be that ghc forces its evaluation during compilation and renders something hard-coded into the binary? - this is how it feels, I am trying to show it, so far w/o success. > > Another thing which convoluted in the issue... >> The function, *getSystemInfo :: IO SYSTEM_INFO, *can read out the >> underlying architecture. When compiled on x86 and run on x64 it would tell >> me: "I am running on x86". That's failure. >> > You can blame Windows for that one: if you run an x86 binary on x86_64, it > launches the WoW subsystem emulating an x86 processor, so you will get the > emulated processor reported back. There may be a different API to get the > actual host --- but given that WoW exists to minimize incompatibilities for > x86 software, it is likely well hidden if it exists at all. I do not know that, but it feels like I should use something which can be called via /system/ and hence on can rely on the local window api and not on the system I compile. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 10 16:34:03 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 10 Apr 2017 12:34:03 -0400 Subject: [Haskell-cafe] Same code, system, but different arch using Win32 for reading registry. In-Reply-To: <1748a685-e227-4bf4-ce37-fc5199846cc8@gmail.com> References: <4cc23963-f3b5-881a-c6b6-60ce6b1fb919@gmail.com> <1748a685-e227-4bf4-ce37-fc5199846cc8@gmail.com> Message-ID: On Mon, Apr 10, 2017 at 2:17 PM, Akos Marton wrote: > Can it be that ghc forces its evaluation during compilation and renders > something hard-coded into the binary? - this is how it feels, I am trying > to show it, so far w/o success. No. The System.Info module works that way (more precisely it reports things baked into the binary at compile time), but the Win32 module is making an actual system call. That system call is being processed by WoW32 and returning information about the emulator, not the host. If it's not clear yet: WoW32 is a restricted virtual machine. Expect it to behave as if the program is running in a 32-bit Windows inside VirtualBox. You get this any time you run a 32-bit executable on 64-bit Windows. It does not matter what language you use. It does not matter how you access this information. I do not know that, but it feels like I should use something which can be > called via *system* and hence on can rely on the local window api and not > on the system I compile. > That will likely still run within WoW32 though, and report the emulated 32-bit CPU. Windows is specifically avoiding the thing you want, in order to provide backward compatibility. At this point you probably need to spend some time with MSDN to see if there is a way for something running in WoW32 to find out details of the host, probably by communicating with the hypervisor. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Mon Apr 10 18:41:10 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 11 Apr 2017 00:11:10 +0530 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: You can try using ghc directly (instead of cabal) so that you have full control over what flags are passed, like this: ghc -fPIC -dynamic -package xx -c plugin.hs ld -shared -Bsymbolic -L -lHSrts-ghc8.0.2 -o plugin.so plugin.o If this works then you can find what is wrong/different with your cabal setup by using verbose flags and looking at what is being passed to ghc. -harendra On 10 April 2017 at 18:14, Lana Black wrote: > Hello, > > I'm working on a Haskell plugin (a shared library) for a C program. When > I load the plugin, I get the following error: > > > ./open > dlopen() failed: > /usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so: > undefined symbol: stg_thawArrayzh > > open is just a testing wrapper around dlopen(). I found out that > stg_thawArrayzh symbol is exported by the rts, and my library isn't > linked to it, and neither is ghc-prim. How do I fix that? Adding > -lHSrts-ghc8.0.2 to ld-options doesn't seem to have any effect. > > Thanks. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lanablack at amok.cc Mon Apr 10 20:58:26 2017 From: lanablack at amok.cc (Lana Black) Date: Mon, 10 Apr 2017 20:58:26 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: On 10/04/17 18:41, Harendra Kumar wrote: > You can try using ghc directly (instead of cabal) so that you have full > control over what flags are passed, like this: > > ghc -fPIC -dynamic -package xx -c plugin.hs > ld -shared -Bsymbolic -L -lHSrts-ghc8.0.2 -o plugin.so > plugin.o > > If this works then you can find what is wrong/different with your cabal > setup by using verbose flags and looking at what is being passed to ghc. > > -harendra Thank you for the idea. That way everything works. I created a repo with a small demo of this issue [1]. For some reason, when options -fPIC -dynamic -shared are present, cabal creates an executable a.out and links in with RTS instead. The shared library on the other hand isn't linked with RTS in any case unless ghc is called directly. ~/devel/hs/cabal-bug> cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring cabal-bug-0.1... Building cabal-bug-0.1... Preprocessing library cabal-bug-0.1... [1 of 1] Compiling Cabal.Bug ( src/Cabal/Bug.hs, dist/build/Cabal/Bug.o ) Linking a.out ... ~/devel/hs/cabal-bug> ldd a.out linux-vdso.so.1 (0x00007ffc403e6000) libHSrts-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/rts/libHSrts-ghc8.0.2.so (0x00007f62fb591000) libHSbase-4.9.1.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so (0x00007f62fa987000) libHSinteger-gmp-1.0.0.1-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so (0x00007f62fa751000) libHSghc-prim-0.5.0.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so (0x00007f62fa366000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f62fa0c8000) libm.so.6 => /lib64/libm.so.6 (0x00007f62f9dc5000) libc.so.6 => /lib64/libc.so.6 (0x00007f62f9a2c000) librt.so.1 => /lib64/librt.so.1 (0x00007f62f9823000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f62f961f000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f62f9416000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f62f91f9000) /lib64/ld-linux-x86-64.so.2 (0x000055768de76000) ~/devel/hs/cabal-bug> ldd dist/build/libHScabal-bug-0.1-50NTk4EdDNe8utEsR21Nft-ghc8.0.2.so linux-vdso.so.1 (0x00007fff249d9000) libHSbase-4.9.1.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so (0x00007f6c90bb4000) libHSinteger-gmp-1.0.0.1-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so (0x00007f6c9097d000) libHSghc-prim-0.5.0.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so (0x00007f6c90592000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f6c902f5000) libm.so.6 => /lib64/libm.so.6 (0x00007f6c8fff1000) libc.so.6 => /lib64/libc.so.6 (0x00007f6c8fc58000) /lib64/ld-linux-x86-64.so.2 (0x000055f911c1d000) Is this a bug in cabal? [1]: https://github.com/greydot/cabal-bug From mail at nh2.me Mon Apr 10 22:03:49 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Tue, 11 Apr 2017 00:03:49 +0200 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: <9d41faff-eda4-1464-31fd-d25b22272c91@nh2.me> I don't know if it's a cabal bug, but when I try to make foreign libraries, I always put them into an `executable` section and use `-no-hs-main -fPIC -shared -dynamic`: https://github.com/nh2/call-haskell-from-anything/blob/d750f9881b4023ead32172967c0b1c88f36038f8/call-haskell-from-anything.cabal#L66 From jeffbrown.the at gmail.com Mon Apr 10 22:40:28 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 10 Apr 2017 15:40:28 -0700 Subject: [Haskell-cafe] Semantic Synchrony: some open-source knowledge graph software Message-ID: Esteemed Haskellers, Semantic Synchrony is an open-source knowledge graph server with an Emacs front end. It integrates with Chrome and Git. Git allows a graph to be selectively shared, as a collection of repositories. Subgraphs can be created and edited using indented plain text or Markdown; the latter allows nodes to serve double-duty as edge labels, by linking to them in section or subsection headings. The front end and server communicate using simple JSON. We are open to taking it in new directions. For hacking it, check out our invitation to coders[1]. For learning more about it, check out the wiki[2], which is thorough and friendly -- it even including videos. [1] github.com/synchrony/smsn-why/blob/master/invitations/to-coders.md [2] github.com/synchrony/smsn/wiki -- 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 trebla at vex.net Mon Apr 10 22:46:45 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 10 Apr 2017 18:46:45 -0400 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: On 2017-04-10 04:58 PM, Lana Black wrote: > ~/devel/hs/cabal-bug> cabal build > Package has never been configured. Configuring with default flags. If this > fails, please run configure manually. > Resolving dependencies... > Configuring cabal-bug-0.1... I am surprised that at this point you did not receive the warning I received: Warning: Instead of 'ghc-options: -lHSrts-ghc8.0.2' use 'extra-libraries: HSrts-ghc8.0.2' In my http://www.vex.net/~trebla/haskell/so.xhtml I use the extra-libraries route (and build-type: Configure to automate "8.0.2"). Also I do not use ghc-options, see below. > Building cabal-bug-0.1... > Preprocessing library cabal-bug-0.1... > [1 of 1] Compiling Cabal.Bug ( src/Cabal/Bug.hs, > dist/build/Cabal/Bug.o ) > Linking a.out ... This a.out is not an executable. It is a shared library. The name "a.out" is a historical generic bland default name for any linker output whenever the user fails to specify "-o realname". Linker output could be executable or library depending on other flags. Now to see why this a.out exists at all, you really should use "cabal build -v" to see how cabal uses GHC. But the short story is: cabal calls GHC at least 3 times: 1st time is to compile *.hs files to *.o files, e.g., Bug.hs to Bug.o. (If you have multiple *.hs files, it is still one call, and you also see a -j2 or -j4 or -j65536 according to your number of CPU cores to tell GHC to parallelize.) 2nd time is to produce the *.a library. 3rd time is to produce the *.so library. Now, if you hardcode the blunt sledgehammer that is ghc-options: -fPIC -dynamic -shared, as opposed to letting cabal do it at the right times (namely, -shared during the 3rd time only), then the extraneous -shared during the 1st time, which is supposed to be *.o only, tricks GHC into calling the linker to produce an extraneous *.so (except there is no -o so the name comes out as a.out). But do not think that you can declare victory now and take this a.out and get away with it. For all practical purposes you will need to include some C code in the library. See again my article for why. But the short story is: Who's gonna call hs_init? The 1st call to GHC does not mention the C code whatsoever. The a.out thus produced will be missing the C code. It is incomplete. There are extra calls after the 1st and before the 2nd to compile *.c to *.o. Only by the 3rd call are all *.o files, from both Haskell and C, brought together into a complete *.so. (Well, the 2nd call too, but you are not going after the *.a.) From brucker at spamfence.net Mon Apr 10 23:00:13 2017 From: brucker at spamfence.net (Achim D. Brucker) Date: Tue, 11 Apr 2017 00:00:13 +0100 Subject: [Haskell-cafe] 2nd CFP - Only Two Weeks Left: International Workshop on OCL and Textual Modeling (OCL 2017) Message-ID: <20170410230013.qvbjhyy4v6ionu2j@fujikawa.home.brucker.ch> (Apologies for duplicates) -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From whosekiteneverfly at gmail.com Mon Apr 10 23:24:55 2017 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Tue, 11 Apr 2017 08:24:55 +0900 Subject: [Haskell-cafe] How does GHC avoid ": hPutChar: invalid argument (invalid character)"? Message-ID: Hello Haskellers, Currently, I’m working on this issue , where haddock crashes when printing the Unicode “bullet character” on stderr whose character encoding is not UTF-8. In the beforementioned pull request, I just added hSetEncoding stderr utf8 as a quick-and-dirty workaround. But GHC actually doesn’t do so: GHC prints “?” instead of the bullet character when stderr is not Unicode-compatible. So, I believe there’s a better way to handle the case, and GHC knows it. Then, how does GHC detect the handle’s character encoding and convert incompatible characters (such as the bullet character) into “?” to avoid the error? I couldn’t get it by reading the source of GHC a bit. Thanks in advance! ​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Apr 10 23:32:19 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 10 Apr 2017 19:32:19 -0400 Subject: [Haskell-cafe] How does GHC avoid ": hPutChar: invalid argument (invalid character)"? In-Reply-To: References: Message-ID: On Mon, Apr 10, 2017 at 7:24 PM, Yuji Yamamoto wrote: > Currently, I’m working on this issue > , > > where haddock crashes when printing the Unicode “bullet character” > on stderr > whose character encoding is not UTF-8. > > In the beforementioned pull request, I just added hSetEncoding stderr utf8 > as a quick-and-dirty workaround. > But GHC actually doesn’t do so: GHC prints “?” instead of the bullet > character when stderr is not Unicode-compatible. > > https://downloads.haskell.org/~ghc/8.0.2/docs/html/libraries/base-4.9.1.0/GHC-IO-Encoding.html#v:mkTextEncoding note the suffixes you can add to an encoding name. -- 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 jeffbrown.the at gmail.com Tue Apr 11 06:34:19 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Mon, 10 Apr 2017 23:34:19 -0700 Subject: [Haskell-cafe] Semantic Synchrony: some open-source knowledge graph software In-Reply-To: References: Message-ID: I should have mentioned that the front end is simple, resembling an ordinary text editor. There are only 25 commands a user has to learn; no programming is needed. On Mon, Apr 10, 2017 at 3:40 PM, Jeffrey Brown wrote: > Esteemed Haskellers, > > Semantic Synchrony is an open-source knowledge graph server with an Emacs > front end. It integrates with Chrome and Git. Git allows a graph to be > selectively shared, as a collection of repositories. Subgraphs can be > created and edited using indented plain text or Markdown; the latter allows > nodes to serve double-duty as edge labels, by linking to them in section or > subsection headings. The front end and server communicate using simple JSON. > > We are open to taking it in new directions. > > For hacking it, check out our invitation to coders[1]. For learning more > about it, check out the wiki[2], which is thorough and friendly -- it even > including videos. > > [1] github.com/synchrony/smsn-why/blob/master/invitations/to-coders.md > [2] github.com/synchrony/smsn/wiki > > > -- > Jeff Brown | Jeffrey Benjamin Brown > Website | Facebook > | LinkedIn > (spammy, so I often > miss messages here) | Github > > -- 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 lanablack at amok.cc Tue Apr 11 07:20:38 2017 From: lanablack at amok.cc (Lana Black) Date: Tue, 11 Apr 2017 07:20:38 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> Message-ID: <1ea4db55-64a4-fa4d-d09d-9f915eb64773@amok.cc> On 10/04/17 22:46, Albert Y. C. Lai wrote: > I am surprised that at this point you did not receive the warning I > received: > > Warning: Instead of 'ghc-options: -lHSrts-ghc8.0.2' use > 'extra-libraries: HSrts-ghc8.0.2' > > In my http://www.vex.net/~trebla/haskell/so.xhtml I use the > extra-libraries route (and build-type: Configure to automate "8.0.2"). > Also I do not use ghc-options, see below. Thank you for this suggestion. Now things start to get rather strange. I have changed the cabal file accordingly [1]. When I run cabal configure, I get the following error: > cabal configure Resolving dependencies... Configuring cabal-bug-0.1... cabal: Missing dependency on a foreign library: * Missing C library: HSrts-ghc8.0.2 This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. However, that doesn't prevent cabal build from succeeding, and now I have a shared library linked to RTS. > cabal build Building cabal-bug-0.1... Preprocessing library cabal-bug-0.1... [1 of 1] Compiling Cabal.Bug ( src/Cabal/Bug.hs, dist/build/Cabal/Bug.o ) > ldd dist/build/libHScabal-bug-0.1-50NTk4EdDNe8utEsR21Nft-ghc8.0.2.so linux-vdso.so.1 (0x00007ffea75c9000) libHSrts-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/rts/libHSrts-ghc8.0.2.so (0x00007f8057193000) libHSbase-4.9.1.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/base-4.9.1.0/libHSbase-4.9.1.0-ghc8.0.2.so (0x00007f8056589000) libHSinteger-gmp-1.0.0.1-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/integer-gmp-1.0.0.1/libHSinteger-gmp-1.0.0.1-ghc8.0.2.so (0x00007f8056353000) libHSghc-prim-0.5.0.0-ghc8.0.2.so => /usr/lib64/ghc-8.0.2/ghc-prim-0.5.0.0/libHSghc-prim-0.5.0.0-ghc8.0.2.so (0x00007f8055f68000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f8055cca000) libm.so.6 => /lib64/libm.so.6 (0x00007f80559c7000) libc.so.6 => /lib64/libc.so.6 (0x00007f805562e000) librt.so.1 => /lib64/librt.so.1 (0x00007f8055425000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f8055221000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007f8055018000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f8054dfb000) /lib64/ld-linux-x86-64.so.2 (0x000056212e051000) However, if I run cabal build without calling cabal configure first, the latter fails and the build process is stopped at that point. This also prevents me from building my project with stack. >> Building cabal-bug-0.1... >> Preprocessing library cabal-bug-0.1... >> [1 of 1] Compiling Cabal.Bug ( src/Cabal/Bug.hs, >> dist/build/Cabal/Bug.o ) >> Linking a.out ... > > This a.out is not an executable. It is a shared library. The name > "a.out" is a historical generic bland default name for any linker output > whenever the user fails to specify "-o realname". Linker output could be > executable or library depending on other flags. > > Now to see why this a.out exists at all, you really should use "cabal > build -v" to see how cabal uses GHC. But the short story is: > > cabal calls GHC at least 3 times: > > 1st time is to compile *.hs files to *.o files, e.g., Bug.hs to Bug.o. > (If you have multiple *.hs files, it is still one call, and you also see > a -j2 or -j4 or -j65536 according to your number of CPU cores to tell > GHC to parallelize.) > > 2nd time is to produce the *.a library. > > 3rd time is to produce the *.so library. > > Now, if you hardcode the blunt sledgehammer that is ghc-options: -fPIC > -dynamic -shared, as opposed to letting cabal do it at the right times > (namely, -shared during the 3rd time only), then the extraneous -shared > during the 1st time, which is supposed to be *.o only, tricks GHC into > calling the linker to produce an extraneous *.so (except there is no -o > so the name comes out as a.out). Thanks for this explanation. > But do not think that you can declare victory now and take this a.out > and get away with it. > > For all practical purposes you will need to include some C code in the > library. See again my article for why. But the short story is: Who's > gonna call hs_init? Yes, I'm aware of this. The real code in question has calls to hs_init() and hs_exit(). All I'm trying to do now is to solve the linking problem. [1]: https://github.com/greydot/cabal-bug/blob/extra-lib/cabal-bug.cabal From merijn at inconsistent.nl Tue Apr 11 07:46:58 2017 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Tue, 11 Apr 2017 09:46:58 +0200 Subject: [Haskell-cafe] How does GHC avoid ": hPutChar: invalid argument (invalid character)"? In-Reply-To: References: Message-ID: <7FDEC133-00A8-416E-81A3-73A5383F22E4@inconsistent.nl> This sounds to me like a classical case of a wrongly (or not) configured locale/terminal. As a starting point I would check both what the locale variables are set to (run "locale" in the shell) and check what encoding the terminal is set to. I've noticed a lot of linux installs have completely borked configuration with regards to these and in those cases GHC can't do much. Side note: Just forcing output to be utf8 is *definitely* the wrong thing to do, as it'd break any environment set to a different encoding... Cheers, Merijn > On 11 Apr 2017, at 1:24, Yuji Yamamoto wrote: > > Hello Haskellers, > > Currently, I’m working on this issue, > where haddock crashes when printing the Unicode “bullet character” on stderr whose character encoding is not UTF-8. > > In the beforementioned pull request, I just added hSetEncoding stderr utf8 as a quick-and-dirty workaround. > But GHC actually doesn’t do so: GHC prints “?” instead of the bullet character when stderr is not Unicode-compatible. > > So, I believe there’s a better way to handle the case, and GHC knows it. > Then, how does GHC detect the handle’s character encoding and convert incompatible characters (such as the bullet character) into “?” to avoid the error? > I couldn’t get it by reading the source of GHC a bit. > > Thanks in advance! > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Graham.Hutton at nottingham.ac.uk Tue Apr 11 12:22:04 2017 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 11 Apr 2017 12:22:04 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, deadline 30th April 2017. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 30th April 2017 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 30th April 2017. o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 1000 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting in the abstract, but do get in touch if this causes significant problems) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From whosekiteneverfly at gmail.com Tue Apr 11 13:22:13 2017 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Tue, 11 Apr 2017 22:22:13 +0900 Subject: [Haskell-cafe] How does GHC avoid ": hPutChar: invalid argument (invalid character)"? In-Reply-To: <7FDEC133-00A8-416E-81A3-73A5383F22E4@inconsistent.nl> References: <7FDEC133-00A8-416E-81A3-73A5383F22E4@inconsistent.nl> Message-ID: Brandon and Merijn, Thank you for advice. But I should have noted that the issue is about Windows... So things to take care might be different... 2017-04-11 16:46 GMT+09:00 Merijn Verstraaten : > This sounds to me like a classical case of a wrongly (or not) configured > locale/terminal. As a starting point I would check both what the locale > variables are set to (run "locale" in the shell) and check what encoding > the terminal is set to. I've noticed a lot of linux installs have > completely borked configuration with regards to these and in those cases > GHC can't do much. > > Side note: Just forcing output to be utf8 is *definitely* the wrong thing > to do, as it'd break any environment set to a different encoding... > > Cheers, > Merijn > > > On 11 Apr 2017, at 1:24, Yuji Yamamoto > wrote: > > > > Hello Haskellers, > > > > Currently, I’m working on this issue, > > where haddock crashes when printing the Unicode “bullet character” on > stderr whose character encoding is not UTF-8. > > > > In the beforementioned pull request, I just added hSetEncoding stderr > utf8 as a quick-and-dirty workaround. > > But GHC actually doesn’t do so: GHC prints “?” instead of the bullet > character when stderr is not Unicode-compatible. > > > > So, I believe there’s a better way to handle the case, and GHC knows it. > > Then, how does GHC detect the handle’s character encoding and convert > incompatible characters (such as the bullet character) into “?” to avoid > the error? > > I couldn’t get it by reading the source of GHC a bit. > > > > Thanks in advance! > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Tue Apr 11 14:06:54 2017 From: mantkiew at gsd.uwaterloo.ca (=?UTF-8?Q?Micha=C5=82_Antkiewicz?=) Date: Tue, 11 Apr 2017 10:06:54 -0400 Subject: [Haskell-cafe] Semantic Synchrony: some open-source knowledge graph software In-Reply-To: References: Message-ID: What is "knowledge graph server"? Is it like a semantic wiki? What's the main use case? Is it like "git for structured information"? Or is it like "distributed mindmap"? Michał On Tue, Apr 11, 2017 at 2:34 AM, Jeffrey Brown wrote: > I should have mentioned that the front end is simple, resembling an > ordinary text editor. There are only 25 commands > a > user has to learn; no programming is needed. > > On Mon, Apr 10, 2017 at 3:40 PM, Jeffrey Brown > wrote: > >> Esteemed Haskellers, >> >> Semantic Synchrony is an open-source knowledge graph server with an Emacs >> front end. It integrates with Chrome and Git. Git allows a graph to be >> selectively shared, as a collection of repositories. Subgraphs can be >> created and edited using indented plain text or Markdown; the latter allows >> nodes to serve double-duty as edge labels, by linking to them in section or >> subsection headings. The front end and server communicate using simple JSON. >> >> We are open to taking it in new directions. >> >> For hacking it, check out our invitation to coders[1]. For learning more >> about it, check out the wiki[2], which is thorough and friendly -- it even >> including videos. >> >> [1] github.com/synchrony/smsn-why/blob/master/invitations/to-coders.md >> [2] github.com/synchrony/smsn/wiki >> >> >> -- >> Jeff Brown | Jeffrey Benjamin Brown >> Website | Facebook >> | LinkedIn >> (spammy, so I often >> miss messages here) | Github >> >> > > > > -- > Jeff Brown | Jeffrey Benjamin Brown > Website | Facebook > | LinkedIn > (spammy, so I often > miss messages here) | Github > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 krapsh at yandex.com Tue Apr 11 16:24:07 2017 From: krapsh at yandex.com (Karps) Date: Tue, 11 Apr 2017 09:24:07 -0700 Subject: [Haskell-cafe] [ANN] Karps-0.2.0 Haskell frontend and optimizer for Apache Spark's dataframes and datasets Message-ID: <2794051491927847@web48j.yandex.ru> An HTML attachment was scrubbed... URL: From boccato at gmail.com Wed Apr 12 01:36:33 2017 From: boccato at gmail.com (Ricardo Boccato Alves) Date: Tue, 11 Apr 2017 22:36:33 -0300 Subject: [Haskell-cafe] Help with hspec-wai Message-ID: Hello, I have been struggling with hspec-wai with what seems to me to be a simple problem: I want to create an Application using a parameter and access that parameter inside the test. The closer I found was this article: https://begriffs.com/posts/2014-10-19-warp-server-controller-test.html The part I am struggling is to access the connection inside the test, this gist is the closer I got. https://gist.github.com/boccato/e151d3a4e4f5d925b904126f80d8cb65 I know I am doing something very stupid and / or didn't understand something very basic, but I just can't see it by myself. Tks, Ricardo Boccato Alves. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guthrie at mum.edu Wed Apr 12 03:25:57 2017 From: guthrie at mum.edu (Gregory Guthrie) Date: Tue, 11 Apr 2017 22:25:57 -0500 Subject: [Haskell-cafe] install problems Message-ID: <08EF9DA445C4B5439C4733E1F35705BA065BF53870EE@MAIL.cs.mum.edu> I tried to install HSBC and HSQL-sqlite3, Bot fail, And the error report is: >cabal install HDBC Resolving dependencies... Configuring old-locale-1.0.0.7... Configuring utf8-string-1.0.1.1... Building old-locale-1.0.0.7... Building utf8-string-1.0.1.1... Installed old-locale-1.0.0.7 Configuring old-time-1.1.0.3... Installed utf8-string-1.0.1.1 Failed to install old-time-1.1.0.3 Build log ( C:\Users\guthrie\AppData\Roaming\cabal\logs\old-time-1.1.0.3.log ): Configuring old-time-1.1.0.3... configure: WARNING: unrecognized options: --with-compiler checking for gcc... e:\Plang\Haskell Platform\8.0.2\mingw\bin\gcc.exe checking whether the C compiler works... no configure: error: in `/tmp/cabal-tmp-21488/old-time-1.1.0.3': configure: error: C compiler cannot create executables See `config.log' for more details But the path to gcc is correct, and gc works fine. I had a similar problem once, and the issue was that the autoconf script didn't allow paths with spaces, Odd since Haskell installs into "Haskell Package" on windows. That time I had to reconfigure my whole installation (eliminating the space character), and then install it, and then restore the paths to what they were. Is this an ongoing issue? Should I reconfigure Haskell to install differently? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Apr 12 03:33:50 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 11 Apr 2017 23:33:50 -0400 Subject: [Haskell-cafe] install problems In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA065BF53870EE@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA065BF53870EE@MAIL.cs.mum.edu> Message-ID: On Tue, Apr 11, 2017 at 11:25 PM, Gregory Guthrie wrote: > I had a similar problem once, and the issue was that the autoconf script > didn’t allow paths with spaces, > > Odd since Haskell installs into “Haskell Package” on windows. > Many package developers only work on Unix/Linux and don't test on Windows. Haskell is not a monolith controlled by a single entity that guarantees that everything always works everywhere. You are probably better off overriding the installation to use a path not containing spaces, or sticking to packages known to work on Windows (you may need to find this out by asking around). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.sorokin at gmail.com Wed Apr 12 03:49:40 2017 From: david.sorokin at gmail.com (David Sorokin) Date: Wed, 12 Apr 2017 06:49:40 +0300 Subject: [Haskell-cafe] install problems In-Reply-To: <08EF9DA445C4B5439C4733E1F35705BA065BF53870EE@MAIL.cs.mum.edu> References: <08EF9DA445C4B5439C4733E1F35705BA065BF53870EE@MAIL.cs.mum.edu> Message-ID: <468FE1F1-F81A-4D55-8925-5211376F1D9A@gmail.com> Hi Gregory, I had a similar issue when tried to install on Windows some packages that depend on the old-time package. I don’t remember all the details, but I installed MSYS and some its modules additionally. Then my issue had gone. There are also MSYS2 and Cygwin that can be used instead of MSYS. I would try to experiment with MSYS2. Earlier the old-time package was included in the Haskell platform and all my installations went smooth on Windows. But recently, the old-time package was removed from the Haskell platform and it caused some issues on clean Windows, for some packages still depend on that package explicitly or implicitly. Thanks, David > 12 апр. 2017 г., в 6:25, Gregory Guthrie написал(а): > > I tried to install HSBC and HSQL-sqlite3, > Bot fail, > And the error report is: > > >cabal install HDBC > Resolving dependencies... > Configuring old-locale-1.0.0.7... > Configuring utf8-string-1.0.1.1... > Building old-locale-1.0.0.7... > Building utf8-string-1.0.1.1... > Installed old-locale-1.0.0.7 > Configuring old-time-1.1.0.3... > Installed utf8-string-1.0.1.1 > Failed to install old-time-1.1.0.3 > Build log ( C:\Users\guthrie\AppData\Roaming\cabal\logs\old-time-1.1.0.3.log ): > Configuring old-time-1.1.0.3... > configure: WARNING: unrecognized options: --with-compiler > checking for gcc... e:\Plang\Haskell Platform\8.0.2\mingw\bin\gcc.exe > checking whether the C compiler works... no > configure: error: in `/tmp/cabal-tmp-21488/old-time-1.1.0.3': > configure: error: C compiler cannot create executables > See `config.log' for more details > > But the path to gcc is correct, and gc works fine. > > I had a similar problem once, and the issue was that the autoconf script didn’t allow paths with spaces, > Odd since Haskell installs into “Haskell Package” on windows. > > That time I had to reconfigure my whole installation (eliminating the space character), and then install it, and then restore the paths to what they were. > > Is this an ongoing issue? Should I reconfigure Haskell to install differently? > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jeffbrown.the at gmail.com Wed Apr 12 04:21:54 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Tue, 11 Apr 2017 21:21:54 -0700 Subject: [Haskell-cafe] Semantic Synchrony: some open-source knowledge graph software In-Reply-To: References: Message-ID: One of those pages had broken links; they are now fixed. My apologies. On Mon, Apr 10, 2017 at 3:40 PM, Jeffrey Brown wrote: > Esteemed Haskellers, > > Semantic Synchrony is an open-source knowledge graph server with an Emacs > front end. It integrates with Chrome and Git. Git allows a graph to be > selectively shared, as a collection of repositories. Subgraphs can be > created and edited using indented plain text or Markdown; the latter allows > nodes to serve double-duty as edge labels, by linking to them in section or > subsection headings. The front end and server communicate using simple JSON. > > We are open to taking it in new directions. > > For hacking it, check out our invitation to coders[1]. For learning more > about it, check out the wiki[2], which is thorough and friendly -- it even > including videos. > > [1] github.com/synchrony/smsn-why/blob/master/invitations/to-coders.md > [2] github.com/synchrony/smsn/wiki > > > -- > Jeff Brown | Jeffrey Benjamin Brown > Website | Facebook > | LinkedIn > (spammy, so I often > miss messages here) | Github > > -- 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 mail at stefanwehr.de Wed Apr 12 07:36:42 2017 From: mail at stefanwehr.de (Stefan Wehr) Date: Wed, 12 Apr 2017 09:36:42 +0200 Subject: [Haskell-cafe] ANN: HacFreiburg 2017, Friday 4 August - Sunday 6 August, Freiburg, Germany Message-ID: Dear Haskellers, there is another Haskell Hackathon, taking place in Freiburg, Germany this year! When: Friday 4 August 2017 - Sunday 6 August 2017 Where: Faculty of Engineering, University of Freiburg, Germany (https://goo.gl/maps/ZcHWLpMPhtj) Info page: https://wiki.haskell.org/HacFreiburg2017 Organizers: Peter Thiemann, Alexander Thiemann, Stefan Wehr HacFreiburg is another Haskell Hackathon, where Haskell programmers from all around the world meet in Freiburg, Germany, to discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! The Haskell Hackathon in Freiburg is part of the "Sommercampus 2017" (https://sommercampus.fachschaft.tf/en/), organized by the Faculty of Engineering at the University of Freiburg. Hope to see you there, Stefan (with Peter and Alex) From saurabhnanda at gmail.com Wed Apr 12 14:59:51 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Wed, 12 Apr 2017 20:29:51 +0530 Subject: [Haskell-cafe] RFC: Handling marginally bad data via logging "soft-errors" Message-ID: Cross-posted from https://www.reddit.com/r/haskell/comments/64ymup/rfc_handling_marginally_bad_data_via_logging/ Hi Everyone, I would like to hear some perspectives from people who have more experience in handling production code in Haskell. SCENARIO: You're loading data from a DB (or any other external source) and are expecting certain fields to be present. You end-up loading a record/row which has all the strictly necessary fields, but a not-so-necessary field is missing. Example: loading a full name, stored as the following HSTORE in PG: {'title' => '...', 'first_name' => '...', 'last_name' => '...'} For whatever legacy reasons, there is a possibility that some records may not have the title field, or may not have the last_name field. Now, the skies are not going to fall if you display the name with some components missing, so, you don't want to throw an error and terminate the entire operation. It's a "soft error" which you want to log, and proceed with a default value. OPTION 1: Use unsafePerformIO to avoid making an otherwise pure function, "impure", i.e. parseName :: HStore -> FullName -- uses unsafePerformIO to log soft-errors OPTION 2: Put the data transformation function in IO or the app-wide monad AppM because it will call the logging function, i.e. parseName :: HStore -> AppM FullName OPTION 3: Use a wrapper over Writer monad, called ErrorCollector, that forces the calling function to log while accessing the underlying value, i.e. parseName :: HStore -> ErrorCollector FullName logErrorAndExtract extraLoggingContext (parseName hstoreVal) THOUGHTS: -- The downside of Option 1 is that (a) it's unsafe, and (b) the log won't have surrounding context, for example it won't have the primary key of the row that was being loaded within which this error occurred. -- The downside of Option 2 is that it introduces AppM into the function signature, and even that log won't have enough surrounding context to help in debugging. -- The downside of Option 3 is that it pushes some logging responsibility to the calling functions, but gives the ability to put extra context when a soft-error occurs. How do others deal with this problem? -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at patrickmn.com Wed Apr 12 15:35:34 2017 From: haskell at patrickmn.com (Patrick Mylund Nielsen) Date: Wed, 12 Apr 2017 11:35:34 -0400 Subject: [Haskell-cafe] RFC: Handling marginally bad data via logging "soft-errors" In-Reply-To: References: Message-ID: <98620abf-42ce-0a2e-b296-58c33490e885@patrickmn.com> On 4/12/2017 10:59 AM, Saurabh Nanda wrote: > OPTION 1: Use unsafePerformIO to avoid making an otherwise pure > function, "impure", i.e. > > parseName :: HStore -> FullName -- uses unsafePerformIO to log > soft-errors > > OPTION 2: Put the data transformation function in IO or the app-wide > monad AppM because it will call the logging function, i.e. > > parseName :: HStore -> AppM FullName > > > OPTION 3: Use a wrapper over Writer monad, called ErrorCollector, that > forces the calling function to log while accessing the underlying value, > i.e. > > parseName :: HStore -> ErrorCollector FullName > logErrorAndExtract extraLoggingContext (parseName hstoreVal) May I suggest a fourth option: Keep the utility functions such as parsing pure, and do the logging in the IO threads that are calling them. This is a nice way to keep from polluting general-purpose functions with I/O, whether unsafe or not. If the calling thread doesn't have enough information to produce a meaningful log message, the pure function could return it as part of a Left. From amindfv at gmail.com Wed Apr 12 18:09:29 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 12 Apr 2017 13:09:29 -0500 Subject: [Haskell-cafe] RFC: Handling marginally bad data via logging "soft-errors" In-Reply-To: References: Message-ID: <0CEB8092-B06D-40C4-A35E-9F84D4FE7816@gmail.com> Why not eg: parseName :: HStore -> (Maybe String, FullName) Where all the errors are collected after parsing with: mapMaybe fst :: [(Maybe String, FullName)] -> [String] And the values are just collected with "map snd" Tom > El 12 abr 2017, a las 09:59, Saurabh Nanda escribió: > > parseName :: HStore -> FullName From litchard.michael at gmail.com Wed Apr 12 17:45:53 2017 From: litchard.michael at gmail.com (Michael Litchard) Date: Wed, 12 Apr 2017 10:45:53 -0700 Subject: [Haskell-cafe] Dynamic Programming exercises Message-ID: I found the below link to be an illuminating read in regards to how to approach dynamic programming in haskell. Now I would like to test my understanding on different exercises. I'd like suggestions on problems that could be solved by the approach elucidated below. http://jelv.is/blog/Lazy-Dynamic-Programming/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From litchard.michael at gmail.com Wed Apr 12 23:35:32 2017 From: litchard.michael at gmail.com (Michael Litchard) Date: Wed, 12 Apr 2017 16:35:32 -0700 Subject: [Haskell-cafe] looking for a file mentioned on haskell.org Message-ID: Can someone post/send a copy of the file p83.dat mentioned in the below link? https://wiki.haskell.org/99_questions/80_to_89 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Apr 13 18:42:22 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 13 Apr 2017 14:42:22 -0400 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: <1ea4db55-64a4-fa4d-d09d-9f915eb64773@amok.cc> References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> <1ea4db55-64a4-fa4d-d09d-9f915eb64773@amok.cc> Message-ID: <58ce5535-214a-8ef0-3084-d3f8a22b2484@vex.net> On 2017-04-11 03:20 AM, Lana Black wrote: >> cabal configure > Resolving dependencies... > Configuring cabal-bug-0.1... > cabal: Missing dependency on a foreign library: > * Missing C library: HSrts-ghc8.0.2 > This problem can usually be solved by installing the system package that > provides this library (you may need the "-dev" version). If the library is > already installed but in a non-standard location then you can use the flags > --extra-include-dirs= and --extra-lib-dirs= to specify where it is. > > However, that doesn't prevent cabal build from succeeding, and now I > have a shared library linked to RTS. [...] > However, if I run cabal build without calling cabal configure first, the > latter fails and the build process is stopped at that point. This also > prevents me from building my project with stack. Here is the thing. I cannot reproduce either outcome. From lanablack at amok.cc Thu Apr 13 21:23:30 2017 From: lanablack at amok.cc (Lana Black) Date: Thu, 13 Apr 2017 21:23:30 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: <58ce5535-214a-8ef0-3084-d3f8a22b2484@vex.net> References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> <1ea4db55-64a4-fa4d-d09d-9f915eb64773@amok.cc> <58ce5535-214a-8ef0-3084-d3f8a22b2484@vex.net> Message-ID: <2f432e97-b46d-2999-bc91-590911dafc41@amok.cc> On 13/04/17 18:42, Albert Y. C. Lai wrote: > On 2017-04-11 03:20 AM, Lana Black wrote: >>> cabal configure >> Resolving dependencies... >> Configuring cabal-bug-0.1... >> cabal: Missing dependency on a foreign library: >> * Missing C library: HSrts-ghc8.0.2 >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the >> library is >> already installed but in a non-standard location then you can use the >> flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> >> However, that doesn't prevent cabal build from succeeding, and now I >> have a shared library linked to RTS. > > [...] > >> However, if I run cabal build without calling cabal configure first, the >> latter fails and the build process is stopped at that point. This also >> prevents me from building my project with stack. > > Here is the thing. I cannot reproduce either outcome. > I dug a bit further, and it looks like the cabal configure error is somehow related to Gentoo, since I'm only able to reproduce it there. Otherwise the solution you linked works perfectly. From corentin.dupont at gmail.com Fri Apr 14 12:42:51 2017 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Fri, 14 Apr 2017 14:42:51 +0200 Subject: [Haskell-cafe] ANN: Nomyx 1.0, the only game where you can change the rules Message-ID: After a loooooong wait... I am finally proud to announce Nomyx V1.0! Nomyx is a unique game where you can change the rules of the game itself while playing it. The major novelty in this version is that you can play even without knowing how to program. There is a library of rules that are ready to be proposed. Let's start a new game! You can login here: http://www.nomyx.net:8000/Nomyx The games are discussed on the mailing list: nomyx-game at googlegroups.com Here is a video introduction of the game: http://vimeo.com/58265498 I created a tutorial to learn how to play: http:// corentindupont.info/blog/posts/Programming/2014-09-23-Nomyx-Language.html Some background: this is an implementation of a Nomic [1] game in Haskell (I believe the first complete implementation of a Nomic game on a computer). At the beginning, the initial rules are describing: - how to add new rules and change existing ones. For example a unanimity vote is necessary to have a new rule accepted. - how to win the game. For example you win the game if you have 5 rules accepted. But of course even that can be changed! Cheers, Corentin [1] www.nomic.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanablack at amok.cc Fri Apr 14 13:55:19 2017 From: lanablack at amok.cc (Lana Black) Date: Fri, 14 Apr 2017 13:55:19 +0000 Subject: [Haskell-cafe] Haskell plugin dynamic linking issue In-Reply-To: <58ce5535-214a-8ef0-3084-d3f8a22b2484@vex.net> References: <5262913d-4b50-e57b-ac4a-b86dce5e833c@amok.cc> <1ea4db55-64a4-fa4d-d09d-9f915eb64773@amok.cc> <58ce5535-214a-8ef0-3084-d3f8a22b2484@vex.net> Message-ID: <87da3369-7af8-5ed6-6d60-ccec8bd8e885@amok.cc> On 13/04/17 18:42, Albert Y. C. Lai wrote: > On 2017-04-11 03:20 AM, Lana Black wrote: >>> cabal configure >> Resolving dependencies... >> Configuring cabal-bug-0.1... >> cabal: Missing dependency on a foreign library: >> * Missing C library: HSrts-ghc8.0.2 >> This problem can usually be solved by installing the system package that >> provides this library (you may need the "-dev" version). If the >> library is >> already installed but in a non-standard location then you can use the >> flags >> --extra-include-dirs= and --extra-lib-dirs= to specify where it is. >> >> However, that doesn't prevent cabal build from succeeding, and now I >> have a shared library linked to RTS. > > [...] > >> However, if I run cabal build without calling cabal configure first, the >> latter fails and the build process is stopped at that point. This also >> prevents me from building my project with stack. > > Here is the thing. I cannot reproduce either outcome. Disregard my previous email. The cause of this issue is that cabal tries to link a test executable with only libraries specified in extra-libs. Therefore the test build fails, because RTS isn't linked to base or ghc-prim. Now, here's the fun part. Because the test code supplied by cabal has no actual calls to any library functions, ld may filter out any unused libraries, which includes RTS in our case. This behaviour is controlled by --as-needed option and is enabled by default in Ubuntu, which, I assume, you are using. In my case, the workaround here would be to enable --as-needed by default in the system. From oleg at okmij.org Sat Apr 15 15:21:54 2017 From: oleg at okmij.org (Oleg) Date: Sun, 16 Apr 2017 00:21:54 +0900 Subject: [Haskell-cafe] Downsides of the Prompt Monad Message-ID: <20170415152154.GA4686@Magus.localnet> David Menendez wrote > It's worth noting that Prompt p is the free monad for a type constructor p, > just as Free f is the free monad for a Functor f. As such, when p is a > Functor, they are isomorphic. > data Free f a = Var a | Wrap (f (Free f a)) > newtype Prompt p a = > Prompt { unPrompt :: forall b. (forall i. p i -> (i -> b) -> b) -> (a -> b) -> b } > -- equivalently, Prompt p a = Done a | forall i. Prompt (p i) (i -> Prompt > p a) Indeed. The Freer monad paper, Sec 2.4, describes this correspondence in general: type FFree p = Free (Lan p) (FFree p is the alternative Prompt p in David's message) where Lan p is a (simple version) of the left Kan extension that turns any p :: * -> * into a functor. Once (Lan p) is a Functor, the standard free monad construction applies. The Freer monad paper then goes on to say that since the continuation is made explicit, it can be represented in a better way than just a function. From dbm at refined-audiometrics.com Sat Apr 15 16:56:11 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Sat, 15 Apr 2017 09:56:11 -0700 Subject: [Haskell-cafe] Wow Monads! Message-ID: It’s been about 15 years on/off since I first looked at Monads. This weekend I finally sat down and really learned what they are, how they work. I found what looks like the seminal paper on them by Phil Wadler: https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times. What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any mention of Monads. Surely there is a benefit that could be had… Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you? - DM -------------- next part -------------- An HTML attachment was scrubbed... URL: From litchard.michael at gmail.com Sat Apr 15 17:55:23 2017 From: litchard.michael at gmail.com (Michael Litchard) Date: Sat, 15 Apr 2017 10:55:23 -0700 Subject: [Haskell-cafe] Jane Street Question Message-ID: Could those of you who have worked at Jane Street comment on how often a hiring round occurs? Once a quarter? Twice a year? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jackhill at jackhill.us Sat Apr 15 18:43:10 2017 From: jackhill at jackhill.us (Jack Hill) Date: Sat, 15 Apr 2017 14:43:10 -0400 (EDT) Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: On Sat, 15 Apr 2017, David McClain wrote: > It’s been about 15 years on/off since I first looked at Monads. This weekend I finally sat down and really learned what they are, how they work. I found what looks like the > seminal paper on them by Phil Wadler: > https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf > > I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times. > > What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness > of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any > mention of Monads. Surely there is a benefit that could be had… > > Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you? > > - DM Hi David, My lisp experience comes mostly from Scheme, but GNU Guix build tool/package manager has a monad abstraction: . They've even borrowed used >>= notation for bind. Best, Jack From jeffbrown.the at gmail.com Sat Apr 15 19:18:07 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 15 Apr 2017 12:18:07 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: Using monads without static typing sounds hard. When I do anything monadic, I'm constantly using the :t directive to check type signatures, to make sure I'm plugging the right thing into the right thing. On Sat, Apr 15, 2017 at 11:43 AM, Jack Hill wrote: > On Sat, 15 Apr 2017, David McClain wrote: > > It’s been about 15 years on/off since I first looked at Monads. This >> weekend I finally sat down and really learned what they are, how they work. >> I found what looks like the >> seminal paper on them by Phil Wadler: >> https://page.mi.fu-berlin.de/scravy/realworldhaskell/materia >> lien/the-essence-of-functional-programming.pdf >> >> I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did >> tons of SML and OCaml programming. But I only dipped my toe into Haskell a >> few times. >> >> What I was looking for was a more in-depth understanding of Monads and >> how they work. I remember reading that Wadler paper many years ago, and I >> was intrigued by the conciseness >> of changing the interpreter to do different instrumentation. I was hoping >> to find a magic bullet like that for my Lisp code. And I noticed that Lisp >> almost never makes any >> mention of Monads. Surely there is a benefit that could be had… >> >> Anyone else have Lisp experience using Monads? Did it offer some major >> enhancements for you? >> >> - DM >> > > Hi David, > > My lisp experience comes mostly from Scheme, but GNU Guix build > tool/package manager has a monad abstraction: < > https://www.gnu.org/software/guix/manual/html_node/The-Store-Monad.html>. > They've even borrowed used >>= notation for bind. > > Best, > Jack > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 dbm at refined-audiometrics.com Sat Apr 15 21:18:29 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Sat, 15 Apr 2017 14:18:29 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: <0D2FB7AB-FA89-47F9-8645-31495C4BA137@refined-audiometrics.com> I don’t think it matters much about typing in this case. I am free to name the Monads anything I like, probably a name indicative of its purpose. I do see that if you insist on living by the conventional >> and >>= naming that it would need type checking to help it select the correct thing. What’s more important is what a Monad does and enables. Everything else is window dressing. - DM > On Apr 15, 2017, at 12:18, Jeffrey Brown wrote: > > Using monads without static typing sounds hard. When I do anything monadic, I'm constantly using the :t directive to check type signatures, to make sure I'm plugging the right thing into the right thing. > > On Sat, Apr 15, 2017 at 11:43 AM, Jack Hill > wrote: > On Sat, 15 Apr 2017, David McClain wrote: > > It’s been about 15 years on/off since I first looked at Monads. This weekend I finally sat down and really learned what they are, how they work. I found what looks like the > seminal paper on them by Phil Wadler: > https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf > > I’m a pretty heavy Common Lisp guy, going on 30 years with it. I also did tons of SML and OCaml programming. But I only dipped my toe into Haskell a few times. > > What I was looking for was a more in-depth understanding of Monads and how they work. I remember reading that Wadler paper many years ago, and I was intrigued by the conciseness > of changing the interpreter to do different instrumentation. I was hoping to find a magic bullet like that for my Lisp code. And I noticed that Lisp almost never makes any > mention of Monads. Surely there is a benefit that could be had… > > Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you? > > - DM > > Hi David, > > My lisp experience comes mostly from Scheme, but GNU Guix build tool/package manager has a monad abstraction: >. They've even borrowed used >>= notation for bind. > > Best, > Jack > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 donn at avvanta.com Sat Apr 15 21:24:59 2017 From: donn at avvanta.com (Donn Cave) Date: Sat, 15 Apr 2017 14:24:59 -0700 (PDT) Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <0D2FB7AB-FA89-47F9-8645-31495C4BA137@refined-audiometrics.com> References: <0D2FB7AB-FA89-47F9-8645-31495C4BA137@refined-audiometrics.com> Message-ID: <20170415212459.B59D9F3935@mail.avvanta.com> quoth David McClain > I don’t think it matters much about typing in this case. Try combining some monads, without help from the type checker. Donn From johnw at newartisans.com Sun Apr 16 01:13:56 2017 From: johnw at newartisans.com (John Wiegley) Date: Sat, 15 Apr 2017 18:13:56 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: (David McClain's message of "Sat, 15 Apr 2017 09:56:11 -0700") References: Message-ID: >>>>> "DM" == David McClain writes: MD> Anyone else have Lisp experience using Monads? Did it offer some major MD> enhancements for you? In Lisp, I don't think the abstraction buys you much, because all the functionality you need (state, exceptions, runtime, etc) are always available to all expressions. They become an excellent way of representing "extensible composition" in a pure language that otherwise could not allow those things, but I don't see that you need it for an untyped language like Lisp. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From jo at durchholz.org Sun Apr 16 10:00:42 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 16 Apr 2017 12:00:42 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> Am 15.04.2017 um 18:56 schrieb David McClain: > It’s been about 15 years on/off since I first looked at Monads. This > weekend I finally sat down and really learned what they are, how they > work. I found what looks like the seminal paper on them by Phil Wadler: > > https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf What I think he's doing is: - Define a standard language core. - Instead of hardcoding function application, he defers that to a function passed in as an externally-supplied parameter. - Various cleanup definition so that the construction properly interoperates with primitive values and primitive functions. - Leave the type parameter for the externally-supplied function from the signatures, for Haskell's type inference to determine. So all the signatures look much simpler than they really are; one could call this either "excellent abstraction" or "muddling the water so nobody sees what's going on", depending on how well one can read this kind of idiom. I didn't see this as "particularly wow"; I have seen similar things being done in Java EE (all those "request/response interceptor chains"). What would "wow" me was a language where this kind of technique were automatically present even if the author of the expression evaluator didn't prepare for it. I.e. if the language provided a way to take such an expression evaluator as in the paper, and gave people a way to add a monad in a post-hoc fashion (because expression evaluator designers typically forget to add this kind of feature, unless they have written a dozen of these things already). This kind of thing is also relatively easy to do in Java or any other language with parametric polymorphism, though adding the function parameter all over the place would be a pain in the @ss. Yeah I know that Phil highlights this as a plus, "just add these three lines and everything is automatically parametrized" - having worked with sub-average programmers and having done a lot of legacy maintenance, I'd say it's a strong minus because a single definition at the innermost level will substantially change the signature of the whole thing, suddenly you have a monad parameter in all the types. (I'm not 100% sure whether this is such a big problem, because it seems that monads are about the only thing you need to worry about in practice - everybody is talking about monad transformers and such, I don't see arrows and all the other higher-order-typing constructions given much attention in practice). (Full disclosure: Java programmer with interest in better ways to construct software, long-time Haskell lurker with several attempts at wrapping the mind around various concepts in life and found roughly one-third of them firmly in the "nice but grossly overhyped"... even after 20 years I'm still not decided about whether monads are in that category or not (pun unintended, honest!).) From saurabhnanda at gmail.com Sun Apr 16 11:51:57 2017 From: saurabhnanda at gmail.com (Saurabh Nanda) Date: Sun, 16 Apr 2017 17:21:57 +0530 Subject: [Haskell-cafe] Ensuring that blank-state has been handled in UIs? Message-ID: Hi Everyone, In most user-interfaces we need special-treatment for blank states (zero-item state). For example: * In case there are no customers, don't show an empty table, instead show the message "You seem to have no customers, why not start by creating one..." * In case there are no bookings, don't show an empty table, instead show the message, "No bookings here. Want to create one?" * In case there are no search results, don't show an empty table, instead show the message, "No items found. Undo your last filter?" In some cases, the one-item case also needs special treatment, but I'm unable to come with relatable examples at the moment. A lot of times the dev simply forgets about the blank state, and it is caught during QA, which results in a quick-fix on the following lines: if length item > 0 then displayTable else showBlankState if Data.Map.Strict.size map > 0 then displayTable else showBlankState if Data.Set.Ordered.size set > 0 then displayTable else showBlankState Is there a way to prevent this bug from the get-go? Can we use the type-system (or anything else) to enforce the dev to at least _think_ about the blank state? Obviously, the type system can't help us with _what_ needs to be done with the blank state, but at least it can _remind_ the dev at compile-time about handling blank states. -- Saurabh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.carnecky at gmail.com Sun Apr 16 12:03:26 2017 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Sun, 16 Apr 2017 12:03:26 +0000 Subject: [Haskell-cafe] Ensuring that blank-state has been handled in UIs? In-Reply-To: References: Message-ID: Make your 'displayTable' function take a 'NonEmpty a' instead of a List (eg. [a] or Vector a). That at least ensures that you won't ever be showing an empty table. I don't think there is a Map/Set-equivalent of NonEmpty. But you will have to convert a Map/Set into a list at some point, and that's where you can again use NonEmpty. https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/base-4.9.0.0/Data-List-NonEmpty.html On Sun, Apr 16, 2017 at 1:54 PM Saurabh Nanda wrote: > Hi Everyone, > > In most user-interfaces we need special-treatment for blank states > (zero-item state). For example: > > * In case there are no customers, don't show an empty table, instead show > the message "You seem to have no customers, why not start by creating > one..." > * In case there are no bookings, don't show an empty table, instead show > the message, "No bookings here. Want to create one?" > * In case there are no search results, don't show an empty table, instead > show the message, "No items found. Undo your last filter?" > > In some cases, the one-item case also needs special treatment, but I'm > unable to come with relatable examples at the moment. > > A lot of times the dev simply forgets about the blank state, and it is > caught during QA, which results in a quick-fix on the following lines: > > if length item > 0 then displayTable else showBlankState > if Data.Map.Strict.size map > 0 then displayTable else showBlankState > if Data.Set.Ordered.size set > 0 then displayTable else showBlankState > > Is there a way to prevent this bug from the get-go? Can we use the > type-system (or anything else) to enforce the dev to at least _think_ about > the blank state? Obviously, the type system can't help us with _what_ needs > to be done with the blank state, but at least it can _remind_ the dev at > compile-time about handling blank states. > > -- Saurabh. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Sun Apr 16 15:05:08 2017 From: monkleyon at gmail.com (MarLinn) Date: Sun, 16 Apr 2017 17:05:08 +0200 Subject: [Haskell-cafe] Ensuring that blank-state has been handled in UIs? In-Reply-To: References: Message-ID: <0d626232-543a-1ec9-f9f4-534619583995@gmail.com> On 2017-04-16 13:51, Saurabh Nanda wrote: > Can we use the type-system (or anything else) to enforce the dev to at > least _think_ about the blank state? That is an interesting problem. But I'd say the solution depends highly on your architecture. Tomas' suggestion to use NonEmpty could be one solution, and one you could try to build upon to track more details in the types. Alternatively, you could add a typeclass that just handles the zero-element-case. That way your constraints remind the developer to at least copy-paste a default implementation. showItemTable :: (HasZeroItemPresentation (presenter item)) => presenter item -> [item] -> Table item But maybe there's a much simpler solution: Create a datatype that stores the normal presentation function, a zero-case presentation function, and optionally a one-item presentation function. Now whenever someone creates a new type of item, they need a new presentation adapter. data TablePresenter item = TablePresenter { showZeroItems :: Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item -> Widget) } showItemTable :: TablePresenter item -> [item] -> Table item This should offer safety and code reuse, and it should be easy to integrate because you don't even have to start with types. Why be fancy when the simple solutions work? Cheers, MarLinn From simon at joyful.com Sun Apr 16 17:39:21 2017 From: simon at joyful.com (Simon Michael) Date: Sun, 16 Apr 2017 10:39:21 -0700 Subject: [Haskell-cafe] ANN: projects available for adoption Message-ID: <5E601163-D27F-4D72-86B3-B7A02DFAB350@joyful.com> Hi all, to increase focus on other things, I am offering the following projects for adoption. Are you interested in one of these ? Would you like to pick it up and make it shine ? Ideally you are a regular user of the project yourself, and will be a more active maintainer than I have been. Or, you might like to try being co-maintainer or release manager for a time. Let's talk! http://joyful.com/shelltestrunner - compares command-line programs or shell commands with expected output. http://hackage.haskell.org/package/quickbench - produces quick, readable comparative benchmarks of program invocations. http://hackage.haskell.org/package/rss2irc - an IRC bot that announces any RSS/Atom feed to IRC. Formerly used for hackagebot in #haskell. http://joyful.com/fungen - the oldest and easiest way to build cross platform, easy to install 2D games in haskell. Also: http://planet.darcs.net - Darcs-related feed aggregator (Planet Venus) http://planet.squeak.org - Squeak Smalltalk-related feed aggregators (Planet Venus) http://hub.darcs.net/simon/darcsum - emacs UI for darcs (think mini-magit) (elisp) http://zwiki.org - a powerful wiki engine built on the Zope 2 platform. (Long shot, just putting it out there.) (python) Best! -Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From hello at mario.net.au Sun Apr 16 19:54:34 2017 From: hello at mario.net.au (Mario Rogic) Date: Sun, 16 Apr 2017 19:54:34 +0000 Subject: [Haskell-cafe] Ensuring that blank-state has been handled in UIs? In-Reply-To: <0d626232-543a-1ec9-f9f4-534619583995@gmail.com> References: <0d626232-543a-1ec9-f9f4-534619583995@gmail.com> Message-ID: I think you might find the RemoteData solution here relevant to your problem: http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html I've been using it successfully for a lot of UI work. Even if you have a default handler function that gives a sane-ish default value for the context you'll be using it in (I.e "Loading..." in UI), I've found it helps keep interfaces sane even when you "forget" you actually care about the empty state. On Sun, 16 Apr 2017 at 15:07, MarLinn wrote: > On 2017-04-16 13:51, Saurabh Nanda wrote: > > Can we use the type-system (or anything else) to enforce the dev to at > > least _think_ about the blank state? > > That is an interesting problem. But I'd say the solution depends highly > on your architecture. Tomas' suggestion to use NonEmpty could be one > solution, and one you could try to build upon to track more details in > the types. Alternatively, you could add a typeclass that just handles > the zero-element-case. That way your constraints remind the developer to > at least copy-paste a default implementation. > > showItemTable :: (HasZeroItemPresentation (presenter item)) => > presenter item -> [item] -> Table item > > But maybe there's a much simpler solution: Create a datatype that stores > the normal presentation function, a zero-case presentation function, and > optionally a one-item presentation function. Now whenever someone > creates a new type of item, they need a new presentation adapter. > > data TablePresenter item = TablePresenter { showZeroItems :: > Widget; showItem :: item -> Widget; showSingleItem :: Maybe (item -> > Widget) } > > showItemTable :: TablePresenter item -> [item] -> Table item > > This should offer safety and code reuse, and it should be easy to > integrate because you don't even have to start with types. Why be fancy > when the simple solutions work? > > Cheers, > MarLinn > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- - Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbm at refined-audiometrics.com Sun Apr 16 21:07:00 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Sun, 16 Apr 2017 14:07:00 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> Message-ID: Heh!! My title “Wow” was not an expression of wonderment. Rather it was “Holy Cow! Monads, how can you guys be so obtuse?!” - DM > On Apr 16, 2017, at 03:00, Joachim Durchholz wrote: > > Am 15.04.2017 um 18:56 schrieb David McClain: >> It’s been about 15 years on/off since I first looked at Monads. This >> weekend I finally sat down and really learned what they are, how they >> work. I found what looks like the seminal paper on them by Phil Wadler: >> >> https://page.mi.fu-berlin.de/scravy/realworldhaskell/materialien/the-essence-of-functional-programming.pdf > > What I think he's doing is: > - Define a standard language core. > - Instead of hardcoding function application, he defers that to a function passed in as an externally-supplied parameter. > - Various cleanup definition so that the construction properly interoperates with primitive values and primitive functions. > - Leave the type parameter for the externally-supplied function from the signatures, for Haskell's type inference to determine. So all the signatures look much simpler than they really are; one could call this either "excellent abstraction" or "muddling the water so nobody sees what's going on", depending on how well one can read this kind of idiom. > > I didn't see this as "particularly wow"; I have seen similar things being done in Java EE (all those "request/response interceptor chains"). > > What would "wow" me was a language where this kind of technique were automatically present even if the author of the expression evaluator didn't prepare for it. I.e. if the language provided a way to take such an expression evaluator as in the paper, and gave people a way to add a monad in a post-hoc fashion (because expression evaluator designers typically forget to add this kind of feature, unless they have written a dozen of these things already). > This kind of thing is also relatively easy to do in Java or any other language with parametric polymorphism, though adding the function parameter all over the place would be a pain in the @ss. Yeah I know that Phil highlights this as a plus, "just add these three lines and everything is automatically parametrized" - having worked with sub-average programmers and having done a lot of legacy maintenance, I'd say it's a strong minus because a single definition at the innermost level will substantially change the signature of the whole thing, suddenly you have a monad parameter in all the types. (I'm not 100% sure whether this is such a big problem, because it seems that monads are about the only thing you need to worry about in practice - everybody is talking about monad transformers and such, I don't see arrows and all the other higher-order-typing constructions given much attention in practice). > > (Full disclosure: Java programmer with interest in better ways to construct software, long-time Haskell lurker with several attempts at wrapping the mind around various concepts in life and found roughly one-third of them firmly in the "nice but grossly overhyped"... even after 20 years I'm still not decided about whether monads are in that category or not (pun unintended, honest!).) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 monkleyon at gmail.com Sun Apr 16 22:43:45 2017 From: monkleyon at gmail.com (MarLinn) Date: Mon, 17 Apr 2017 00:43:45 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: On 2017-04-16 03:13, John Wiegley wrote: > MD> Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you? > > In Lisp, I don't think the abstraction buys you much, because all the functionality you need (state, exceptions, runtime, etc) are always available to all expressions. They become an excellent way of representing "extensible composition" in a pure language that otherwise could not allow those things, but I don't see that you need it for an untyped language like Lisp. May I present to you the lecture "Monads and Gonads" by Douglas Crockford (https://www.youtube.com/watch?v=b0EF0VTs9Dc). He shows that monads can make even a language like JavaScript useful (not his words). And the talk is one of the better monad tutorials out there to boot, not least because it's different from all the others. My own conclusion from it is that I would maybe even turn your argument around and claim that especially a language that has as few tools to keep programs sensible as JS can benefit greatly from the structure a monad provides. The benefits will be different for Lisp, but I imagine there might be some nice use cases as well. After all, structures are a great tool even if you're not forced to use them. ;) On another note: the more I work with monads and their brethren, the more I find myself thinking in terms of (a -> f b) functions instead of things like bind. Not only is it closer to the mathematical basis, but there's also the close relationship to lenses. I mention this because my feeling is that this type of function is a more usable puzzle piece in languages with limited syntax support. Especially if you also implement functors. But that's just unsubstantiated gut feeling. Cheers, MarLinn From dbm at refined-audiometrics.com Mon Apr 17 06:51:06 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Sun, 16 Apr 2017 23:51:06 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: Message-ID: That was absolutely excellent !! Great video presentation by Douglas Crockford. It took me about 2 hours to slowly advance through it, stopping along the way to translate his JS into Lisp to try out the Monads. This is by far the clearest explanation of Monads that I have seen, from among at least 2 dozen different videos and blogs. Even clearer than that Wadler paper. I highly recommend viewing this presentation. As for the rest of them, I hearken to the words of another great scientist who once stated that: “If you can’t explain a problem to your grandmother so that she understands it, then you don’t really understand the problem yourself…" - DM >> On Apr 16, 2017, at 15:43, MarLinn wrote: >> >> On 2017-04-16 03:13, John Wiegley wrote: >>> MD> Anyone else have Lisp experience using Monads? Did it offer some major enhancements for you? >>> >>> In Lisp, I don't think the abstraction buys you much, because all the functionality you need (state, exceptions, runtime, etc) are always available to all expressions. They become an excellent way of representing "extensible composition" in a pure language that otherwise could not allow those things, but I don't see that you need it for an untyped language like Lisp. >> >> May I present to you the lecture "Monads and Gonads" by Douglas Crockford (https://www.youtube.com/watch?v=b0EF0VTs9Dc). He shows that monads can make even a language like JavaScript useful (not his words). And the talk is one of the better monad tutorials out there to boot, not least because it's different from all the others. >> >> My own conclusion from it is that I would maybe even turn your argument around and claim that especially a language that has as few tools to keep programs sensible as JS can benefit greatly from the structure a monad provides. The benefits will be different for Lisp, but I imagine there might be some nice use cases as well. After all, structures are a great tool even if you're not forced to use them. ;) >> >> On another note: the more I work with monads and their brethren, the more I find myself thinking in terms of (a -> f b) functions instead of things like bind. Not only is it closer to the mathematical basis, but there's also the close relationship to lenses. I mention this because my feeling is that this type of function is a more usable puzzle piece in languages with limited syntax support. Especially if you also implement functors. But that's just unsubstantiated gut feeling. >> >> Cheers, >> MarLinn >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > From jo at durchholz.org Mon Apr 17 08:58:45 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 17 Apr 2017 10:58:45 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> Message-ID: <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Am 16.04.2017 um 23:07 schrieb David McClain: > Heh!! My title “Wow” was not an expression of wonderment. Rather it > was “Holy Cow! Monads, how can you guys be so obtuse?!” LOL okay :-D I think they suffer from being awesome even if not well-understood, so half-true statements about them get widely distributed. What I still don't know is if their face value is overhyped or not. The paper essentially displays how to do the visitor pattern in a functional way. Nothing to see here, move on... There are a few interesting aside points though: One, that this kind of injection can be done in a type-safe way (not a mean feat given the complexities of type parameters, but essentially follows from the choice of type system and, interestingly, the absence of side effects). This point is unrelated to monads, it's entirely conceivable that some other structure could have been used instead. Two, that the set of changes needed to turn a straightforward expression tree into an injectable one is so small. It's a mixed blessing, because the actual complexity of the definition is much larger than what you see at a glance. However, it's unrelated to monads as well, it's a consequence of having type inference and currying. Three, that the injected structure does not need to be more than merely conform to Monad, which is a pretty small core API (with "core" I mean the set of functions that cannot be expressed as composition of other API functions). Now this is indeed related to monads, but to me, it's unclear how important that finding is. I see monads being found all over the place, but is that a consequence of the Monad structure being so simple and permissive that it happens to match so many places in so many programs, is it because there are useful monad libraries that people actively make their code conform to the structure, is it perception bias (because monads are well-discussed so people can identify a Monad in their code but not an Arrow), or is Monad indeed tied to fundamental properties of coding? Frankly, I don't even know how to test the hypotheses here. What I do know is that we had a quite overhyped, simple but ubiquitous data structure earlier: Lists. In the 80ies, there was that meme that lists are the universal answers to data structures, mostly from the Lisp camp where lists were indeed fundamental, ubiquitous, and so simple they could be applied easily to all tasks. I haven't seen anybody seriously entertaining that thought in years; it will be interesting to see whether monads share that fate or prove to be something more fundamental. Just my 2 cents :-) From jan.loewenstein at gmail.com Mon Apr 17 12:56:47 2017 From: jan.loewenstein at gmail.com (=?UTF-8?Q?Jan_von_L=C3=B6wenstein?=) Date: Mon, 17 Apr 2017 12:56:47 +0000 Subject: [Haskell-cafe] Cross-compiling GHC Message-ID: Hi, I would like to have an integer-simple GHC for Mac and Linux. As there is no official download for that I should probably build it myself. My CI server is running Linux containers though. When https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling says "build must equal host", does that mean I cannot produce a mac ghc with Linux ci server? How do others produce ghc for mac or Windows? Best Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbm at refined-audiometrics.com Mon Apr 17 14:56:31 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Mon, 17 Apr 2017 07:56:31 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Message-ID: What I have been able to grok by translating into Lisp is that Monadic programming allows you to hide implicit accumulators, filters, control-flow (the Maybe Monad). Haskel absolutely needs Monads in order to force evaluation order in side-effecting places. Lisp doesn’t absolutely need Monads. I won’t really know if programming in Monadic style actually makes better looking code or not - cleaner, easier to grok, performant, organized? - until I try to apply it in anger on a larger project. But I am happy now that I finally understand this often obfuscated beast. The monster is actually a tiny mouse. I’m old enough now to have lived through at least two major programming fad cycles: Structured Programming followed by Object Oriented Programming. There are always nuggets to be found in any fad cycle, but unfortunately fad cycles always seem to swing to extremes. Psychologists would recognize that as borderline behavioral traits. I totally ignored the Programming Patterns cycle, so whenever I hear references to such patterns I first have to Google them. I can appreciate that practitioners would want a taxonomy, but for myself, I see programming patterns in an entirely different light. I have been designing and programming computers for longer than most readers on this site have been alive. But programming has always been only a tool for me, a sharp pencil, a side channel, in the pursuit of physics. Lisp has somehow managed to retain relevance to me throughout this entire period. I don’t choose languages for myself based on popularity. I want to get things done. And I want to do them quickly and move on to the next project. So, being in Lisp, I am not overly concerned with type safety. I don’t have to live in a community of programmers all contributing to the project code base. I am in complete control of the projects in their entirety. But if this were not the case, then certainly a strong case can be made in favor of type strictness. I did tons of SML and OCaml code about 10-15 years ago. I used to design languages and write commercial compilers for C and numerical analysis languages. But for my own uses, I find Lisp, on balance, to be my ultimate modeling clay. Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp. They might be useful to me. - DM > On Apr 17, 2017, at 01:58, Joachim Durchholz wrote: > > Am 16.04.2017 um 23:07 schrieb David McClain: >> Heh!! My title “Wow” was not an expression of wonderment. Rather it >> was “Holy Cow! Monads, how can you guys be so obtuse?!” > > LOL okay :-D > > I think they suffer from being awesome even if not well-understood, so half-true statements about them get widely distributed. > > What I still don't know is if their face value is overhyped or not. > > The paper essentially displays how to do the visitor pattern in a functional way. Nothing to see here, move on... > There are a few interesting aside points though: > > One, that this kind of injection can be done in a type-safe way (not a mean feat given the complexities of type parameters, but essentially follows from the choice of type system and, interestingly, the absence of side effects). This point is unrelated to monads, it's entirely conceivable that some other structure could have been used instead. > > Two, that the set of changes needed to turn a straightforward expression tree into an injectable one is so small. It's a mixed blessing, because the actual complexity of the definition is much larger than what you see at a glance. However, it's unrelated to monads as well, it's a consequence of having type inference and currying. > > Three, that the injected structure does not need to be more than merely conform to Monad, which is a pretty small core API (with "core" I mean the set of functions that cannot be expressed as composition of other API functions). > Now this is indeed related to monads, but to me, it's unclear how important that finding is. I see monads being found all over the place, but is that a consequence of the Monad structure being so simple and permissive that it happens to match so many places in so many programs, is it because there are useful monad libraries that people actively make their code conform to the structure, is it perception bias (because monads are well-discussed so people can identify a Monad in their code but not an Arrow), or is Monad indeed tied to fundamental properties of coding? Frankly, I don't even know how to test the hypotheses here. > What I do know is that we had a quite overhyped, simple but ubiquitous data structure earlier: Lists. In the 80ies, there was that meme that lists are the universal answers to data structures, mostly from the Lisp camp where lists were indeed fundamental, ubiquitous, and so simple they could be applied easily to all tasks. I haven't seen anybody seriously entertaining that thought in years; it will be interesting to see whether monads share that fate or prove to be something more fundamental. > > Just my 2 cents :-) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jo at durchholz.org Mon Apr 17 17:57:42 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 17 Apr 2017 19:57:42 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Message-ID: Am 17.04.2017 um 16:56 schrieb David McClain: > I totally ignored the Programming Patterns cycle, so whenever I hear > references to such patterns I first have to Google them. I can > appreciate that practitioners would want a taxonomy, but for myself, > I see programming patterns in an entirely different light. I have > been designing and programming computers for longer than most readers > on this site have been alive. But programming has always been only a > tool for me, a sharp pencil, a side channel, in the pursuit of > physics. Programming is complicated enough to require its own terminology, so it's more than a mere sharp pencil. Design Patterns were a fad, but a pretty atypical one, because the seminal work (the famous "Gang-of-Four Book") made it pretty clear what a Design Pattern was good for and what it wouldn't do. So a lot of the hyperbole was cut short. :-) From spam at scientician.net Mon Apr 17 18:12:10 2017 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 17 Apr 2017 20:12:10 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Message-ID: On 2017-04-17 16:56, David McClain wrote: > > Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp. > Beware that Crockford's understanding of monads itself has been questioned (based on this talk). It's been ages since I saw his video and don't feel inclined to watch it again, but I fancy myself as someone who _does_ understand monads[1] and can remember that his presentation seemed *incredibly* fuzzy and imprecise. This might give one the impression that they do understand, when they really don't. I'm not saying that's the case here, but it's something that anyone watching his video should be aware of. The only way to be sure is to try to implement some monads and monad transformers for yourself. (I'd be absolutely *terrified*, personally, of doing it in a unityped langauge because there are *so* many ways to get it subtly wrong and not know it until you hit exactly the "right" edge case. Heck, I even find it somewhat scary in Scala because it's rather easy to accidentally do something impure -- though if you're abstract about your types, you can usually avoid such accidents.) Btw, from my perspecitve the thing that makes monads work for arbitrary side effects is really *data dependencies* + the fact that IO is a sort of "fake" State World monad where you pretend that you always fully evaluate the World argument to the "next step". For anything non-IO it's really just a way to do arbitrary *control flow* based on runtime values -- whereas e.g. Applicative doesn't let you do that[2]. A more direct approach would be Algebraic Effects. Regards, [1] At least at an "intermediate" level. If you just go by the type signatures and desugaring it doesn't seem all that complicated to me, but whatever. I've always been inclined towards algebra/symbol manipulation, so maybe it's just me. [2] You can kind of simulate it, but you basically end up evaluating everything and "wasting computation" by redundant evaluation. You can think of it as always having to evaluate both branches of all if's and then choosing the result afterwards. Obviously, that doesn't work if you have *actual* side effects. From tobias.grosser at inf.ethz.ch Mon Apr 17 20:09:31 2017 From: tobias.grosser at inf.ethz.ch (Tobias Grosser) Date: Mon, 17 Apr 2017 22:09:31 +0200 Subject: [Haskell-cafe] Call for participation: PLDI 2017 and co-located events Message-ID: <1492459771.2579708.947193024.1FCB0126@webmail.messagingengine.com> Call for participation: PLDI 2017 and co-located events PLDI is the premier forum in the field of programming languages and programming systems research, covering the areas of design, implementation, theory, applications, and performance. The co-located conferences take place in Barcelona, June 18-23, 2017. This year, PLDI is co-located with ECOOP, LCTES, DEBS, ISMM, Curry On and others. The conferences will take place at the Universitat Polytècnica de Catalunya in Barcelona, Spain. http://conf.researchr.org/home/pldi-2017 Registration is now open, please visit: https://regmaster4.com/2017conf/BARC17/register.php to register. The early registration rate ends on May 26th. The tentative program is available at: http://pldi17.sigplan.org/program/program-pldi-2017 PLDI will also hold an ACM Student Research Competition: http://pldi17.sigplan.org/track/pldi-2017-student-research-competition Co-located events: + ECOOP: European Conference on Object-Oriented Programming + DEBS: annual conference on Distributed Event-Based Systems + Curry On: conference on programming languages and emerging challenges in industry. + ISMM: International Symposium on Memory Management + LCTES: Languages, Compilers, and Tools for Embedded Systems Co-located workshops include: + ARRAY: Workshop on Libraries, Languages and Compilers for Array Programming + DSW: Deep Specifications in the Wild + FMS: Formal Methods for Security + IC: Workshop on Incremental Computing + MAPL: Machine Learning and Programming Languages + PLMW: Programming Languages Mentoring Workshop + SOAP: International Workshop on the State Of the Art in Java Program Analysis + WCIRE: Workshop for Compiler Infrastructure for Research and Education Additionally, there will be eight co-located tutorials: + Bug detection in JavaScript web apps using the SAFE framework + Building your own modular static analyzer with Facebook Infer + Engineering Static Analyzers with Soufflé + Graal: High Performance Compilation for Managed Languages + P4: Programming the Network Data Plane + Polyhedral Compilation + Refinement Types for Program Verification and Synthesis + Scala, LMS and Delite for High-Performance DSLs and Program Generators + WALA Hack-A-Thon + Writing Verified Programs in CakeML See the web site for a schedule and further details and links. For further updates, follow PLDI on the social media: Facebook: https://www.facebook.com/PLDIConf Twitter: https://twitter.com/PLDI Albert Cohen, PLDI 2017 General Chair Tobias Grosser, PLDI 2017 Publicity Chair From dbm at refined-audiometrics.com Mon Apr 17 19:26:32 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Mon, 17 Apr 2017 12:26:32 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Message-ID: > who _does_ understand monads[1] and can remember that his presentation > seemed *incredibly* fuzzy and imprecise. Interesting comment… I was just reading up on the history of Pure Lisp, and the earliest attempts at reconciling mathematics with the early Lisp interpreters. In there they pointed out the initial disparity between denotational semantics and operational semantics. What I gained from Crockford’s presentation was a (my own in Lisp) clean implementation of operators called Unit and Bind, and I find those to be quite operationally simple, clever, and potentially useful. However, I have not attempted the verification with the 3 Monadic Lemmas on my own. Two of them should be quite obvious by inspection. The third, relating to functional composition awaits scrutiny. But beyond that, I find the general framework potentially useful. As I mentioned, they should be capable of accumulation (lists, binding trees, environments, etc), filtering out elements during accumulation, and control flow (the Maybe Monad). All of these are clear in my mind, and require only minor modifications to the specific implementations of the generic Bind operator. Now, I am hugely experienced in not only Lisp, but going all the way back down to pre-C languages and Assembly. So I have a pretty solid understanding of operational semantics. I am not personally frightened, for my own projects, of typing issues. I would be more scared if I had to exist in a group of programmers, all of whom contribute to the project code base. My own projects only rarely suffer from type issues. A bigger category of mistakes comes from simple keyboard typos and incorrect choice of algorithms. Apart from choice of algorithms, I find typically 1 bug per 50-100 LOC (operational lines). Compared to C, that is a factor of 10’s less bug prone. Add to that, the increased semantic value of 1 LOC of Lisp compared to C, and you get an efficiency increase of 1,000’s. But even in C, the typing is not the main issue, at least it hasn’t been for me. When I initially embarked on SML and OCaml, back in the late 1990’s, I was initially enthralled by the power of strong typing with inference. I was able to solve a nonlinear optimization over 150+ DOF using OCaml, whereas we had been stuck and bombing out after only 5 DOF using the strictly imperative Fortran-like language we had been using. I was so impressed, that word got out, and Phil Wadler invited me to write up my findings for his ACM Letters, which I did. And BTW… the breakthrough had absolutely nothing to do with typing and type inference. The success arose because of clean versus unclean control-flow. So you could say that OCaml adhered to “Structured Programming” in a better manner, which corresponds entirely to a fad cycle 2 layers back in time. But then after several years of pushing forward with OCaml, in writing math analysis compilers and image recognition systems, I began to find that, despite proper typing and clean compiles, system level issues would arise and cause my programs to fail. The holy grail of provably correct code came tumbling down in the face of practical reality. That’s when I began migrating back over to my old standby Lisp system. I live inside of my Lisp all day long, for days on end. It is a whole ecosystem. There is not crisp boundary of edit / compile / debug. It is all incremental and extensional. I think that kind of environment, regardless of language, is the holy grail of computing. I even had that kind of experience back in the late 1970’s when we were writing large telescope control systems in Forth. - DM > On Apr 17, 2017, at 11:12, Bardur Arantsson wrote: > > On 2017-04-17 16:56, David McClain wrote: >> >> Monads were always a hole in my knowledge. I read Phil Wadler’s paper more than a decade ago, and I remember being impressed at the terseness of his little interpreter. But Monads kept being offered with all the extraneous Category Theory stuff, and all the black-box mysticism. Now that I have seen Crockford's video, translated his JavaScript into my Lisp, I thoroughly get what they are all about in languages like Javascript and now Lisp. >> > > Beware that Crockford's understanding of monads itself has been > questioned (based on this talk). It's been ages since I saw his video > and don't feel inclined to watch it again, but I fancy myself as someone > who _does_ understand monads[1] and can remember that his presentation > seemed *incredibly* fuzzy and imprecise. > > This might give one the impression that they do understand, when they > really don't. > > I'm not saying that's the case here, but it's something that anyone > watching his video should be aware of. The only way to be sure is to try > to implement some monads and monad transformers for yourself. > > (I'd be absolutely *terrified*, personally, of doing it in a unityped > langauge because there are *so* many ways to get it subtly wrong and not > know it until you hit exactly the "right" edge case. Heck, I even find > it somewhat scary in Scala because it's rather easy to accidentally do > something impure -- though if you're abstract about your types, you can > usually avoid such accidents.) > > Btw, from my perspecitve the thing that makes monads work for arbitrary > side effects is really *data dependencies* + the fact that IO is a sort > of "fake" State World monad where you pretend that you always fully > evaluate the World argument to the "next step". For anything non-IO it's > really just a way to do arbitrary *control flow* based on runtime values > -- whereas e.g. Applicative doesn't let you do that[2]. A more direct > approach would be Algebraic Effects. > > Regards, > > [1] At least at an "intermediate" level. If you just go by the type > signatures and desugaring it doesn't seem all that complicated to me, > but whatever. I've always been inclined towards algebra/symbol > manipulation, so maybe it's just me. > > [2] You can kind of simulate it, but you basically end up evaluating > everything and "wasting computation" by redundant evaluation. You can > think of it as always having to evaluate both branches of all if's and > then choosing the result afterwards. Obviously, that doesn't work if you > have *actual* side effects. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 wangbj at gmail.com Mon Apr 17 20:34:53 2017 From: wangbj at gmail.com (Baojun Wang) Date: Mon, 17 Apr 2017 20:34:53 +0000 Subject: [Haskell-cafe] slow type level function Message-ID: Hello cafe, I tried to play with some type level natural numbers, and it seems type level function is quite slow, for instance: (full source) https://gist.github.com/wangbj/5939aa7a30c3d756d98f5b5775e162a6 data Z data S n class KnownNat n where natSing :: n -> Integer instance KnownNat Z where natSing _ = 0 instance KnownNat n => KnownNat (S n) where natSing _ = 1 + natSing (undefined :: n) natVal :: KnownNat n => n -> Integer natVal = natSing natSing doesn't seems to know how to optimize when KnownNat is very big (i.e: 10000), I tried Peano Add/Mul, and they are very slow to be really useful. Is there any ways to improve this? How fully dependent typed language such as Adga/Idris handle this, do they have the same performance issue? Thanks baojun -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Mon Apr 17 20:48:01 2017 From: will.yager at gmail.com (Will Yager) Date: Mon, 17 Apr 2017 15:48:01 -0500 Subject: [Haskell-cafe] slow type level function In-Reply-To: References: Message-ID: <3D5DA9F3-7630-4DFA-B994-A81FC35E1CC6@gmail.com> As I recall from the Idris paper, the compiler has special knowledge about types like Nat. As you have noticed, actually computing peano numbers is quite slow. Take a look at https://hackage.haskell.org/package/ghc-typelits-natnormalise for an example of "cheating" and embedding integers at the type level with special support. Will > On Apr 17, 2017, at 3:34 PM, Baojun Wang wrote: > > Hello cafe, > > I tried to play with some type level natural numbers, and it seems type level function is quite slow, for instance: > > (full source) > https://gist.github.com/wangbj/5939aa7a30c3d756d98f5b5775e162a6 > > data Z > data S n > > class KnownNat n where > natSing :: n -> Integer > > instance KnownNat Z where > natSing _ = 0 > instance KnownNat n => KnownNat (S n) where > natSing _ = 1 + natSing (undefined :: n) > > natVal :: KnownNat n => n -> Integer > natVal = natSing > > natSing doesn't seems to know how to optimize when KnownNat is very big (i.e: 10000), I tried Peano Add/Mul, and they are very slow to be really useful. Is there any ways to improve this? How fully dependent typed language such as Adga/Idris handle this, do they have the same performance issue? > > Thanks > baojun > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 djohnson.m at gmail.com Mon Apr 17 21:22:42 2017 From: djohnson.m at gmail.com (David Johnson) Date: Mon, 17 Apr 2017 16:22:42 -0500 Subject: [Haskell-cafe] Cross-compiling GHC In-Reply-To: References: Message-ID: One (simple?) solution is to use the Nix package manager. Integer-simple GHCs were recently added (available on both Darwin and Linux afaik). After downloading the nix package manager, simply run: *nix-shell -p haskell.compiler.integer-simple.ghc802* The above command will put you into a shell with an integer-simple GHC-8.0.2 For more info on nix and haskell, this is a good guide: https://github.com/Gabriel439/haskell-nix Along with what is mentioned in the nixpkgs manual. http://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure - David On Mon, Apr 17, 2017 at 7:56 AM, Jan von Löwenstein < jan.loewenstein at gmail.com> wrote: > Hi, > > I would like to have an integer-simple GHC for Mac and Linux. As there is > no official download for that I should probably build it myself. > > My CI server is running Linux containers though. > > When https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling says > "build must equal host", does that mean I cannot produce a mac ghc with > Linux ci server? How do others produce ghc for mac or Windows? > > Best > Jan > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Cell: 1.630.740.8204 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Tue Apr 18 06:56:56 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 18 Apr 2017 08:56:56 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> Message-ID: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> Am 17.04.2017 um 21:26 schrieb David McClain: > And BTW… the breakthrough had absolutely nothing to do with typing > and type inference. The success arose because of clean versus unclean > control-flow. So you could say that OCaml adhered to “Structured > Programming” in a better manner, which corresponds entirely to a fad > cycle 2 layers back in time. That's not the first time I hear such statements. One other instance is Erlang users writing that it's not the functional aspect that is making it effective (Erlang isn't particularly strong in that area anyway), it's garbage collection (i.e. no invalid pointers to dereference). > But then after several years of pushing forward with OCaml, in > writing math analysis compilers and image recognition systems, I > began to find that, despite proper typing and clean compiles, system > level issues would arise and cause my programs to fail. The holy > grail of provably correct code came tumbling down in the face of > practical reality. What happened with these OCaml programs? I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me. From zocca.marco at gmail.com Tue Apr 18 08:48:53 2017 From: zocca.marco at gmail.com (Marco Zocca) Date: Tue, 18 Apr 2017 10:48:53 +0200 Subject: [Haskell-cafe] Req. for co-maintaining hs-libhdf5 and bindings-hdf5 Message-ID: Dear all, I would like to help taking care of two libraries for HDF5. The author, James Cook (mokus0 on GitHub, CC'd here), didn't reply to a private email I sent about this on April 12. I hope he's doing well, by the way. HDF5 is a popular format for scientific datasets, and it would be a pity to see the Haskell bindings bitrot. I have previous experience building Haskell C bindings with HSC, c2hs and inline-c, and as co-maintainer I would, as first steps, add memory brackets and user-facing `exceptions`, enable continuous integration (Travis) and "stack-ify" the libraries. Hoping to hear soon from James and/or the Hackage trustees; All the best, Marco (ocramz) From ollie at ocharles.org.uk Tue Apr 18 13:16:43 2017 From: ollie at ocharles.org.uk (Oliver Charles) Date: Tue, 18 Apr 2017 14:16:43 +0100 Subject: [Haskell-cafe] containers: Efficiently concatenating nested maps (or should I look at another data structure) Message-ID: <87shl5vosk.fsf@nixos-desktop.i-did-not-set--mail-host-address--so-tickle-me> Hi all, First, a little context. I'm currently working on [1] a little OpenGL project - a Quake 3 map viewer in Haskell. For the most part, things are working out great, but the way I construct the scene is costing me a lot of alloction, and I wonder if I can do better. The OpenGL system is essentially a giant state machine. Whenever you issue a draw call ("draw these triangles"), OpenGL will do different things depending on what the state is. For example, if you have a texture bound, then the triangle will be textured, and if you have blending enabled, then the triangle might be blended into whatever was drawn previously. While this can be tricky to manage, Haskell does a good job of giving us tools to model state. The real spanner is that state transitions are not free. In the above example, the state transitions associated with binding a texture or enabling blending both cost time - and this time is variable depending on the state change. In this case, setting the currently bound texture is a very expensive operation, whereas setting the blending mode is less costly. For this reason, it's common in graphics programming to want to sort draw calls to minimise state changes. For example, we might draw all triangles with texture 1, then all triangles with texture 2 - rather than interleaving those draw calls. To model this in Haskell, I'm using a tree-like structure to group and express each state change [2]. To give you an example of what this looks like, I have: class RenderNode a m where draw :: a -> m () instance RenderNode (IO ()) IO where draw = id newtype BindTexture a = BindTexture (MonoidalIntMap a) [3] deriving (Functor, Monoid) instance (MonadIO m, RenderNode a m) => RenderNode (BindTexture a) m where draw (BindTexture t) = IM.foldrWithKey (\texture0 m next -> do glActiveTexture GL_TEXTURE0 glBindTexture GL_TEXTURE_2D (fromIntegral texture0) draw m next) (return ()) (getMonoidalIntMap t) newtype BlendMode a = BlendMode (MonoidalMap (GLuint, GLuint) a) [3] deriving (Functor, Monoid) blendMode :: (GLuint, GLuint) -> a -> BlendMode a blendMode srcDst = BlendMode . MonoidalMap . Map.singleton srcDst instance (MonadIO m, RenderNode a m) => RenderNode (BlendMode a) m where draw (BlendMode m) = Map.foldrWithKey (\(srcBlend, destBlend) child next -> do glBlendFunc srcBlend destBlend draw child next) (return ()) (getMonoidalMap m) I can then stack these nodes together to form a "render graph": newtype RenderGraph = RenderGraph (BindTexture (BlendMode (IO ()))) deriving (Monoid) The IO action at the leaf corresponds to a draw call to draw some triangles. Now that I've explained the basics of my rendering plan, I just need to tell you a little bit about Quake 3 maps. A Quake 3 map is essentially a big soup of "faces", where each face is a collection of triangles (that can be drawn in one call) and a set of associated state. Furthermore, each face is assigned a "cluster" (an Int), and we have a function that given a cluster gives us back a list of other clusters that we can "see" - this is visibility determination, or occlusion culling. I am hence modelling the map as an IntMap RenderGraph - each cluster maps to a RenderGraph of how to draw all the faces in that cluster, organised to minimise draw calls. Then, given some sort of visibility check, when I render I filter this IntMap to only the clusters that can be seen, and combine all the render graphs: IntMap.foldlWithKey' (\scene clusterNumber clusterFaces -> scene <> clusterFaces) mempty clusters In reality, this results in combining a few hundred-thousad very deeply nested structures, and naturally that's resulting in a fair bit of allocation pressure. I need to do this almost every frame, because as the camera moves, we might be able to see different clusters, so I don't think there's really much that I can cache. My actual final RenderGraph is Sort |> Cull |> MultiplePasses |> BindTexture |> SetUniform Bool |> SetDynamicUniform (M33 Float) |> AlphaFunc |> BlendMode |> DepthFunc where (|>) is Functor composition, and each of those functors is either a Map or IntMap. It seems to deteriorate to pairwise `mappend`, as you can see from the definition of mappend for MonoidalMap or MonoidalIntMap in [3]. Can anyone think of any obvious ways to rewrite this to have less allocation pressure? I'm of course open to other ways to batch operations, but there is something I find quite beautiful about shoving everything into Maps and mappending them. In the C world, the approach is usually to combine all the states into a single bitmask, and then sort that. That same approach might be possible here, but I'd like to keep the pick-and-choose compositional nature that I've got above. Thanks for reading this far, I hope my post has made sense. If you need clarification on anything, the source is below, and don't hesitate to ask me any questions! -- ocharles [1]: http://github.com/ocharles/hs-quake-3 [2]: https://github.com/ocharles/hs-quake-3/blob/master/RenderGraph.hs [3]: newtype MonoidalMap k a = MonoidalMap { getMonoidalMap :: Map k a } instance Functor (MonoidalMap k) where fmap f (MonoidalMap a) = MonoidalMap (fmap f a) instance (Monoid a, Ord k) => Monoid (MonoidalMap k a) where mempty = MonoidalMap Map.empty mappend (MonoidalMap a) (MonoidalMap b) = MonoidalMap (Map.unionWith mappend a b) mconcat = coerce . Map.unionsWith mappend . (coerce :: [MonoidalMap k a] -> [Map k a]) newtype MonoidalIntMap a = MonoidalIntMap { getMonoidalIntMap :: IntMap a } deriving (Functor) instance Monoid a => Monoid (MonoidalIntMap a) where mempty = MonoidalIntMap IM.empty mappend (MonoidalIntMap a) (MonoidalIntMap b) = MonoidalIntMap (IM.unionWith mappend a b) mconcat = coerce . IM.unionsWith mappend . (coerce :: [MonoidalIntMap a] -> [IntMap a]) From dbm at refined-audiometrics.com Tue Apr 18 14:57:20 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 07:57:20 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> Message-ID: > What happened with these OCaml programs? > I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me. Hi Joachim, Not sure what you are asking here? Do you mean, are they still extant? or do you want to know the failure mechanisms? The biggest program of the lot still remains, although I have not used it in nearly 10 years. It was a compiler for a math analysis language called NML (Numerical Modeling Language, Not ML, …). It borrowed the syntax of OCaml, was coded in OCaml, but was a vectorized math language with dynamic binding. For me, at the time, the biggest gain was treating all arrays as toroidal, so that I could easily play with FFT’s in multiple dimensions, and reach things like the tail of the array with negative indices. That, and the automatic vectorizing of overloaded math operators. That particular program began to fail as a result of the continual evolution of OCaml. It became a chore to constantly adapt to ever changing syntax patterns, on again / off again preprocessing of AST trees etc. But it did serve me well for about 5 years. About 20 KLOC of OCaml and 3 KLOC of supporting C glue code for access to BLAS, FFT’s, plotting graphics, etc. That NML effort was launched shortly after my initial success in the nonlinear optimization that I mentioned. This was also a huge success for me, because I had tried repeatedly over the previous 5 years to construct an NML in C, then C++, and I always crapped out when the line count reached around 100 KLOC. Being able to produce a fully working system in 20 KLOC was a huge win. The other programs compiled properly, and yet failed in execution, but my recall is fuzzy. One of them had the job of trying to watch automobile traffic through several cameras, day and night, and try to give consistent identity to the images seen through separate cameras, their motion patterns, and so forth. The cameras did not have overlapping fields of view. Not an easy problem, especially on rainy nights with street reflections from headlights. I don’t recall the exact failures, but things like data structure Maps started to fail with Address Faults. That should not ever happen, according to theory, but it really does. On and off, I did have quite a bit of success with OCaml. But getting clients to accept OCaml in the code base, c.a. 2000-2005 was a major problem. They all had their in-house experts telling them that C++ and Java was the way to go… (I managed to avoid Java in my career). Another major project was an Embedded Scheme compiler aimed at DSP’s c.a. 2008. That worked quite well for me, no failures to speak of. But I did learn during that effort that pattern matching has its limits. You often want to match subtrees and stubs, and just writing them out becomes an exercise in write-only code. A fallback effort done later in Lisp succeeded even better, but that’s probably because of the lower impedance mismatch between Lisp / Scheme, compared to OCaml / Scheme. I never learned nor made use of the OOP in OCaml. Never seemed necessary. But then they started implementing syntax sugar to represent optional args, etc. and quite frankly the effort looks really cheesy and difficult to read. You might as well just use Common Lisp and be done with it. Then around 2008 I got invited to speak at the European Common Lisp Meeting in Hamburg, and they made their preferences for Lisp be strongly known. Despite whatever I had in OCaml, that would be of no interest to them. So I began reentry into Lisp in a serious way, and I have been there since. Lisp for me had been on/off since about 1985. There were side diversions into Forth, C, Objective-C-like compilers, Smalltalk, and lots of DSP coding in bare-metal DSP Assembly. Transputers and Occam for a while. Massively parallel computing on a 4096 processor SIMD DAP Machine, 46 node MIMD machines based on DSP / Transputers for airborne LIDAR underwater mine detection systems. Lots of history… - DM > On Apr 17, 2017, at 23:56, Joachim Durchholz wrote: > > Am 17.04.2017 um 21:26 schrieb David McClain: >> And BTW… the breakthrough had absolutely nothing to do with typing >> and type inference. The success arose because of clean versus unclean >> control-flow. So you could say that OCaml adhered to “Structured >> Programming” in a better manner, which corresponds entirely to a fad >> cycle 2 layers back in time. > > That's not the first time I hear such statements. > One other instance is Erlang users writing that it's not the functional > aspect that is making it effective (Erlang isn't particularly strong in > that area anyway), it's garbage collection (i.e. no invalid pointers to > dereference). > >> But then after several years of pushing forward with OCaml, in >> writing math analysis compilers and image recognition systems, I >> began to find that, despite proper typing and clean compiles, system >> level issues would arise and cause my programs to fail. The holy >> grail of provably correct code came tumbling down in the face of >> practical reality. > > What happened with these OCaml programs? > I do see quite a few deficits in OCamls practices, but I don't know how relevant they are or if they are even related to your experience, so that would be interesting to me. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jo at durchholz.org Tue Apr 18 15:18:53 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 18 Apr 2017 17:18:53 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> Message-ID: <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> Am 18.04.2017 um 16:57 schrieb David McClain: > > Not sure what you are asking here? Do you mean, are they still > extant? or do you want to know the failure mechanisms? What failed for you when you were using OCaml. From dbm at refined-audiometrics.com Tue Apr 18 15:39:45 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 08:39:45 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> Message-ID: <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> Well, as I stated, I think failures come in several categories: 1. Machine Fault failures on successfully compiled code. That’s the big nasty one. Provably correct code can’t fail, right? But it sometimes does. And I think you can trace that to the need to interface with the real world. The underlying OS isn’t written in OCaml. Neither are many of the C-libs on which OCaml depends. In an ideal world, where everything in sight has gone through type checking, you might do better. But that will never be the case, even when the current FPL Fad reaches its zenith. About that time, new architectures will appear underneath you and new fad cycles will be in their infancy and chomping at the bits to become the next wave… Reality is a constantly moving target. We always gear up to fight the last war, not the unseen unkowns headed our way. 2. Experimental languages are constantly moving tools with ever changing syntax and semantics. It becomes a huge chore to keep your code base up to date, and sooner or later you will stop trying. I have been through that cycle so many times before. Not just in OCaml. There is also RSI/IDL, C++ compilers ever since 1985, even C compilers. The one constant, believe it or not, has been my Common Lisp. I’m still running code today, as part of my system environment, that I wrote back in 1990 and have never touched since then. It just continues to work. I don’t have one other example in another language where I can state that. 3. Even if the underlying language were fixed, the OS never changing, all libraries fully debugged and cast in concrete, the language that you use will likely have soft edges somewhere. For Pattern-based languages with full type decorations (e.g., row-type fields), attempting to match composite patterns over several tree layers becomes an exercise in write-only coding. The lack of a good macro facility in current FPL is hindering. Yes, you can do some of it functionally, but that implies a performance hit. Sometimes the FPL compilers will allow you to see the initial AST parse trees and you might be able to implement a macro facility / syntax bending at that point. But then some wise guy back at language HQ decides that the AST tool is not really needed by anyone, and then you get stung for having depended on it. The manual effort to recode what had been machine generated becomes too much to bear. 4. I will fault any language system for programming that doesn’t give you an ecosystem to live inside of, to allow for incremental extensions, test, recoding, etc. Edit / compile / debug cycles are awful. FPL allows you to generally minimize the debug cycle, by having you live longer at the edit / compile stage. But see some of the more recent work of Alan Kay and is now defunct project. They had entire GUI systems programmed in meta-language that compiles on the fly using JIT upon JIT. They make the claim that compilers were tools from another era, which they are, and that we should not be dealing with such things today. Heck, even the 1976 Forth system, crummy as it was, offered a live-in ecosystem for programming. So, that’s my short take on problems to be found in nearly all languages. There is no single perfect language, only languages best suited to some piece of your problem space. For me, Lisp offers a full toolbox and allows me to decide its shape in the moment. It doesn’t treat me like an idiot, and it doesn’t hold me to rigid world views. Is is perfect? Not by a long shot. But I haven’t found anything better yet… - DM > On Apr 18, 2017, at 08:18, Joachim Durchholz wrote: > > Am 18.04.2017 um 16:57 schrieb David McClain: >> >> Not sure what you are asking here? Do you mean, are they still >> extant? or do you want to know the failure mechanisms? > > What failed for you when you were using OCaml. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 dbm at refined-audiometrics.com Tue Apr 18 16:12:38 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 09:12:38 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> Message-ID: … step back about 40 years, and realize that people then understood the frailty of real machines. When I first interviewed with IBM back in 1982, before going with them on another project, one project group explained to me that they were working on error correction codes for large disk drive cache memories. Back in those days, the ceramic IC packages had trace amount of radioactive isotopes, and every once in a while an alpha particle would smash into a DRAM cell, splattering the charge away and dropping or setting bits. Now on a small memory system (a few KB in those days) the probability was low. But IBM was working on an 8 MB backing cache memory to speed up the disk I/O, and the likelihood of an errant bit worked out to about 1 per hour. That would be unacceptable. So IBM, like nearly all other memory manufacturers at the time, built memory systems with ECC. Fast forward to day, and we have cheap Chinese production machines. No memory ECC at all. And memory density is even higher than before. Oh yes, they ultimately found improved manufacturing processes so that the alpha particles aren’t anywhere near the problem today that they were in 1982. But higher bit density today, larger memories, solar flares, cosmic rays, and plenty of code bloat that depends on perfectly held memory… Who knows why an FPL module gives a machine fault? But they sometimes really do. - DM > On Apr 18, 2017, at 08:39, David McClain wrote: > > Well, as I stated, I think failures come in several categories: > > 1. Machine Fault failures on successfully compiled code. That’s the big nasty one. Provably correct code can’t fail, right? But it sometimes does. And I think you can trace that to the need to interface with the real world. The underlying OS isn’t written in OCaml. Neither are many of the C-libs on which OCaml depends. > > In an ideal world, where everything in sight has gone through type checking, you might do better. But that will never be the case, even when the current FPL Fad reaches its zenith. About that time, new architectures will appear underneath you and new fad cycles will be in their infancy and chomping at the bits to become the next wave… Reality is a constantly moving target. We always gear up to fight the last war, not the unseen unkowns headed our way. > > 2. Experimental languages are constantly moving tools with ever changing syntax and semantics. It becomes a huge chore to keep your code base up to date, and sooner or later you will stop trying. I have been through that cycle so many times before. Not just in OCaml. There is also RSI/IDL, C++ compilers ever since 1985, even C compilers. > > The one constant, believe it or not, has been my Common Lisp. I’m still running code today, as part of my system environment, that I wrote back in 1990 and have never touched since then. It just continues to work. I don’t have one other example in another language where I can state that. > > 3. Even if the underlying language were fixed, the OS never changing, all libraries fully debugged and cast in concrete, the language that you use will likely have soft edges somewhere. For Pattern-based languages with full type decorations (e.g., row-type fields), attempting to match composite patterns over several tree layers becomes an exercise in write-only coding. > > The lack of a good macro facility in current FPL is hindering. Yes, you can do some of it functionally, but that implies a performance hit. Sometimes the FPL compilers will allow you to see the initial AST parse trees and you might be able to implement a macro facility / syntax bending at that point. But then some wise guy back at language HQ decides that the AST tool is not really needed by anyone, and then you get stung for having depended on it. The manual effort to recode what had been machine generated becomes too much to bear. > > 4. I will fault any language system for programming that doesn’t give you an ecosystem to live inside of, to allow for incremental extensions, test, recoding, etc. Edit / compile / debug cycles are awful. FPL allows you to generally minimize the debug cycle, by having you live longer at the edit / compile stage. > > But see some of the more recent work of Alan Kay and is now defunct project. They had entire GUI systems programmed in meta-language that compiles on the fly using JIT upon JIT. They make the claim that compilers were tools from another era, which they are, and that we should not be dealing with such things today. > > Heck, even the 1976 Forth system, crummy as it was, offered a live-in ecosystem for programming. > > So, that’s my short take on problems to be found in nearly all languages. There is no single perfect language, only languages best suited to some piece of your problem space. For me, Lisp offers a full toolbox and allows me to decide its shape in the moment. It doesn’t treat me like an idiot, and it doesn’t hold me to rigid world views. Is is perfect? Not by a long shot. But I haven’t found anything better yet… > > - DM > >> On Apr 18, 2017, at 08:18, Joachim Durchholz wrote: >> >> Am 18.04.2017 um 16:57 schrieb David McClain: >>> >>> Not sure what you are asking here? Do you mean, are they still >>> extant? or do you want to know the failure mechanisms? >> >> What failed for you when you were using OCaml. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From andrei.paskevich at lri.fr Tue Apr 18 11:35:29 2017 From: andrei.paskevich at lri.fr (Andrei Paskevich) Date: Tue, 18 Apr 2017 13:35:29 +0200 Subject: [Haskell-cafe] VSTTE 2017 - Second Call for Papers Message-ID: <20170418113529.me6s4ajal7gckfgi@tikki.lri.fr> 9th Working Conference on Verified Software: Theories, Tools, and Experiments (VSTTE) https://vstte17.lri.fr July 22-23, 2017, Heidelberg, Germany Co-located with the 29th International Conference on Computer-Aided Verification, CAV 2017 Important Dates * Abstract submission: Mon, Apr 24, 2017 * Full paper submission: Mon, May 1, 2017 * Notification: Mon, Jun 5, 2017 * VSTTE: Sat-Sun, Jul 22-23, 2017 * Camera-ready: Mon, Aug 21, 2017 Overview The goal of the VSTTE conference series is to advance the state of the art in the science and technology of software verification, through the interaction of theory development, tool evolution, and experimental validation. We welcome submissions describing significant advances in the production of verified software, i.e., software that has been proved to meet its functional specifications. Submissions of theoretical, practical, and experimental contributions are equally encouraged, including those that focus on specific problems or problem domains. We are especially interested in submissions describing large-scale verification efforts that involve collaboration, theory unification, tool integration, and formalized domain knowledge. We also welcome papers describing novel experiments and case studies evaluating verification techniques and technologies. Topics of interest for VSTTE include education, requirements modeling, specification languages, specification/verification/certification case studies, formal calculi, software design methods, automatic code generation, refinement methodologies, compositional analysis, verification tools (e.g., static analysis, dynamic analysis, model checking, theorem proving, satisfiability), tool integration, benchmarks, challenge problems, and integrated verification environments. Paper Submissions We accept both long (limited to 16 pages) and short (limited to 10 pages) paper submissions. Short submissions also cover Verification Pearls describing an elegant proof or proof technique. Submitted research papers and system descriptions must be original and not submitted for publication elsewhere. Each submission will be evaluated by at least three members of the Program Committee. We expect that one author of every accepted paper will present their work at the conference. Paper submissions must be written in English using the LNCS LaTeX format (http://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines) and must include a cogent and self-contained description of the ideas, methods, results, and comparison to existing work. Papers will be submitted via EasyChair at the VSTTE 2017 conference page (https://www.easychair.org/conferences/?conf=vstte2017). The post-conference proceedings of VSTTE 2017 will be published in the LNCS series. Authors of accepted papers will be requested to sign the copyright transfer form. A selection of best papers will be invited for publication in the Journal of Automated Reasoning. Invited Speakers * Christoph Weidenbach (Max Planck Institute for Informatics, Germany) * Santiago Zanella-Beguelin (Microsoft Research, UK) Program Committee * June Andronick (University of New South Wales, Australia) * Christel Baier (TU Dresden, Germany) * Sandrine Blazy (Université de Rennes 1, France) * Arthur Charguéraud (Inria, France) * Ernie Cohen (Amazon Web Services, USA) * Rayna Dimitrova (MPI-SWS, Germany) * Carlo A. Furia (Chalmers University of Technology, Sweden) * Arie Gurfinkel (University of Waterloo, Canada) * Hossein Hojjat (Rochester Institute of Technology, USA) * Marieke Huisman (University of Twente, Netherlands) * Bart Jacobs (KU Leuven, Belgium) * Rajeev Joshi (NASA Jet Propulsion Laboratory, USA) * Zachary Kincaid (Princeton University, USA) * Akash Lal (Microsoft Research, India) * Shuvendu Lahiri (Microsoft Research, USA) * Francesco Logozzo (Facebook, USA) * Peter Müller (ETH Zürich, Switzerland) * Jorge A. Navas (SRI International, USA) * Scott Owens (University of Kent, UK) * Andrei Paskevich (Université Paris-Sud, France), co-chair * Gerhard Schellhorn (Universität Augsburg, Germany) * Peter Schrammel (University of Sussex, UK) * Natarajan Shankar (SRI International, USA) * Mihaela Sighireanu (Université Paris-Diderot, France) * Julien Signoles (CEA LIST, France) * Michael Tautschnig (Queen Mary University of London, UK) * Tachio Terauchi (JAIST, Japan) * Oksana Tkachuk (NASA Ames Research Center, USA) * Mattias Ulbrich (Karlsruhe Institute of Technology, Germany) * Thomas Wies (New York University, USA), co-chair From jo at durchholz.org Tue Apr 18 16:28:22 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 18 Apr 2017 18:28:22 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> Message-ID: Am 18.04.2017 um 17:39 schrieb David McClain: > Well, as I stated, I think failures come in several categories: > > 1. Machine Fault failures on successfully compiled code. That’s the > big nasty one. Provably correct code can’t fail, right? But it > sometimes does. And I think you can trace that to the need to > interface with the real world. The underlying OS isn’t written in > OCaml. Neither are many of the C-libs on which OCaml depends. I think that any language will depend on C libs, and so all languages are afflicted by that. Of course some languages have their own software stack and need less external libs, so this depends. > 2. Experimental languages are constantly moving tools with ever > changing syntax and semantics. It becomes a huge chore to keep your > code base up to date, and sooner or later you will stop trying. I > have been through that cycle so many times before. Not just in OCaml. > There is also RSI/IDL, C++ compilers ever since 1985, even C > compilers. > > The one constant, believe it or not, has been my Common Lisp. I’m > still running code today, as part of my system environment, that I > wrote back in 1990 and have never touched since then. It just > continues to work. I don’t have one other example in another language > where I can state that. Java :-) Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall). > 3. Even if the underlying language were fixed, the OS never changing, > all libraries fully debugged and cast in concrete, the language that > you use will likely have soft edges somewhere. For Pattern-based > languages with full type decorations (e.g., row-type fields), > attempting to match composite patterns over several tree layers > becomes an exercise in write-only coding. > > The lack of a good macro facility in current FPL is hindering. Yes, > you can do some of it functionally, but that implies a performance > hit. Sometimes the FPL compilers will allow you to see the initial > AST parse trees and you might be able to implement a macro facility / > syntax bending at that point. But then some wise guy back at language > HQ decides that the AST tool is not really needed by anyone, and then > you get stung for having depended on it. The manual effort to recode > what had been machine generated becomes too much to bear. I think Lisp-style macros are too powerful. You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well. If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening. > 4. I will fault any language system for programming that doesn’t give > you an ecosystem to live inside of, to allow for incremental > extensions, test, recoding, etc. Edit / compile / debug cycles are > awful. FPL allows you to generally minimize the debug cycle, by > having you live longer at the edit / compile stage. > > But see some of the more recent work of Alan Kay and is now defunct > project. They had entire GUI systems programmed in meta-language that > compiles on the fly using JIT upon JIT. They make the claim that > compilers were tools from another era, which they are, and that we > should not be dealing with such things today. Well... the Java compiler doesn't really "exist" in a modern IDE, stuff is being compiled on-the-fly in the background, even with live reload inside a running program (with some restrictions, so this isn't perfect - but then Java is anything but perfect). So I do not think that compilers per se are a problem, though they way they often need to be used can be. > For me, Lisp offers a > full toolbox and allows me to decide its shape in the moment. It > doesn’t treat me like an idiot, and it doesn’t hold me to rigid world > views. Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of. It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team. From dbm at refined-audiometrics.com Tue Apr 18 16:57:10 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 09:57:10 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> Message-ID: <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> > > Java :-) > Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall). > I have never programmed in Java. I have watched others do so, and I interfaced some C++ code as a library to a Java app once. But I don’t live much in the typical commercial software world. I am a physicist (astrophysicist) and the closest I came to commercial software on / off were early versions of extended C compilers that I wrote, image analysis systems for MacDonald’s (!!?), and mostly the international war machine. My area has mostly been signal and image processing. I have never used a database in anger either, even though I have authored OODBMS systems. I wouldn’t really know how to wrap an app around a database, or even why you would do such a thing. That probably sounds really odd to anyone younger than about 40-50 years old. I have never written a web page. I don’t understand the fascination with HTML or XML or SGML or whatever you call it. Elaborated S-expressions that don’t seem to follow their own syntax rules. > I think Lisp-style macros are too powerful. > You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well. > If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening. > Too powerful for whom? Again, I’m lucky to be master of my own domain. I don’t have to share code with anyone. For me, the biggest errors come from incorrect algorithm choice, not coding, not typing, not library API incompatibilities. Coding I can do with my eyes closed, except for all the typos… but then even with eyes open those still happen. My very first year in computing, 1969, was the most frustrating year in my entire life. Everything I did was called wrong by the computer. Almost drove me to the point of tears. But then one day I woke up and I was one with the machine. Been that way for now, 47 years. > > Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of. > It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team. Isn’t that always the case, and always will be the case? Nobody can be certain how some library or application was written. You might have some pretty strong hints and hunches, but how can you be sure? Seems like the best bet is to treat everything as untrusted black boxes. Erlang probably offers the best security model against dependencies. If you look at any major element of code in production, it was probably written in a hurry under near unreasonable demands because hardware engineering overran their budgets and took some of yours, and the programmer may or may not have well understood his tools and language, or even if he did, he might have been daydreaming of being on the beach with his girlfriend instead of in this meat locker with the rest of you guys… My experience has been that hardware companies produce the most gawd-awful code you can imagine. Software shops vary… take M$ for instance - the bane of my existence. Looks like code gets pushed out the door and they rely on the audience to test it. Apple looks to me like a room full of really bright young minds, with no adult supervision. I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did. I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me. - DM From dbm at refined-audiometrics.com Tue Apr 18 17:36:46 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 10:36:46 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <20170418172048.GA17192@fuzzbomb> References: <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <20170418172048.GA17192@fuzzbomb> Message-ID: <0D33D27F-D948-4D9F-884C-3B68EAF915D6@refined-audiometrics.com> Your’e welcome… > On Apr 18, 2017, at 10:20, Bryan Richter wrote: > > On Tue, Apr 18, 2017 at 09:57:10AM -0700, David McClain wrote: >> <...> > > These posts of yours have been incredibly interesting to me, and I just > wanted to thank you for sharing them! I think my point about ecosystem programming is really about the importance of immediate feedback when crafting software. You need a powerful language so that you don’t get torpedoed with your fresh ideas with lots of mandatory scaffolding. In C-like languages the goal becomes one of writing a correct line of code. The strongly typed languages, of the FPL variety, don’t force that upon you. But you do get sidetracked by the challenge of getting that last bit of code to type check successfully. And if you aren’t already in an ecosystem with the language, even more distracted by the demands of the edit / compile cycle. Any distractions from your idea means that, if you happened to have chosen the wrong approach, you aren’t thinking properly about that aspect because the distractions have set up a nearer term goal for you to reach. We become like hamsters on a wheel, and we feel good after doing battle successfully. But the problem is, after all that, did it work the way you hoped? And without immediate feedback, even if you have some distractions that you must put up with, you are using an extended tape measure to flip the light switch on the opposite wall. I think Haskell does offer some ecosystems. I have one that I installed on my Mac a couple months ago called “Haskell for Mac” by Chakravarty. It seems a pretty nifty little environment, but I have only been in there for about an hour or two. Part of my own push for polygot creds. Another one that looks possibly interesting is Shen, formerly Qi. I did a fair amount with the old Qi language, even adding / correcting the compiler system to fit my own needs. Mastering the logic system is another challenge ahead of me. I was impressed at the implementation, and the equational reasoning, which I first saw back in the 1990’s with the publication of the SML Language. But right off the bat, Haskell will present the bigger challenge to me. There is a huge scaffold of type class hierarchy that comes in the base environment. Reminds me a bit of trying to learn the old MSVC system from yore… - DM From johannes.waldmann at htwk-leipzig.de Tue Apr 18 18:14:39 2017 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 18 Apr 2017 20:14:39 +0200 Subject: [Haskell-cafe] Where do I start if I would like help improve GHC compilation times? Message-ID: <17753911-471f-94f7-44d8-8f8649133b38@htwk-leipzig.de> > it would be quite helpful if `pretty` > gained a special-case for the infinite band-width case Absolutely +1 this. Not "pretty" but similar: https://github.com/jwaldmann/wl-pprint-text/commit/7843d96db57ab01c0be336a5be0d7bca61902005 - J.W. From wangbj at gmail.com Tue Apr 18 18:46:06 2017 From: wangbj at gmail.com (Baojun Wang) Date: Tue, 18 Apr 2017 18:46:06 +0000 Subject: [Haskell-cafe] slow type level function In-Reply-To: <3D5DA9F3-7630-4DFA-B994-A81FC35E1CC6@gmail.com> References: <3D5DA9F3-7630-4DFA-B994-A81FC35E1CC6@gmail.com> Message-ID: Thanks for the link, it seems a lot more complicated than I thought, but understandable since the Peano arithmetic is fully recursive, it may has the same performance issue even at value level. This make type level Nat less attractive, I think. With TypeLits (assuming it doesn't have the slow performance issue) it is impossible to write something like: add :: a -> b -> a+b add a b = a+b ? Thanks Baojun On Mon, Apr 17, 2017 at 13:48 Will Yager wrote: > As I recall from the Idris paper, the compiler has special knowledge about > types like Nat. As you have noticed, actually computing peano numbers is > quite slow. Take a look at > https://hackage.haskell.org/package/ghc-typelits-natnormalise for an > example of "cheating" and embedding integers at the type level with special > support. > > Will > > On Apr 17, 2017, at 3:34 PM, Baojun Wang wrote: > > Hello cafe, > > I tried to play with some type level natural numbers, and it seems type > level function is quite slow, for instance: > > (full source) > https://gist.github.com/wangbj/5939aa7a30c3d756d98f5b5775e162a6 > > data Z > data S n > > class KnownNat n where > natSing :: n -> Integer > > instance KnownNat Z where > natSing _ = 0 > instance KnownNat n => KnownNat (S n) where > natSing _ = 1 + natSing (undefined :: n) > > natVal :: KnownNat n => n -> Integer > natVal = natSing > > natSing doesn't seems to know how to optimize when KnownNat is very big > (i.e: 10000), I tried Peano Add/Mul, and they are very slow to be really > useful. Is there any ways to improve this? How fully dependent typed > language such as Adga/Idris handle this, do they have the same performance > issue? > > Thanks > baojun > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jan.loewenstein at gmail.com Tue Apr 18 18:46:36 2017 From: jan.loewenstein at gmail.com (=?UTF-8?Q?Jan_von_L=C3=B6wenstein?=) Date: Tue, 18 Apr 2017 18:46:36 +0000 Subject: [Haskell-cafe] Cross-compiling GHC In-Reply-To: References: Message-ID: I will definitely look at nix and cabal new-build. My current setup works but makes me ship insanely oversized tarballs... The project is a bosh-release (https://bosh.io), more precisely a cloud provider interface for Kubernetes ( https://github.com/sap/bosh-kubernetes-cpi-release). In order to have offline compilation with stack I currently have to package GHC thrice (darwin, linux and old-linux (centos)) plus half of stackage for my dependencies. Offline compilation is probably what will not make `nix-shell -p haskell.compiler.integer-simple.ghc802` particularly simple. Or will it still? Best Jan David Johnson schrieb am Mo., 17. Apr. 2017 um 23:22 Uhr: > One (simple?) solution is to use the Nix package manager. Integer-simple > GHCs were recently added (available on both Darwin and Linux afaik). After > downloading the nix package manager, simply run: > > *nix-shell -p haskell.compiler.integer-simple.ghc802* > > The above command will put you into a shell with an integer-simple > GHC-8.0.2 > > For more info on nix and haskell, this is a good guide: > https://github.com/Gabriel439/haskell-nix > > Along with what is mentioned in the nixpkgs manual. > http://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure > > - David > > On Mon, Apr 17, 2017 at 7:56 AM, Jan von Löwenstein < > jan.loewenstein at gmail.com> wrote: > >> Hi, >> >> I would like to have an integer-simple GHC for Mac and Linux. As there is >> no official download for that I should probably build it myself. >> >> My CI server is running Linux containers though. >> >> When https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling says >> "build must equal host", does that mean I cannot produce a mac ghc with >> Linux ci server? How do others produce ghc for mac or Windows? >> >> Best >> Jan >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > Cell: 1.630.740.8204 <(630)%20740-8204> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From twhitehead at gmail.com Tue Apr 18 19:41:22 2017 From: twhitehead at gmail.com (Tyson Whitehead) Date: Tue, 18 Apr 2017 15:41:22 -0400 Subject: [Haskell-cafe] Problem with tuple with one element constrained Message-ID: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> I've been unable to get the following (simplified) code to be accepted by GHCi (8.0.1 and 8.0.2) Prelude> let (x, y) = (1, return 2) :1:5: error: • Could not deduce (Monad m0) from the context: Num t bound by the inferred type for ‘x’: Num t => t at :1:5-24 The type variable ‘m0’ is ambiguous • When checking that the inferred type x :: forall a (m :: * -> *) t. (Num a, Num t, Monad m) => t is as general as its inferred signature x :: forall t. Num t => t and I don't seem to be able to provide a type signatures that GHCi is okay with Prelude> let { x :: Int; y :: Monad m => m Int; (x, y) = (1, return 2) } :5:40: error: • Ambiguous type variable ‘m0’ prevents the constraint ‘(Monad m0)’ from being solved. • When checking that the inferred type x :: forall a (m :: * -> *) t (m1 :: * -> *). (Num a, Num t, Monad m) => t is as general as its signature x :: Int Prelude> let (x, y) = (1, return 2) :: (Int, Monad m => m Int) :4:31: error: • Illegal qualified type: Monad m => m Int GHC doesn't yet support impredicative polymorphism • In an expression type signature: (Int, Monad m => m Int) In the expression: (1, return 2) :: (Int, Monad m => m Int) In a pattern binding: (x, y) = (1, return 2) :: (Int, Monad m => m Int) Prelude> let (x,y) = (1,return 2) :: Monad m => (Int, m Int) :7:5: error: • Ambiguous type variable ‘m0’ prevents the constraint ‘(Monad m0)’ from being solved. • When checking that the inferred type x :: forall (m :: * -> *). Monad m => Int is as general as its inferred signature x :: Int It seems the constraint on y leaks to x where it isn't well formed? Any help and/or explanations would be greatly appreciated. In my actual code the assignment is from the return value of a function so I can't just split it into two separate statements. Thanks! -Tyson From dev at justus.science Tue Apr 18 20:44:53 2017 From: dev at justus.science (Justus Adam) Date: Tue, 18 Apr 2017 13:44:53 -0700 Subject: [Haskell-cafe] Problem with tuple with one element constrained Message-ID: <1492548293.2513721.948531904.295EC998@webmail.messagingengine.com> I am not sure really what you are trying to do, but here are a few approaches which I think may solve your problem. 1. Calculate the monadic value outside or fmap over the tuple constructor for instance do x <- functionCall return (y, x) or (y, ) <$> functionCall (uses the TupleSections extension) 2. Use explicit forall and scoped type variables If you really want to return a tuple with that monadic value from a function then the `Monad m` constraint must be on the function itself. Like so Compiled with ExplicitForAll and ScopedTypeVariables myFunction :: forall m. Monad m => m ... myFunction = let x :: m SomeType (y, x) = (..., return ...) in ... Which binds `m` to be of the same type as the outer `m`. This is necessary as there must be some way that even from outside the function we can figure out what concretely `m` actually is. Ergo it must be bound in some way to the functions type signature. 3. ExistentialTypes If you __really__ think you only need a `Monad` constraint on this type (which I doubt) you can use an existential to wrap things into generic monads. (Uses ExistentialTypes) data ExtMonad a = forall m. Monad m => ExtMonad m a The thing I don't quite understand is, if you have a function call, which produces the value, doesn't that call return a concrete monad? Rather than just `Monad m`? It sounds to me like you're actually barking up the wrong tree when you try and do what you are doing here so I suggest using something like approach 1 or 2 and perhaps rethinking if your problem may lay somewhere else. Regards Justus -- Justus Adam dev at justus.science On Tue, Apr 18, 2017, at 12:41 PM, Tyson Whitehead wrote: > I've been unable to get the following (simplified) code to be accepted by > GHCi (8.0.1 and 8.0.2) > > Prelude> let (x, y) = (1, return 2) > :1:5: error: > • Could not deduce (Monad m0) > from the context: Num t > bound by the inferred type for ‘x’: > Num t => t > at :1:5-24 > The type variable ‘m0’ is ambiguous > • When checking that the inferred type > x :: forall a (m :: * -> *) t. (Num a, Num t, Monad m) => t > is as general as its inferred signature > x :: forall t. Num t => t > > and I don't seem to be able to provide a type signatures that GHCi is > okay with > > Prelude> let { x :: Int; y :: Monad m => m Int; (x, y) = (1, return 2) } > :5:40: error: > • Ambiguous type variable ‘m0’ > prevents the constraint ‘(Monad m0)’ from being solved. > • When checking that the inferred type > x :: forall a (m :: * -> *) t (m1 :: * -> *). > (Num a, Num t, Monad m) => > t > is as general as its signature > x :: Int > > Prelude> let (x, y) = (1, return 2) :: (Int, Monad m => m Int) > :4:31: error: > • Illegal qualified type: Monad m => m Int > GHC doesn't yet support impredicative polymorphism > • In an expression type signature: (Int, Monad m => m Int) > In the expression: (1, return 2) :: (Int, Monad m => m Int) > In a pattern binding: > (x, y) = (1, return 2) :: (Int, Monad m => m Int) > > Prelude> let (x,y) = (1,return 2) :: Monad m => (Int, m Int) > :7:5: error: > • Ambiguous type variable ‘m0’ > prevents the constraint ‘(Monad m0)’ from being solved. > • When checking that the inferred type > x :: forall (m :: * -> *). Monad m => Int > is as general as its inferred signature > x :: Int > > It seems the constraint on y leaks to x where it isn't well formed? Any > help and/or explanations would be greatly appreciated. In my actual code > the assignment is from the return value of a function so I can't just > split it into two separate statements. > > Thanks! -Tyson > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 sivanov at colimite.fr Tue Apr 18 21:01:21 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Tue, 18 Apr 2017 23:01:21 +0200 Subject: [Haskell-cafe] Problem with tuple with one element constrained In-Reply-To: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> References: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> Message-ID: <87a87dtopq.fsf@colimite.fr> Hello Tyson, Thus quoth Tyson Whitehead at 19:41 on Tue, Apr 18 2017: > > I've been unable to get the following (simplified) code to be accepted > by GHCi (8.0.1 and 8.0.2) > > Prelude> let (x, y) = (1, return 2) [...] > and I don't seem to be able to provide a type signatures that GHCi is > okay with GHCi handles polymorphic types of interactive expressions somewhat differently from the polymorphic types of expressions loaded from files. (I'd be happy if someone could reproduce the explanation which I saw a couple times but which I cannot find any more.) Anyway, I put the following in tuple.hs: func :: Monad m => (Int, m Int) func = (1, return 2) Then, ghci tuple.hs swallows the file no problem and allows me to do *Main> func :: (Int, Maybe Int) (1, Just 2) (I have GHCi 8.0.2.) -- 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 Tue Apr 18 21:33:48 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Tue, 18 Apr 2017 23:33:48 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> Message-ID: <878tmxtn7n.fsf@colimite.fr> Hello David, Thus quoth David McClain at 15:39 on Tue, Apr 18 2017: > > 1. Machine Fault failures on successfully compiled code. That’s the > big nasty one. Provably correct code can’t fail, right? But it > sometimes does. A very small remark (mostly directed at novice Haskell users reading this): code which typechecks is _not_ the same thing as _provably correct_ code. Code which typechecks is code in which function applications concord with the types. Provably correct code is code which was (or can be) (automatically) proved to correspond to a certain exact specification. Haskell or OCaml type systems are usually not used for writing such exact specifications, because they are not expressive enough. Thus, in general, showing that Haskell or OCaml code typechecks is weaker than proving that it has a certain property (like not failing). (However, passing Haskell or OCaml type checks is still stronger than passing Java type checks.) > And I think you can trace that to the need to interface with the real > world. I have the same gut feeling. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dbm at refined-audiometrics.com Tue Apr 18 22:47:28 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 15:47:28 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <877f2htn3a.fsf@colimite.fr> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <877f2htn3a.fsf@colimite.fr> Message-ID: <9A2DA583-C885-45E8-92A6-04BCA1841B37@refined-audiometrics.com> Hi Sergiu, Excellent point you make about type checking versus provably correct code. I probably allowed myself to be lulled by a false equivalence many times in the past, confusing one for the other under pressure to get something working. But then, how many programmers actually produce provably correct code? I can see that happening very easily in the small. But for overall large programs? - DM > On Apr 18, 2017, at 14:36, Sergiu Ivanov wrote: > > > Hello David, > > Thanks a lot for sharing your opinions, I find it very interesting. > > Thus quoth David McClain at 19:26 on Mon, Apr 17 2017: >> >> That’s when I began migrating back over to my old standby Lisp >> system. I live inside of my Lisp all day long, for days on end. It is >> a whole ecosystem. There is not crisp boundary of edit / compile / >> debug. It is all incremental and extensional. I think that kind of >> environment, regardless of language, is the holy grail of computing. > > Just a small question: have you ever tried Smalltalk/Squeak/Pharo? (I'm > in no way affiliated.) > > These guys seem to be quite keen on blending the edit/compile/debug > boundaries. > > -- > Sergiu From sivanov at colimite.fr Wed Apr 19 00:00:57 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 19 Apr 2017 02:00:57 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <9A2DA583-C885-45E8-92A6-04BCA1841B37@refined-audiometrics.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <877f2htn3a.fsf@colimite.fr> <9A2DA583-C885-45E8-92A6-04BCA1841B37@refined-audiometrics.com> Message-ID: <874lxltgee.fsf@colimite.fr> Thus quoth David McClain at 22:47 on Tue, Apr 18 2017: > > Excellent point you make about type checking versus provably correct > code. I probably allowed myself to be lulled by a false equivalence > many times in the past, confusing one for the other under pressure to > get something working. But then, how many programmers actually produce > provably correct code? I can see that happening very easily in the > small. But for overall large programs? According to my knowledge, as well as to the unverified remark on Wikipedia [0], not so many people prove their software correct. That's probably because current formal verification methods require a lot of effort and have trouble supporting somewhat variable end-user requirements within reasonable time bounds. -- Sergiu [0] https://en.wikipedia.org/wiki/Formal_verification#Industry_use -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From atrudyjane at protonmail.com Wed Apr 19 03:13:49 2017 From: atrudyjane at protonmail.com (Atrudyjane) Date: Tue, 18 Apr 2017 23:13:49 -0400 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> Message-ID: <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> "I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did." By no means a young programmer here, but am currently learning Haskell as my first functional language for fun. Occaasionally I'll lament the fact that functional programming was not part of my CS curriculum back in the mid 90's. What you say is true because at the end of the day, being a self teacher has been rewarding. Can't really call myself a polyglot though, as I tend to deep-dive into interests. "I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me." I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : ) Regards, Andrea Sent with [ProtonMail](https://protonmail.com) Secure Email. -------- Original Message -------- Subject: Re: [Haskell-cafe] Wow Monads! Local Time: April 18, 2017 11:57 AM UTC Time: April 18, 2017 4:57 PM From: dbm at refined-audiometrics.com To: haskell-cafe > > Java :-) > Breakage does happen, but it's rare, though the incident rate can go up if you don't know what you're doing (some people routinely use APIs wrongly, read Internet recipes rather than the docs that come with the Java libs, and are caught flat-footed when internals change - I guess you don't have that problem because you know your system well enough to avoid this kind of pitfall). > I have never programmed in Java. I have watched others do so, and I interfaced some C++ code as a library to a Java app once. But I don’t live much in the typical commercial software world. I am a physicist (astrophysicist) and the closest I came to commercial software on / off were early versions of extended C compilers that I wrote, image analysis systems for MacDonald’s (!!?), and mostly the international war machine. My area has mostly been signal and image processing. I have never used a database in anger either, even though I have authored OODBMS systems. I wouldn’t really know how to wrap an app around a database, or even why you would do such a thing. That probably sounds really odd to anyone younger than about 40-50 years old. I have never written a web page. I don’t understand the fascination with HTML or XML or SGML or whatever you call it. Elaborated S-expressions that don’t seem to follow their own syntax rules. > I think Lisp-style macros are too powerful. > You can get excellent results as long as everybody involved knows all the relevant macros and their semantics perfectly well, and for one-man teams like yourself this can work very well. > If you need to work with average programmers, this fails. In such an environment, you need to be able to read other peoples' code, and if they can define macros, you don't really know anymore what's happening. > Too powerful for whom? Again, I’m lucky to be master of my own domain. I don’t have to share code with anyone. For me, the biggest errors come from incorrect algorithm choice, not coding, not typing, not library API incompatibilities. Coding I can do with my eyes closed, except for all the typos… but then even with eyes open those still happen. My very first year in computing, 1969, was the most frustrating year in my entire life. Everything I did was called wrong by the computer. Almost drove me to the point of tears. But then one day I woke up and I was one with the machine. Been that way for now, 47 years. > > Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. There might be macros involved, there might be metaprogramming involved, or some kind of multiple dispatch with nonobvious defaulting rules, or a gazillion of other things that you have to be aware of. > It's not a problem if you know your system from the inside out, but it doesn't scale well to tasks that need to be done by a team. Isn’t that always the case, and always will be the case? Nobody can be certain how some library or application was written. You might have some pretty strong hints and hunches, but how can you be sure? Seems like the best bet is to treat everything as untrusted black boxes. Erlang probably offers the best security model against dependencies. If you look at any major element of code in production, it was probably written in a hurry under near unreasonable demands because hardware engineering overran their budgets and took some of yours, and the programmer may or may not have well understood his tools and language, or even if he did, he might have been daydreaming of being on the beach with his girlfriend instead of in this meat locker with the rest of you guys… My experience has been that hardware companies produce the most gawd-awful code you can imagine. Software shops vary… take M$ for instance - the bane of my existence. Looks like code gets pushed out the door and they rely on the audience to test it. Apple looks to me like a room full of really bright young minds, with no adult supervision. I guess if I could offer any advice to other younger programmers, it would be to push yourself to become a polyglot to expand your mental horizons of what is possible, and a historian to understand what went before you and why, so that you don’t keep repeating the same stupid mistakes we did. I could not be a production programmer. I’m definitely too much of a cowboy and a lone wolf. Teams are anathema to me. I need deep periods of isolation to think. People who manage to perform in production coding environments must have very different personalities from me. - DM _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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 ok at cs.otago.ac.nz Wed Apr 19 04:24:35 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 19 Apr 2017 16:24:35 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> Message-ID: <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> > On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe wrote: > > I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : ) It's hidden, but there is definitely "a me" in "team". And then it's time for "T". (Obscure Lisp reference.) Someone wrote: >> >> > I think Lisp-style macros are too powerful. It's true that higher-order functions can do a lot of the things people used macros to do, and better. However, having said "Lisp-style macros", Lisp is a tree with many branches. How about Scheme-style macros? >> > Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. This is also true in Haskell. Show me a piece of code golf with Arrows and LemurCoSprockets and such all over the place and I haven't a clue. Total bewilderment. Heck, show me *undocumented* code in a language without macros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'll be just as baffled, if it is big enough. (I've been staring at some old numeric code recently. One page is quite big enough...) From migmit at gmail.com Wed Apr 19 05:05:20 2017 From: migmit at gmail.com (MigMit) Date: Wed, 19 Apr 2017 07:05:20 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: http://www.offcenterdesigns.net/wp-content/uploads/wp-checkout/images/i-found-the-i-in-team-t-shirt-1344970569.jpg I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write. Az iPademről küldve 2017. ápr. 19. dátummal, 6:24 időpontban Richard A. O'Keefe írta: > >> On 19/04/2017, at 3:13 PM, Atrudyjane via Haskell-Cafe wrote: >> >> I used to, mainly C/C++. There is no "I" in team... Our personalities must be similar : ) > > It's hidden, but there is definitely "a me" in "team". > And then it's time for "T". (Obscure Lisp reference.) > > Someone wrote: >>> >>>> I think Lisp-style macros are too powerful. > > It's true that higher-order functions can do a lot of the things people used > macros to do, and better. > > However, having said "Lisp-style macros", Lisp is a tree with many branches. > How about Scheme-style macros? > >>>> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. > > This is also true in Haskell. Show me a piece of code golf with Arrows and > LemurCoSprockets and such all over the place and I haven't a clue. Total > bewilderment. Heck, show me *undocumented* code in a language without > macros, classes, or higher-order functions (Fortran 95? COBOL 85?) and I'll > be just as baffled, if it is big enough. (I've been staring at some old > numeric code recently. One page is quite big enough...) > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 dbm at refined-audiometrics.com Wed Apr 19 06:52:57 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Tue, 18 Apr 2017 23:52:57 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: > On Apr 18, 2017, at 22:05, MigMit wrote: > > http://www.offcenterdesigns.net/wp-content/uploads/wp-checkout/images/i-found-the-i-in-team-t-shirt-1344970569.jpg > > I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write. > Those first two sentences were a joke, eh? Macros exist to shape the language to suit the problem domain and prevent massive typos and fingers cramping up. I played around with Sanitary Macrology, or whatever they are called, in Dylan back in the late 90’s. Frankly, I find them maddening. I much prefer the Common Lisp style of macrology. But read up on macros in Quiennec’s book, “Lisp in Small Pieces”. They exist in a kind of no-man’s land in language stages. There really isn’t any one best kind of macrology. Back in OCaml land they used to have a preprocessor that could give you access to the AST’s from a first pass of compiling, and I made liberal use of a custom tree rewriter in order to give my vectorized / overloaded math language NML a better shape than plain OCaml syntax. That is yet another kind of macrology. And potentially just as powerful, if less convenient to use on the fly. - DM -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfredo.dinapoli at gmail.com Wed Apr 19 06:53:41 2017 From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli) Date: Wed, 19 Apr 2017 08:53:41 +0200 Subject: [Haskell-cafe] Where do I start if I would like help improve GHC compilation times? In-Reply-To: <17753911-471f-94f7-44d8-8f8649133b38@htwk-leipzig.de> References: <17753911-471f-94f7-44d8-8f8649133b38@htwk-leipzig.de> Message-ID: Hey all, after reading a bit and crosschecking what Ben said, it seems the masterplan should be this (happy path scenario): 1. Switch away from a String-centric representation for a Doc (to be abstracted, in theory, via typeclasses). This would ensure we can “jack-in” things like FastString or ByteString into pretty, without breaking encapsulation. 2. (Orthogonal) Remove accidental quadratic complexity in pretty by leveraging special case for infinite band-width case. If I understood correctly this is the scenario we are in when we do the ASM CodeGen phase, where performance matters. 3. We switch from “GHC Pretty” to “Pretty”, making sure nothing is broken in the process. I know there were some patches which were reverted because they caused a memory regression in the compiler. AFAIK the culprit is unclear. Another complication which is unclear to me is what has been mentioned about “diverging laws”. Looks like there was an ambiguous invariant rule and pretty choose one path, GHC.Pretty the other. Reconciliation is unclear to me in this scenario. Something else unclear is how to reconcile the fact TextDetails in GHC.Pretty contains stuff which is performance and GHC-specific. Maybe we should abstract over TextDetails after all, so that we could jack in a TextDetails representation in a Doc. I don’t know if this path has been attempted yet, probably it was. Does anybody have any experience report? 4. Profit? I’m currently (mostly for fun, to quote Edward Kmett “I reserve the right to get bored and do something else which makes money :P :P) trying to tackle 1., but I have seen valiant knights tried this before being killed by the dragon. Oh dear, I guess I will be the next? Last but not least, sorry for hijacking the original spirit of this email (although it’s always perf-related), but throwing my ramblining into those already-packed GHC trac tickets seemed overkill. I have the feeling (not just a feeling) that this has been discussed and explained over and over to new freshmen trying to venture into GHC outlands, so it must be frustrating for you guys to write that down for the 1000+1 time. A big THANK YOU to put up with yet another young apprentice ;) Alfredo On 18 April 2017 at 20:14, Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > > it would be quite helpful if `pretty` > > gained a special-case for the infinite band-width case > > Absolutely +1 this. > > Not "pretty" but similar: > https://github.com/jwaldmann/wl-pprint-text/commit/ > 7843d96db57ab01c0be336a5be0d7bca61902005 > > - J.W. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From migmit at gmail.com Wed Apr 19 07:06:09 2017 From: migmit at gmail.com (MigMit) Date: Wed, 19 Apr 2017 09:06:09 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: <1760B9A6-DBFF-48BD-80AB-7ADAC46908F1@gmail.com> Of course not. If my language needs much tweaking to fit the problem domain, it usually means I chose the wrong language in the first place. If macros a needed to prevent TYPOS, it means the language is doomed. Az iPademről küldve 2017. ápr. 19. dátummal, 8:52 időpontban David McClain írta: > >> On Apr 18, 2017, at 22:05, MigMit wrote: >> >> http://www.offcenterdesigns.net/wp-content/uploads/wp-checkout/images/i-found-the-i-in-team-t-shirt-1344970569.jpg >> >> I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write. >> > > Those first two sentences were a joke, eh? Macros exist to shape the language to suit the problem domain and prevent massive typos and fingers cramping up. > > I played around with Sanitary Macrology, or whatever they are called, in Dylan back in the late 90’s. Frankly, I find them maddening. I much prefer the Common Lisp style of macrology. But read up on macros in Quiennec’s book, “Lisp in Small Pieces”. They exist in a kind of no-man’s land in language stages. There really isn’t any one best kind of macrology. > > Back in OCaml land they used to have a preprocessor that could give you access to the AST’s from a first pass of compiling, and I made liberal use of a custom tree rewriter in order to give my vectorized / overloaded math language NML a better shape than plain OCaml syntax. That is yet another kind of macrology. And potentially just as powerful, if less convenient to use on the fly. > > - DM > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed Apr 19 07:08:34 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 09:08:34 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> Message-ID: <86259d65-11eb-9871-0680-ee0a66664d3b@durchholz.org> Am 18.04.2017 um 18:57 schrieb David McClain: >> I think Lisp-style macros are too powerful. You can get excellent >> results as long as everybody involved knows all the relevant macros >> and their semantics perfectly well, and for one-man teams like >> yourself this can work very well. If you need to work with average >> programmers, this fails. In such an environment, you need to be >> able to read other peoples' code, and if they can define macros, >> you don't really know anymore what's happening. > > Too powerful for whom? Too powerful for teams that include sub-average programmers (by definition, you always have a sub-average one on the team). The issue is that you don't have enough brilliant developers to staff all the projects in the world, so you need technology that gives consistent results, much more than technology that boosts productivity but is inconsistent. > Again, I’m lucky to be master of my own > domain. Exactly. >> Problem with that is that empowering the programmer makes it harder >> to be 100% sure what a given piece of code does. There might be >> macros involved, there might be metaprogramming involved, or some >> kind of multiple dispatch with nonobvious defaulting rules, or a >> gazillion of other things that you have to be aware of. It's not a >> problem if you know your system from the inside out, but it doesn't >> scale well to tasks that need to be done by a team. > > Isn’t that always the case, and always will be the case? Only in dynamic languages that do not give you any guarantees about what the code is *not* going to do. That's exactly what makes Haskell interesting: There cannot be any side effects unless the code has IO in the type signature, which is so awkward that people tend to push it into a small corner of the program. The net effect is that it is far easier to reason about what a program can and cannot do. In the Java/C++/whatever world, unit testing achieves the same, though the imperative nature and generally less well-delimited semantics the effect is far less pervasive. Java stands out a bit since the language semantics has always been nailed down pretty narrowly right off the start, which is a first in the computing world and has been having pervasive effects through all the language culture - Java libraries tend to interoperate much better than anything that I read about the C and C++ world. > Nobody can > be certain how some library or application was written. You might > have some pretty strong hints and hunches, but how can you be sure? > > Seems like the best bet is to treat everything as untrusted black > boxes. Whenever I see one of the Java libraries do something unexpected in what I code, I tend to read the sources. It's usually easy because Java is so dumbed-down and verbose that you can pick up enough hints. The more advanced libraries (Spring) take longer to understand well enough, and some (Hibernate) are so badly coded that it's pretty non-fun, but I tend to get results, mostly because Java is so strict that I can see what's happening. I get into trouble whenever annotations or AOP stuff is involved, or when too much activity is hidden away into data structures that are being executed at a later time. Data types help me pick up on that lead though; I'd fail miserably in a language without static typing because all the hints and hunches are gone, and I have to go by cultural hints and hunches which tend to diverge between projects so I'd be lost. (Actually I'm pretty sure, I tried to get "into" Smalltalk once and it never worked for me.) > Erlang probably offers the best security model against > dependencies. Erlang is good for handling failures that show up. It does nothing for you if the problem is code that's subtly wrong. > If you look at any major element of code in production, it was > probably written in a hurry under near unreasonable demands because > hardware engineering overran their budgets and took some of yours, > and the programmer may or may not have well understood his tools and > language, or even if he did, he might have been daydreaming of being > on the beach with his girlfriend instead of in this meat locker with > the rest of you guys… Actualy it's not the hardware engineers nowadays (we all work on stock hardware anyway). It's the bean counters who are trying to cut down on the budget. > My experience has been that hardware companies produce the most > gawd-awful code you can imagine. Software shops vary… take M$ for > instance - the bane of my existence. Looks like code gets pushed out > the door and they rely on the audience to test it. They used to be that way. Security threats endangered their business model, so they had to change; nowadays, they aren't that different form other large companies anymore. > Apple looks to me > like a room full of really bright young minds, with no adult > supervision. Actually Apple is the most strictly controlled workplace in the industry, as far as I know. > I guess if I could offer any advice to other younger programmers, it > would be to push yourself to become a polyglot to expand your mental > horizons of what is possible, and a historian to understand what went > before you and why, so that you don’t keep repeating the same stupid > mistakes we did. In the modern world, the bean counters found enough tools to control the development process that you don't have much of a choice. If you want to have choice, you now need to become a manager. Which means no programming at all. It takes a lot out of the profession that was attractive in the past decades, but on the other hand it reduces project unpredictability and increases job security. (It's still not perfect, but I doubt it ever can be.) > I could not be a production programmer. I’m definitely too much of a > cowboy and a lone wolf. Teams are anathema to me. I need deep periods > of isolation to think. People who manage to perform in production > coding environments must have very different personalities from me. That has been clear for a long while :-) From jo at durchholz.org Wed Apr 19 07:23:01 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 09:23:01 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Am 19.04.2017 um 06:24 schrieb Richard A. O'Keefe: > Someone wrote: That was me :-) >>>> I think Lisp-style macros are too powerful. > > It's true that higher-order functions can do a lot of the things people used > macros to do, and better. > > However, having said "Lisp-style macros", Lisp is a tree with many branches. > How about Scheme-style macros? I can't tell the difference anymore, I was going through Common Lisp docs at one time and through the Scheme docs at another time and don't remember anymore which did what. I also have to say that I didn't pick up all the details - I was even more averse to macros then than I am today, so I didn't pay too much attention. The general finding, however, was what both were very, very heavy on enabling all kinds of cool and nifty features, but also very, very weak on making it easy to understand existing code. Essentially, each ecosystem with its set of macros, multiple-dispatch conventions, hook systems and whatnow, to the point that it is its own language that you have to learn. That's essentially why I lost interest: None of what I was learning would enable me to actually work in any project, I'd have to add more time to even understand the libraries, let alone contribute. The other realization was that these extension mechanisms could make code non-interoperable, and there was no easy way to find out whether there would be a problem or not. This would be a non-problem for lone-wolf or always-the-same-team we-reinvent-wheels-routinely scenarios, but it's a closed world that an outsider cannot get into without committing 100%. Java does a lot of things badly, but it got this one right. I can easily integrate whatever library I want, and it "just works", there are no linker errors, incompatible memory layouts, and what else is making the reuse external C++ libraries so hard. Nowadays, the first step in any new project is to see what libraries we need. Integration is usually just a configuration line in the build tool (you don't have build tools in Lisp so that's a downside, but the build tools are generally trivial when it comes to library integration; things get, er, "interesting" if you task the build tool with all the other steps in the pipeline up to and including deployment, but there it's that the environments are so diverse that no simple solution is possible). >>>> Problem with that is that empowering the programmer makes it harder to be 100% sure what a given piece of code does. > > This is also true in Haskell. Show me a piece of code golf with Arrows and > LemurCoSprockets and such all over the place and I haven't a clue. Total > bewilderment. Heh, I can subscribe to that. Even finding out what Monad does took me far too long. From jo at durchholz.org Wed Apr 19 07:30:39 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 09:30:39 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: <451774af-befc-197e-9211-ac8b897e0e3f@durchholz.org> Am 19.04.2017 um 08:52 schrieb David McClain: > I played around with Sanitary Macrology, or whatever they are called, Maybe you remember "hygienic macros". Basically, avoid the C preprocessor crap. I don't know what the exact rules were, and I suspect every language community had its own definition of "hygienic" anyway. From jo at durchholz.org Wed Apr 19 07:51:47 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 09:51:47 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <878tmxtn7n.fsf@colimite.fr> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> Message-ID: Am 18.04.2017 um 23:33 schrieb Sergiu Ivanov: > Haskell or OCaml type systems are usually not used for writing such > exact specifications, because they are not expressive enough. I have read statements that Haskell code still tends to "just work as expected and intended", and see that attributed to the type system. Seemed to be related to Haskells expressivity, with the type system pretty much preventing the typical errors that people make. So the sentiment was that it's not the same but close enough to be the same in practice. Though I doubt that that will hold up once you get more proficient in Haskell and start tackling really complicated things - but "simple stuff in Haskell" tends to get you farther than anybody would expect, so it's still a net win. Just impressions though, I never had an opportunity to delve that deeply into Haskell. > Thus, in > general, showing that Haskell or OCaml code typechecks is weaker than > proving that it has a certain property (like not failing). That a code type checks in Haskell still gives you a whole lot of guarantees. Such as "it doesn't have IO in the type signature so there cannot be any side effect deep inside". (Ironically, people instantly started investigating ways to work around that. Still, the sort-of globals you can introduce via the State monad are still better-controlled than the globals in any other language.) (Aside note: I don't know enough about OCaml to talk about its properties, but I do believe that they are much weaker than in Haskell.) > (However, > passing Haskell or OCaml type checks is still stronger than passing Java > type checks.) Yep. >> And I think you can trace that to the need to interface with the real >> world. > > I have the same gut feeling. I think interfacing with the outside world (still not "real" but just bits inside the operating system and on disk) is one major source of unreliability, but not the only one, and not necessarily the primary one. YMMV. From ok at cs.otago.ac.nz Wed Apr 19 09:10:15 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 19 Apr 2017 21:10:15 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> Message-ID: <391297BF-7062-43B0-82C5-4973E00C9957@cs.otago.ac.nz> > On 19/04/2017, at 5:05 PM, MigMit wrote: > > http://www.offcenterdesigns.net/wp-content/uploads/wp-checkout/images/i-found-the-i-in-team-t-shirt-1344970569.jpg > > I think the problem with macros in general is that their semantics is defined purely in terms of code they generate. Not in terms of what that code actually does. As for me, I want to think about the things I need to achieve, not about the code to write. I find this a rather baffling comment. Let's take SRFI-8, for example, which defines the syntax (receive ) which the SRFI defines *semantically* (paraphrased): - the is evaluated - the values are bound to the - the expressions in the are evaluated sequentially - the values of the last expression are the values of the (receive ...) expression. The syntax is *implemented* thus: (define-syntax receive (syntax-rules () ((receive formals expression body ...) (call-with-values (lambda () expression) (lambda formals body ...))))) but the semantics is *defined* by the specification. The whole point of a macro such as this is for the user *NOT* to "think about the code to write". The code that gets generated is of no interest to the ordinary programmer whatsoever. (Reflecting on the subject of this thread, 'receive' is actually pretty close to >>= .) From ok at cs.otago.ac.nz Wed Apr 19 09:42:36 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 19 Apr 2017 21:42:36 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: > On 19/04/2017, at 7:23 PM, Joachim Durchholz wrote: >> However, having said "Lisp-style macros", Lisp is a tree with many branches. >> How about Scheme-style macros? > > I can't tell the difference anymore, MAJOR differences. Lisp macros: run *imperative* *scope-insensitive* macros to do source to source transformation at compilation or interpretation time. Scheme macros: run *declarative* *scope-sensitive* macros to do source to source transformation at compilation or interpretation time. > > The general finding, however, was what both were very, very heavy on enabling all kinds of cool and nifty features, but also very, very weak on making it easy to understand existing code. With respect to Common Lisp, I'm half-way inclined to give you an argument. Macros, used *carefully*, can give massive improvements in readability. Let's face it, one bit of Lisp (APL, SML, OCaml, Haskell) code looks pretty much like another. The way I've seen macros used -- and the way I've used them myself -- makes code MORE understandable, not less. All it takes is documentation. In Scheme, however, I flatly deny that macros in any way make it harder to understand existing code than functions do. > Essentially, each ecosystem with its set of macros, multiple-dispatch conventions, hook systems and whatnow, to the point that it is its own language that you have to learn. And how is this different from each ecosystem having its own set of operators (with the same names but different precedence and semantics) or its own functions (with the same name but different arities and semantics)? This is why Common Lisp has packages and R6RS and later Scheme have modules. Yes, different subsystems can have different vocabularies of macros, just as different modules in Haskell can have different vocabularies of types, operators, and functions. They don't interfere, thanks to the package or module system. > That's essentially why I lost interest: None of what I was learning would enable me to actually work in any project, I'd have to add more time to even understand the libraries, let alone contribute. That *really* doesn't sound one tiny bit different from trying to work on someone else's Java or Haskell code. My own experience with Lisp was writing tens of thousands of lines to fit into hundreds of thousands, and my experience was very different from yours. Macros were *defined* sparingly, *documented* thoroughly, and *used* freely. Result: clarity. > > The other realization was that these extension mechanisms could make code non-interoperable, I fail to see how define-syntax encapsulated in modules could possibly make Scheme code non-interoperable. > and there was no easy way to find out whether there would be a problem or not. Scheme answer: there isn't. OK, in R5RS there _was_ a problem that two files could both try to define the same macro, but that's not different in kind from the problem that two files could try to define the same function. In R6RS and R7RS, the module system catches that. > > > Java does a lot of things badly, but it got this one right. I can easily integrate whatever library I want, and it "just works", there are no linker errors, incompatible memory layouts, and what else is making the reuse external C++ libraries so hard. Fell off chair laughing hysterically. Or was that screaming with remembered pain? I am sick to death of Java code *NOT* "just working". I am particularly unthrilled about Java code that *used* to work ceasing to work. I am also sick of working code that gets thousands of deprecation warnings. I am particularly tired of having to grovel through thousands of pages of bad documentation, to the point where it's often less effort to write my own code. I am *ALSO* sick of trying to match up Java libraries that only build with Ant and Java libraries that only build with Maven. (Yes, I know about just putting .jar files in the right place. I've also heard of the Easter Bunny.) > Nowadays, the first step in any new project is to see what libraries we need. Integration is usually just a configuration line in the build tool (you don't have build tools in Lisp so that's a downside, Wrong. There are build tools for Common Lisp and have been for a long time. I didn't actually know that myself until I saw a student -- who was using Common Lisp without any of us having ever mentioned it to him -- using one. Look, it's really simple. If programmers *WANT* to write readable code and are *ALLOWED TIME* to write readable code, they will. Whatever the language. If they have other priorities or constraints, they won't. Whatever the language. From ok at cs.otago.ac.nz Wed Apr 19 10:20:57 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 19 Apr 2017 22:20:57 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <86259d65-11eb-9871-0680-ee0a66664d3b@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <86259d65-11eb-9871-0680-ee0a66664d3b@durchholz.org> Message-ID: > On 19/04/2017, at 7:08 PM, Joachim Durchholz wrote: >> >> Too powerful for whom? > > Too powerful for teams that include sub-average programmers (by definition, you always have a sub-average one on the team). > > The issue is that you don't have enough brilliant developers to staff all the projects in the world, so you need technology that gives consistent results, much more than technology that boosts productivity but is inconsistent. To keep this relevant to Haskell, Template Haskell is roughly analogous to Lisp macros. It works on syntactically well-formed fragments. It is normally hygienic, like Scheme, but permits quite complex transformations, like Lisp. And macros in Lisp and Scheme have traditionally been used to develop embedded DSLs, which is something Haskell programmers sometimes do. Template Haskell can of course do amazing things that Lisp and Scheme cannot. There are at least two claims here. - using (not developing, just using) macros requires "brilliant developers" - using (not developing, just using) macros "gives inconsistent results". I am willing to concede that *writing* Lisp macros requires particularly good programmers (because the 'implementation language' of Lisp macros has the full power of Lisp) and that *writing* Scheme macros requires particularly good programmers (because the 'implementation language' of Scheme macros *isn't* Scheme but tree-to-tree rewrite rules). In particular, I am not yet competent to write any Scheme macro whose implementation requires recursion, so since I'm a brilliant programmer, people who can do that must be geniuses, eh? It does not follow that *using* macros is any harder than using any special form pre-defined by the language, and as a matter of fact, it isn't. In Scheme, logical conjunction (AND) and disjunction (OR) are in principle defined as macros. That doesn't make them hard to use, error-prone to use, or in any way inconsistent. (And yes, I *have* struggled with macros in UCI Lisp and InterLisp. Modern Lisp is not your grandfather's Lisp any more than modern Scheme is your grandfather's Scheme or modern Fortran your grandfather's Fortran. And yep, there's a Fortran preprocessor, fpp, modelled on cpp but adapted to Fortran. Not standard, but freely available. And it hasn't caused the death of Fortran yet, any more than CPP has killed Haskell.) From jo at durchholz.org Wed Apr 19 12:42:42 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 14:42:42 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: Am 19.04.2017 um 11:42 schrieb Richard A. O'Keefe: > >> The general finding, however, was what both were very, very heavy on enabling all kinds of cool and nifty features, but also very, very weak on making it easy to understand existing code. > > With respect to Common Lisp, I'm half-way inclined to give you an argument. :-) As I said, I don't really know any details anymore. > Macros, used *carefully*, can give massive improvements in readability. Oh, definitely! Actually this applies even to C-style macros, though they're pretty limited what they can do before you start to hit the more obscure preprocessor features. > Let's face it, one bit of Lisp (APL, SML, OCaml, Haskell) code looks pretty > much like another. The way I've seen macros used -- and the way I've used > them myself -- makes code MORE understandable, not less. > > All it takes is documentation. Good documentation. That's where that Smalltalk system I experimented with (Squeak I think) was a bit weak on: It documented everything, but it was pretty thin on preconditions so you had to experiment, and since parameters were passed through layers and layers of code it was really hard to determine what part of the system was supposed to do what. > In Scheme, however, I flatly deny that macros in any way make it harder to > understand existing code than functions do. Fair enough. >> Essentially, each ecosystem with its set of macros, multiple-dispatch conventions, hook systems and whatnow, to the point that it is its own language that you have to learn. > > And how is this different from each ecosystem having its own set of operators (with the same > names but different precedence and semantics) or its own functions (with the same name but > different arities and semantics)? Different functions with different arities are actually that: different. Just consider the arity a part of the name. Different semantics (in the sense of divergence) - now that would be a major API design problem. It's the kind of stuff you see in PHP, but not very much elsewhere. (Operators are just functions with a funny syntax.) However there's a real difference: If the same name is dispatched at runtime, you're in trouble unless you can tell that the interesting parts of the semantics are always the same. Languages with a notion of subtype, or actually any kind of semantic hierarchy between functions allow you to reason about the minimum guaranteed semantics and check that the caller does it right. Any language with subtyping or a way to associate an abstract data type to an interface can do this; I didn't see anything like that in Smalltalk (where subclasses tend to sort-of be subtypes but no guarantees), or in any Lisp variant that I ever investigated, so this kind of thing is hard. Now there's still a huge difference between just type guarantees (C++, Java, OCaml), design by contract (Eiffel), and provable design by contract (I know of no language that does this, though you can approximate that with a sufficiently strong type system). > Yes, different subsystems can have different vocabularies of macros, > just as different modules in Haskell can have different vocabularies > of types, operators, and functions. > They don't interfere, thanks to the package or module system. Ah. I've been thinking that macros were globally applied. >> That's essentially why I lost interest: None of what I was >> learning would enable me to actually work in any project, I'd have >> to add more time to even understand the libraries, let alone >> contribute. > > That *really* doesn't sound one tiny bit different from trying to work on > someone else's Java or Haskell code. It *is* different: Understanding the libraries isn't hard in Java. That's partly because the language is pretty "stupid", though the addition of generics, annotations, and higher-order functions has started changing that. (Unfortunately these things are too important and useful to just leave them out.) > My own experience with Lisp was writing tens of thousands of lines to fit into > hundreds of thousands, and my experience was very different from yours. > Macros were *defined* sparingly, *documented* thoroughly, and *used* freely. > Result: clarity. Yes, I've been assuming that that's what was happening. I still reserve some scepticism about the "documented thoroughly" bit, because you're so far beyond any learning curve that I suspect that your chances of spotting any deficits in macro documentation are pretty slim. (I may be wrong, but I see no way to really validate the thoroughness of macro documentation.) >> The other realization was that these extension mechanisms could make code non-interoperable, > > I fail to see how define-syntax encapsulated in modules could possibly > make Scheme code non-interoperable. Yeah, I was assuming that macros are global. It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running. What can make code non-interoperable even today is those multiple-dispatch mechanisms (which may not exist in Scheme but only in Common Lisp). Multiple dispatch cannot be made modular and consistent ("non-surprising"), and the MD mechanism that I studied went the other route: If the semantics is a problem, throw more mechanisms at it until people can make it work as intended, to the point that you could dynamically hook into the dispatch process itself. It made my toenails curl. >> Java does a lot of things badly, but it got this one right. I can >> easily integrate whatever library I want, and it "just works", there >> are no linker errors, incompatible memory layouts, and what else is >> making the reuse external C++ libraries so hard. > > Fell off chair laughing hysterically. Or was that screaming with remembered > pain? I am sick to death of Java code *NOT* "just working". > I am particularly unthrilled about Java code that *used* to work ceasing to work. > I am also sick of working code that gets thousands of deprecation warnings. Sorry, but that's all hallmarks of bad Java code. > I am particularly tired of having to grovel through thousands of pages of bad > documentation, to the point where it's often less effort to write my own code. Yeah, that used to be a thing. It isn't usually a problem anymore (even Hibernate may have grown up, I hear that the 4.x codebase is far better than the really crummy 3.6 one that I have come to disrespect). > I am *ALSO* sick of trying to match up Java libraries that only build with Ant > and Java libraries that only build with Maven. (Yes, I know about just putting > .jar files in the right place. I've also heard of the Easter Bunny.) Using Ant means you're doing it in a pretty complicated and fragile, outdated way. Putting .jar files in the right place is the most fragile way ever, and leads stright into stone age nightmares; don't ever follow that kind of advice unless you *want* to fail in mysterious ways. Maven would be the way to go, but only if your project is so large that you have a team of build engineers anyway, i.e. with overall workforce of 30+ persons. Smaller teams should stick with Gradle, which uses the same dependency management as Maven but isn't into the kind of bondage&discipline that Maven is. Sadly, there are still shops that don't use Maven or Gradle. For legacy projects I can understand that, but many do it because they don't know better, i.e. there's no competent build engineer on the team. Those teams are doomed to repeat old mistakes, just like people who still think that Lisp macros are global are doomed to misjudge them :-D >> Nowadays, the first step in any new project is to see what libraries we need. Integration is usually just a configuration line in the build tool (you don't have build tools in Lisp so that's a downside, > > Wrong. There are build tools for Common Lisp and have been for a long time. > I didn't actually know that myself until I saw a student -- who was using > Common Lisp without any of us having ever mentioned it to him -- using one. Ah ok, I didn't know that. > Look, it's really simple. > If programmers *WANT* to write readable code > and are *ALLOWED TIME* to write readable code, they will. > Whatever the language. Unless they want to show off how smart they are, and think that writing code that only they can understand is testament to that. This kind of thinking is frowned upon nowadays, but it used to be pretty widespread not too long ago. > If they have other priorities or constraints, they won't. > Whatever the language. Definitely. Even if programmers would and could to do better, external constraints can prevent them from doing so. From dbm at refined-audiometrics.com Wed Apr 19 12:56:27 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Wed, 19 Apr 2017 05:56:27 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: > On Apr 19, 2017, at 05:42, Joachim Durchholz wrote: > > Yeah, I was assuming that macros are global. > It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running. Was Lisp ever a fad? I’m shocked to hear that. Seriously! I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more. - DM -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbm at refined-audiometrics.com Wed Apr 19 13:08:03 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Wed, 19 Apr 2017 06:08:03 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: Around that time, I only first heard about commercial Lisp systems from Franz (VAX), HP (their own minicomputers), and Symbolics. It was around 1988 when I first saw a Lisp Machine, at a defense contractor (SAIC), after they showed me how defense spending under Pres. Reagan was in the exponential knee of increase. But the fad seemed to be hugely focused on VAX/VMS, not Lisp. Over in the commercial realm, the fad seemed to be with TRS-80, Atari, Mac (?), definitely IBM/PC’s, Pascal, then Object Pascal. Even C wasn’t getting much traction, and C++ was just a gleam in the envious C community’s eyes - largely a preprocessor of some sort. Smalltalk was a fascinating curiosity, and only tinkerers were playing with it. - DM > On Apr 19, 2017, at 05:56, David McClain wrote: > > >> On Apr 19, 2017, at 05:42, Joachim Durchholz > wrote: >> >> Yeah, I was assuming that macros are global. >> It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running. > > Was Lisp ever a fad? I’m shocked to hear that. Seriously! > > I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more. > > - DM > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 sivanov at colimite.fr Wed Apr 19 13:13:53 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 19 Apr 2017 15:13:53 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> Message-ID: <8737d4tu9a.fsf@colimite.fr> Thus quoth Joachim Durchholz at 07:51 on Wed, Apr 19 2017: > Am 18.04.2017 um 23:33 schrieb Sergiu Ivanov: > >> Haskell or OCaml type systems are usually not used for writing such >> exact specifications, because they are not expressive enough. > > I have read statements that Haskell code still tends to "just work as > expected and intended", and see that attributed to the type system. [...] > So the sentiment was that it's not the same but close enough to be the > same in practice. Sure, this "close enough" bit is one of the things which make Haskell very attractive. Now, it's not "close enough" for critical systems (satellites, nuclear reactors, etc.), from what I know. > Seemed to be related to Haskells expressivity, with the type system > pretty much preventing the typical errors that people make. I tend to see Haskell's type system as very restrictive and only allowing behaviour which composes well. It's also rich enough to allow specification of quite a wide variety of behaviour. However, there are a couple big "backdoors", like the IO monad. Typechecking gives zero guarantees for functions of type IO (), for example. > Though I doubt that that will hold up once you get more proficient in > Haskell and start tackling really complicated things To me, it really depends on the kind of complicated things. If you manage to explain the thing at the type level, then typechecking may give you pretty strong guarantees. I'm thinking of parsing and concurrency as positive examples and exception handling as a somewhat negative example. > but "simple stuff in Haskell" tends to get you farther than anybody > would expect, so it's still a net win. Absolutely. >> Thus, in general, showing that Haskell or OCaml code typechecks is >> weaker than proving that it has a certain property (like not >> failing). > > That a code type checks in Haskell still gives you a whole lot of > guarantees. Such as "it doesn't have IO in the type signature so there > cannot be any side effect deep inside". Right, of course. > (Ironically, people instantly started investigating ways to work around > that. Still, the sort-of globals you can introduce via the State monad > are still better-controlled than the globals in any other language.) In fact, I believe having pure functions does not so much target removing state as it does making the state _explicit_. Thus, the State monad is not a work-around to purity, it's a way of purely describing state. And then, if the State monad is too lax for one's purposes, one can use Applicative or even define more specific typeclasses. > (Aside note: I don't know enough about OCaml to talk about its > properties, but I do believe that they are much weaker than in Haskell.) That's what I tend to believe as well from looking over people's shoulders. >>> And I think you can trace that to the need to interface with the real >>> world. >> >> I have the same gut feeling. > > I think interfacing with the outside world (still not "real" but just > bits inside the operating system and on disk) is one major source of > unreliability, but not the only one, and not necessarily the primary one. > YMMV. Yes, that unreliability comes with crossing the frontier between theoretical and applied computer sciences (that's an imprecise metaphor :-) ) -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dbm at refined-audiometrics.com Wed Apr 19 13:14:51 2017 From: dbm at refined-audiometrics.com (David McClain) Date: Wed, 19 Apr 2017 06:14:51 -0700 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: <1E312693-0D50-4163-A777-646F52F0D978@refined-audiometrics.com> Ah Yes… I do now remember the “Race for the 5th Generation”, us against Japan. Lisp against Prolog. That was a fad? Maybe in academic circles and the deep bowels of a handful of defense contractors. Meanwhile the rest of us were busily attaching chains of AP Array Processors on the back of VAX machines. Fortran still ruled the day. Nicholas Wirth had just invented Modula-2 to replace Pascal, as bleeding edge compiler technology. Wow, what memories you sparked... - DM > On Apr 19, 2017, at 06:08, David McClain wrote: > > Around that time, I only first heard about commercial Lisp systems from Franz (VAX), HP (their own minicomputers), and Symbolics. It was around 1988 when I first saw a Lisp Machine, at a defense contractor (SAIC), after they showed me how defense spending under Pres. Reagan was in the exponential knee of increase. But the fad seemed to be hugely focused on VAX/VMS, not Lisp. > > Over in the commercial realm, the fad seemed to be with TRS-80, Atari, Mac (?), definitely IBM/PC’s, Pascal, then Object Pascal. Even C wasn’t getting much traction, and C++ was just a gleam in the envious C community’s eyes - largely a preprocessor of some sort. Smalltalk was a fascinating curiosity, and only tinkerers were playing with it. > > - DM > > >> On Apr 19, 2017, at 05:56, David McClain > wrote: >> >> >>> On Apr 19, 2017, at 05:42, Joachim Durchholz > wrote: >>> >>> Yeah, I was assuming that macros are global. >>> It's very old Lisp experience from the days when Common Lisp and Scheme were new fads, when Lisp machines were still a thing, and had to be rebooted on a daily basis to keep them running. >> >> Was Lisp ever a fad? I’m shocked to hear that. Seriously! >> >> I only got into Lisp after several years of mild nagging by one of my former employees, who studied Lisp and Proof Systems for his graduate CS Degree from U.Oregon, sometime back in the early 80’s, late 70’s. Turns out everything he said was true, and more. >> >> - DM >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed Apr 19 13:52:53 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 15:52:53 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: Am 19.04.2017 um 14:56 schrieb David McClain: > >> On Apr 19, 2017, at 05:42, Joachim Durchholz > > wrote: >> >> Yeah, I was assuming that macros are global. >> It's very old Lisp experience from the days when Common Lisp and >> Scheme were new fads, when Lisp machines were still a thing, and had >> to be rebooted on a daily basis to keep them running. > > Was Lisp ever a fad? I’m shocked to hear that. Seriously! Common Lisp and Scheme were, in their first years. They both managed to transition from "fad" to "production-ready" AFAICT, probably after a stabilization period (I dimly recall having read versioned standardization documents). Lisp as such... probably. Whenever people with enough raw horsepower to use Lisp in practice met people who didn't, because then it would be a fad from the latter ones. Which pretty much meant everybody who didn't have access to abundant corporate-sponsored or state-sponsored hardware. From jo at durchholz.org Wed Apr 19 13:58:39 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 15:58:39 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <8737d4tu9a.fsf@colimite.fr> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> Message-ID: <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov: > >> Seemed to be related to Haskells expressivity, with the type system >> pretty much preventing the typical errors that people make. > > I tend to see Haskell's type system as very restrictive and only > allowing behaviour which composes well. From a library writer's and library user's perspective, that would actually be a Good Thing. > However, there are a couple big "backdoors", like the IO monad. Well, it's so awkward that people don't *want* to use it. > Typechecking gives zero guarantees for functions of type IO (), for > example. That doesn't match what I hear from elsewhere. I don't know what is the cause for that difference though. >> Though I doubt that that will hold up once you get more proficient in >> Haskell and start tackling really complicated things > > To me, it really depends on the kind of complicated things. If you > manage to explain the thing at the type level, then typechecking may > give you pretty strong guarantees. I'm thinking of parsing and > concurrency as positive examples and exception handling as a somewhat > negative example. That matches what I heard :-) >> (Ironically, people instantly started investigating ways to work around >> that. Still, the sort-of globals you can introduce via the State monad >> are still better-controlled than the globals in any other language.) > > In fact, I believe having pure functions does not so much target > removing state as it does making the state _explicit_. Except State tends to make state implicit again, except for the fact that there *is* state (which might be actually enough, I don't have enough insight for any judgemental statements on the issue). > Thus, the State > monad is not a work-around to purity, it's a way of purely describing > state. True. >>>> And I think you can trace that to the need to interface with the real >>>> world. >>> >>> I have the same gut feeling. >> >> I think interfacing with the outside world (still not "real" but just >> bits inside the operating system and on disk) is one major source of >> unreliability, but not the only one, and not necessarily the primary one. >> YMMV. > > Yes, that unreliability comes with crossing the frontier between > theoretical and applied computer sciences (that's an imprecise > metaphor :-) ) :-D From monkleyon at gmail.com Wed Apr 19 14:22:58 2017 From: monkleyon at gmail.com (MarLinn) Date: Wed, 19 Apr 2017 16:22:58 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <1E312693-0D50-4163-A777-646F52F0D978@refined-audiometrics.com> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> <1E312693-0D50-4163-A777-646F52F0D978@refined-audiometrics.com> Message-ID: <32664d7f-1d09-b801-b020-5cc12ab4cba2@gmail.com> On 2017-04-19 15:14, David McClain wrote: > Ah Yes… I do now remember the “Race for the 5th Generation”, us > against Japan. Lisp against Prolog. That was a fad? I have read Haskell being described as "what M-expressions where supposed to be". Granted, it's not compiled down to S-expressions – but to the comparably simple Core, so the analogy has a bit more substance than the visible sentimentality. At the same time, in a way, our type system is a kind of Logic Programming language. We state facts about our programs as well as rules how to derive new facts, and the type checker tries to prove our system to be either inconsistent or incomplete. The syntax is not as simple as Prolog's, but that's partly due to the domain, partly because our type language is a grown one. In other words: After their feud, Lisp and Prolog must have made up and spent a hot few nights together, probably in a seedy conference room in Portland. Haskell is one of the results. Is it a perfect blend of its parents' strengths? Ah, hell no. But no child ever is. Which leads me to the question: Why the hell isn't there a sitcom about programing languages yet? Cheers, MarLinn From monkleyon at gmail.com Wed Apr 19 15:10:20 2017 From: monkleyon at gmail.com (MarLinn) Date: Wed, 19 Apr 2017 17:10:20 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> Message-ID: <14dbb421-f2b6-ef96-73f0-47933d8f34ca@gmail.com> On 2017-04-19 15:58, Joachim Durchholz wrote: > Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov: >> However, there are a couple big "backdoors", like the IO monad. > > Well, it's so awkward that people don't *want* to use it. That's partly because IO isn't very well defined, and therefore used as a catch-all. It's like the "other mail" folder, a stuff-drawer in the kitchen or that one room in the basement: random things tend to accumulate and rot in there because they don't have a better place. One of the worst offenders from my perspective is (non-)determinism. Randomness can be seen as non-deterministic, but it doesn't need IO. At the same time, many things that are in IO are practically not less deterministic than pure functions with _|_ – once you have a good enough model. In other words, these things could be separated. It needs work, to model the real world, to go through all the stuff that's in that black box, to convince people to not use IO if they don't need to, to change the systems to even allow "alternative IOs"… so it's nothing that'll change soon. But my point is: The type system can only help you if there are precise definitions and rules, but IO is the "here be dragons" on our maps of the computational world – for one, because the open work I mentioned is one of the ways to explore that boundary between theoretical and applied computer sciences. IO is the elephant in the room of type-supported hopes of correctness. But then I agree with Joachim: it's also right in the center of the room where everyone can see, acknowledge, and avoid it. Cheers, MarLinn From sivanov at colimite.fr Wed Apr 19 15:56:19 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 19 Apr 2017 17:56:19 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> Message-ID: <871ssotmqk.fsf@colimite.fr> Thus quoth Joachim Durchholz at 13:58 on Wed, Apr 19 2017: > Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov: >> >> However, there are a couple big "backdoors", like the IO monad. > > Well, it's so awkward that people don't *want* to use it. Interesting point of view, I've never thought of the relative awkwardness of IO as of an educational measure. >> Typechecking gives zero guarantees for functions of type IO (), for >> example. > > That doesn't match what I hear from elsewhere. > I don't know what is the cause for that difference though. I'm probably shouting my "zero" too loudly. I wanted to say that, when the typechecker sees a function of type IO (), it only knows that it _may_ have side effects, but it cannot verify that these effects compose correctly with the effects coming from other functions in the IO monad. Of course, the return type IO () still gives a lot of information (e.g., it says the function is only useful for its side effects) and the type system will ensure that any computation actually using this function must be declared as (potentially) having side effects. Yet, you have no guarantees that such effects are composed correctly. >> In fact, I believe having pure functions does not so much target >> removing state as it does making the state _explicit_. > > Except State tends to make state implicit again, except for the fact > that there *is* state (which might be actually enough, I don't have > enough insight for any judgemental statements on the issue). Well, a typical definition of State is parameterised in the type of the state, so you know what it is. Sure, a typical definition of State does not let you know whether and how the state was modified, but if one wants that information, one can "just" define a custom "StateLog" monad, for example, or even use Applicative to statically "record" the effects on the state (I hear that's one use of Applicative). -- 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 Apr 19 16:11:19 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Wed, 19 Apr 2017 18:11:19 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <14dbb421-f2b6-ef96-73f0-47933d8f34ca@gmail.com> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> <14dbb421-f2b6-ef96-73f0-47933d8f34ca@gmail.com> Message-ID: <87zifcs7h4.fsf@colimite.fr> Thus quoth MarLinn at 15:10 on Wed, Apr 19 2017: > On 2017-04-19 15:58, Joachim Durchholz wrote: >> Am 19.04.2017 um 15:13 schrieb Sergiu Ivanov: >>> However, there are a couple big "backdoors", like the IO monad. >> >> Well, it's so awkward that people don't *want* to use it. > > That's partly because IO isn't very well defined, and therefore used as > a catch-all. It's like the "other mail" folder, a stuff-drawer in the > kitchen or that one room in the basement: random things tend to > accumulate and rot in there because they don't have a better place. Exactly. > One of the worst offenders from my perspective is (non-)determinism. Oh, right, interesting! > Randomness can be seen as non-deterministic, but it doesn't need IO. At > the same time, many things that are in IO are practically not less > deterministic than pure functions with _|_ – once you have a good enough > model. In other words, these things could be separated. It needs work, > to model the real world, to go through all the stuff that's in that > black box, to convince people to not use IO if they don't need to, to > change the systems to even allow "alternative IOs"… so it's nothing > that'll change soon. I tend to see monads like STM (software transactional memory) and ST (strict state threads) as a kind of "add structure to IO" effort. Also, there's Eff (algebraic effects), but I still haven't had the time to read the seminal work beyond introduction: http://www.eff-lang.org/ > IO is the elephant in the room of type-supported hopes of correctness. I like this image :-) -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jo at durchholz.org Wed Apr 19 18:39:06 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 Apr 2017 20:39:06 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <871ssotmqk.fsf@colimite.fr> References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> <871ssotmqk.fsf@colimite.fr> Message-ID: Am 19.04.2017 um 17:56 schrieb Sergiu Ivanov: > > I wanted to say that, when the typechecker sees a function of type > IO (), it only knows that it _may_ have side effects, but it cannot > verify that these effects compose correctly with the effects coming from > other functions in the IO monad. Ah right. Even Haskell's type system is not able to classify and characterize side effects properly. I don't think that that's a defect in the type system though; I've had my own experiences with trying to do that (based on design by contract, if anybody is interested), and I found it's pretty much uncontrollable unless you go for temporal logic, which is so hard to reason about that I do not think it's going to be useful to most programmers. (Temporal logic exists in several variants, so maybe I was just looking at the wrong one.) >>> In fact, I believe having pure functions does not so much target >>> removing state as it does making the state _explicit_. >> >> Except State tends to make state implicit again, except for the fact >> that there *is* state (which might be actually enough, I don't have >> enough insight for any judgemental statements on the issue). > > Well, a typical definition of State is parameterised in the type of the > state, so you know what it is. > > Sure, a typical definition of State does not let you know whether and > how the state was modified, but if one wants that information, one can > "just" define a custom "StateLog" monad, for example, or even use > Applicative to statically "record" the effects on the state (I hear > that's one use of Applicative). Thanks, that's going to guide me in future attempts at understanding all the strange and wondrous (and sometimes awesome) things you can find in the Haskell ecology. Regards, Jo From doug at cs.dartmouth.edu Wed Apr 19 20:25:27 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 19 Apr 2017 16:25:27 -0400 Subject: [Haskell-cafe] Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions Message-ID: <201704192025.v3JKPRPw026834@coolidge.cs.Dartmouth.EDU> > It's just helping clean up a bit words that doesn't have much meaning. > Currently GHCi in GHC 8 is supporting this, so you could write both: > > x = 10 > x <- return 10 > > Which is great! I trust that "x = 10" above does NOT t mean the same as "let x = 10". If it did, then it wouldn't mean what it does in Haskell. Then code tried successfully in GHCI could fail in GHC. Compare this GHCI session > let x = 10 > :t x x :: Num a => a > x + 0.0 10.0 to this, in which x = 10 has its Haskell meaning > :! cat test.hs x = 10 > :load test.hs > :t x x :: Integer > x + 0.0 No instance for (Fractional Integer) arising from the literal ‘0.0’. Doug From allbery.b at gmail.com Wed Apr 19 20:29:55 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 19 Apr 2017 16:29:55 -0400 Subject: [Haskell-cafe] Haskell 2020: 'let' to be optional and with wider scope of visibility, like other Haskell functions In-Reply-To: <201704192025.v3JKPRPw026834@coolidge.cs.Dartmouth.EDU> References: <201704192025.v3JKPRPw026834@coolidge.cs.Dartmouth.EDU> Message-ID: On Wed, Apr 19, 2017 at 4:25 PM, Doug McIlroy wrote: > I trust that "x = 10" above does NOT t mean the same as "let x = 10". > If it did, then it wouldn't mean what it does in Haskell. > Then code tried successfully in GHCI could fail in GHC. > > Compare this GHCI session > > let x = 10 > > :t x > x :: Num a => a > > x + 0.0 > 10.0 > to this, in which x = 10 has its Haskell meaning > > :! cat test.hs > x = 10 > > :load test.hs > > :t x > x :: Integer > > x + 0.0 > No instance for (Fractional Integer) arising from the literal > ‘0.0’. > That's got nothing to do with 'let', it's about ghci having the monomorphism restriction turned off by default. (try ":showi language") -- 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 ok at cs.otago.ac.nz Thu Apr 20 00:51:40 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 20 Apr 2017 12:51:40 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> Message-ID: <5C24B0B7-49A7-43FD-A98C-5425E9A3F8A9@cs.otago.ac.nz> > On 20/04/2017, at 1:52 AM, Joachim Durchholz wrote: > > Common Lisp and Scheme were, in their first years. > They both managed to transition from "fad" to "production-ready" AFAICT, probably after a stabilization period (I dimly recall having read versioned standardization documents). > > Lisp as such... probably. Whenever people with enough raw horsepower to use Lisp in practice met people who didn't, because then it would be a fad from the latter ones. Which pretty much meant everybody who didn't have access to abundant corporate-sponsored or state-sponsored hardware. Truly strange. You really did not need "horsepower" to use Lisp in practice. There were several Lisp implementations for CP/M, and CP/M machines were hardly "raw horsepower" by any stretch of the imagination. OK, a University lab of cheap 8086 PCs does technically count as state-sponsored, but hardly "raw horsepower". I suppose the price of TI PC-Scheme (USD95) would have put it out of reach of hobbyists /sarc. (I would definitely call PC-Scheme "production-ready" for its day.) The problem with Lisp was never garbage collection, or speed, or availability. It was *unfamiliarity*. As soon as things like TCL and Python became available, they were adopted gladly by many programmers, despite being less efficient than typical Lisps. To this day, Python forcibly discourages recursive programming by enforcing a small stack depth, even on machines with abundant memory, thus ensuring that Python keeps its reassuringly familiar imperative style. (Yep, ran into this the hard way, trying to implement a dynamic programming algorithm in Python.) I'm very sad to see FUD about Lisp surviving this long. Much the same FUD was spread about Prolog, despite there being decent Prolog implementations for cheap 16-bit machines. It is *bitterly* ironic to see Java adopted by people critical of Lisp. It just goes to show that the old hardware saying, "you can make a brick fly if you strap on a big enough jet engine" is true of programming languages. From twhitehead at gmail.com Thu Apr 20 02:11:42 2017 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed, 19 Apr 2017 22:11:42 -0400 Subject: [Haskell-cafe] Problem with tuple with one element constrained In-Reply-To: References: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> Message-ID: <03821390-0955-1f9e-c197-7fa8f200afbb@gmail.com> On Tue, Apr 18, 2017, 16:02 Joshua Grosso > wrote: /If/ I'm understanding correctly, GHCI's complaining about the fact that `return 2` requires it to create an instance of a `Monad`, but it doesn't know which `Monad` instance it should use... Does `let (x, y) = (1, return 2) :: (Int, Maybe Int)` work (where you can replace `Maybe` with any other monad)? Hi Joshua, Thanks for the input. You are correct that if I choose a particular Monad instance GHCi accepts the code. I believe it should be able to do the assignment without choosing one though. It is, for example, okay with let y = return 2. I'm thinking Sergiu is onto something about this having to do with special GHCi handling. Thanks! -Tyson -------------- next part -------------- An HTML attachment was scrubbed... URL: From twhitehead at gmail.com Thu Apr 20 02:19:15 2017 From: twhitehead at gmail.com (Tyson Whitehead) Date: Wed, 19 Apr 2017 22:19:15 -0400 Subject: [Haskell-cafe] Problem with tuple with one element constrained In-Reply-To: <87a87dtopq.fsf@colimite.fr> References: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> <87a87dtopq.fsf@colimite.fr> Message-ID: <7ad3a69e-7cd3-9abd-b7be-86329e5db249@gmail.com> Thanks Sergiu, I know there was some defaulting, but didn't think much of it beyond that. Special GHCi handling makes sense. Maybe I'll open a ticket just in case this is an unintended effect. Interesting observation about loading it from a file via typing it in. My code is actually a test case for use with the doctest package that I was just running manually to work out. I'm not sure if it does the equivalent of loading it from a file or not. Ultimately I wound up doing the binding via a case statement instead of let. It seems GHCi is okay with that. Cheers! -Tyon On Tue, Apr 18, 2017, 17:01 Sergiu Ivanov > wrote: GHCi handles polymorphic types of interactive expressions somewhat differently from the polymorphic types of expressions loaded from files. (I'd be happy if someone could reproduce the explanation which I saw a couple times but which I cannot find any more.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Thu Apr 20 08:21:35 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 20 Apr 2017 10:21:35 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <5C24B0B7-49A7-43FD-A98C-5425E9A3F8A9@cs.otago.ac.nz> References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> <5C24B0B7-49A7-43FD-A98C-5425E9A3F8A9@cs.otago.ac.nz> Message-ID: Am 20.04.2017 um 02:51 schrieb Richard A. O'Keefe: > >> On 20/04/2017, at 1:52 AM, Joachim Durchholz wrote: >> >> Common Lisp and Scheme were, in their first years. >> They both managed to transition from "fad" to "production-ready" AFAICT, probably after a stabilization period (I dimly recall having read versioned standardization documents). >> >> Lisp as such... probably. Whenever people with enough raw horsepower to use Lisp in practice met people who didn't, because then it would be a fad from the latter ones. Which pretty much meant everybody who didn't have access to abundant corporate-sponsored or state-sponsored hardware. > > Truly strange. You really did not need "horsepower" to use Lisp in practice. > There were several Lisp implementations for CP/M, and CP/M machines > were hardly "raw horsepower" by any stretch of the imagination. If that had been universally true, nobody would have bothered to think about, let alone buy those Lisp machines. > OK, a University lab of cheap 8086 PCs does technically count as > state-sponsored, but hardly "raw horsepower". I suppose the price > of TI PC-Scheme (USD95) would have put it out of reach of hobbyists > /sarc. Nah, it simply wasn't available unless you knew it existed. (I certainly didn't know.) > The problem with Lisp was never garbage collection, or speed, or availability. > It was *unfamiliarity*. Nope. Actually, the first actual project I ever built was a (primitive) Lisp interpreter. I would have liked to work with it, but I lost access to the machine (that was in the pre-PC era), plus I didn't know enough to devise a way to integrate it into the surrounding operating system. > As soon as things like TCL and Python became available, > they were adopted gladly by many programmers, despite being less efficient than > typical Lisps. I don't know what motivated anybody to ever use TCL. It's an abomination. Python doesn't count, it wasn't even thought about in the IBM PC days. > I'm very sad to see FUD about Lisp surviving this long. Enough of this kind of slur. I'm not adhering to "FUD", I am reporting personal experience. I have been refraining from responding in kind, because some unfriendly things could be said about your mindset. > Much the same FUD was spread about Prolog, despite there being decent > Prolog implementations for cheap 16-bit machines. Sorry, Prolog simply didn't work. As soon as you tried to do anything that was prone to combinatoric explosion, you had to resort to cuts and essentially revert to a uselessly complicated imperative programming model just to keep that under control. I am well aware that Prolog can be an excellent tool, but only for tasks that it fits. Unfortunately, most paid jobs are too simple to actually need Prolog, and of the complicated ones, only a small fraction can even be adequately captured using Horn clauses. I'm not talking from theory here. I tried to adopt a simple distance calculation in a hexagonal lattice with it. I realized that to make it reversible I'd need have it do the inverse of finding the distance of two known points, namely find the list of distance-N points from a given centerpoint, which I liked because I needed that anyway; however, it turned out to be O(N^6) because it would explore ALL the paths inside the radius-N circle, and that was useless. Making it avoid that involved cuts, which would make the ruleset non-reversible, and hence non-composable under standard Prolog semantics (you'd be unable to add rules that would e.g. exempt blockaded points from the pathfinding). In other words, the resulting code would be an imperative program, shoehorned into a Prolog ruleset, giving me the worst of both worlds. No I'm fully aware that I might be able to find better solutions now, some three decades of experience later. But I don't think that Prolog's approach will scale to teams of average programmers, and I doubt you can find enough programmers to staff any project worth doing, unless your tasks are a natural fit to Prolog. (Of course there are people who do non-Horn-clause-ish things with Prolog, and successfully so. If all you have a hammer, then every problem starts looking like a nail.) > It is *bitterly* ironic to see Java adopted by people critical of Lisp. I was forced to. I'd really love to live off Haskell programming. I'd even be happy doing Scala - it's far from perfect, but it integrates well with Java libraries, and that's a huge bonus that people without experience in a JVM language seem to be unable to appreciate; I suspect the Blub paradox at work here. > It just goes to show that the old hardware saying, "you can make a > brick fly if you strap on a big enough jet engine" is true of programming languages. Exactly. From sivanov at colimite.fr Thu Apr 20 10:03:47 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Thu, 20 Apr 2017 12:03:47 +0200 Subject: [Haskell-cafe] Problem with tuple with one element constrained In-Reply-To: <7ad3a69e-7cd3-9abd-b7be-86329e5db249@gmail.com> References: <1659089.NTXnnMbVEO@whitehead.beowulf.uwo.ca> <87a87dtopq.fsf@colimite.fr> <7ad3a69e-7cd3-9abd-b7be-86329e5db249@gmail.com> Message-ID: <87wpafs8e4.fsf@colimite.fr> Thus quoth Tyson Whitehead at 02:19 on Thu, Apr 20 2017: > > Interesting observation about loading it from a file via typing it in. Initially I suspected the culprit was the monomorphism restriction being turned off by default (:showi language in GHCi, (great thanks to Brandon Allbery who mentioned this command on another thread)), but I don't really see a difference when I turn it off. > My code is actually a test case for use with the doctest package that > I was just running manually to work out. I'm not sure if it does the > equivalent of loading it from a file or not. Oh, I see. > Ultimately I wound up doing the binding via a case statement instead > of let. It seems GHCi is okay with that. That's kind of funny. Seems somewhat inconsistent to my eye. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From moritz.angermann at gmail.com Thu Apr 20 10:15:43 2017 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Thu, 20 Apr 2017 18:15:43 +0800 Subject: [Haskell-cafe] GHC cross compilation survey Message-ID: Dear friends, as some of you might have noticed, together with obsidian.systems, I’m trying to make cross compiling GHC a bit easier. To that extend, I’d like to invite you to fill out a short survey[1], so we understand the needs of the community better. Please follow the attached link and fill out the survey! Cheers, Moritz [1]: https://medium.com/@zw3rk/hello-world-a-cross-compilation-survey-890cb95029d7 From sivanov at colimite.fr Thu Apr 20 10:43:20 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Thu, 20 Apr 2017 12:43:20 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <9dc8e85d-7357-0d49-62aa-6402a6dc6713@durchholz.org> <5fab4a30-7c30-ad14-470f-19b669576ab4@durchholz.org> <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <878tmxtn7n.fsf@colimite.fr> <8737d4tu9a.fsf@colimite.fr> <486f4488-28a5-1638-a44d-c11550c38afd@durchholz.org> <871ssotmqk.fsf@colimite.fr> Message-ID: <87vapzs6k7.fsf@colimite.fr> Thus quoth Joachim Durchholz at 18:39 on Wed, Apr 19 2017: > Am 19.04.2017 um 17:56 schrieb Sergiu Ivanov: >> >> I wanted to say that, when the typechecker sees a function of type >> IO (), it only knows that it _may_ have side effects, but it cannot >> verify that these effects compose correctly with the effects coming from >> other functions in the IO monad. > > Ah right. > Even Haskell's type system is not able to classify and characterize side > effects properly. The language Eff seems to be built around an algebraic characterisation (according to the author, I haven't yet had the time to check) and handling of effects: http://www.eff-lang.org/ According to the page, the proposed formalism allows doing elegantly what in Haskell is typically done with monad transformers. I actually started thinking about porting the algebraic handling of effects to Haskell, which may be possible since its type system seems to be expressive enough, but my time is quite limited these days. > I don't think that that's a defect in the type system though; I've had > my own experiences with trying to do that (based on design by contract, > if anybody is interested), and I found it's pretty much uncontrollable > unless you go for temporal logic, which is so hard to reason about that > I do not think it's going to be useful to most programmers. (Temporal > logic exists in several variants, so maybe I was just looking at the > wrong one.) Temporal logics kind of require guys with PhDs in your team :-) From what I know, the usual approach is designing (or adapting) a temporal logic for your specific task, since general properties are often undecidable. Your experience of handling effects seems interesting to me. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From fuuzetsu at fuuzetsu.co.uk Thu Apr 20 18:52:36 2017 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 20 Apr 2017 19:52:36 +0100 Subject: [Haskell-cafe] Why does `mzip /= liftM2 (,)` Message-ID: Hi, Today after half a decade I have found `MonadZip` in `base`. The laws state: ``` liftM (f *** g) (mzip ma mb) = mzip (liftM f ma) (liftM g mb) liftM (const ()) ma = liftM (const ()) mb ==> munzip (mzip ma mb) = (ma, mb) ``` The question is why does ``` mzip /= liftM2 (,) ``` in plain words. Notably we can see lack of IO instance which I'm guessing has something to do asynchronous exceptions but I'm probably wrong…. Rather than investigating for next 30 minutes, I thought I'd just sample existing knowledge (that I could not find out from Google). In what circumstances can we not replace `liftM2 (,)` with `mzip`? -- Mateusz K. From monkleyon at gmail.com Thu Apr 20 19:19:37 2017 From: monkleyon at gmail.com (MarLinn) Date: Thu, 20 Apr 2017 21:19:37 +0200 Subject: [Haskell-cafe] Why does `mzip /= liftM2 (,)` In-Reply-To: References: Message-ID: > The question is why does > > ``` > mzip /= liftM2 (,) > > ``` I don't have any evidence, but my gut feeling is that indeed mzip == liftM2 (,) == liftA2 (,), but that MonadZip just predates many advances, and that it's not used often enough to warrant changing. Especially because changing stuff in base comes with huge costs and long debates. Today I would expect something similar to look somewhat more like this: ``` class Applicative f => Unzippative f where unzipF :: f (a,b) => (f a, f b) ``` I personally can't remember a single time that function would have come in handy, so I'm happy with Applicative. And I'm projecting that experience onto others and drawing the conclusion of "Meh.". But if you find out more after > investigating for next 30 minutes I'd be interested to hear. ;) Cheers, MarLinn From tanuki at gmail.com Thu Apr 20 19:56:52 2017 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Thu, 20 Apr 2017 12:56:52 -0700 Subject: [Haskell-cafe] Why does `mzip /= liftM2 (,)` In-Reply-To: References: Message-ID: What about: bisequence :: (Functor f, Bifunctor g) => f (g a b) -> g (f a) (f b) On Apr 20, 2017 12:21 PM, "MarLinn" wrote: > > The question is why does >> >> ``` >> mzip /= liftM2 (,) >> >> ``` >> > > I don't have any evidence, but my gut feeling is that indeed mzip == > liftM2 (,) == liftA2 (,), but that MonadZip just predates many advances, > and that it's not used often enough to warrant changing. Especially because > changing stuff in base comes with huge costs and long debates. > > Today I would expect something similar to look somewhat more like this: > > ``` > class Applicative f => Unzippative f where > unzipF :: f (a,b) => (f a, f b) > ``` > > I personally can't remember a single time that function would have come in > handy, so I'm happy with Applicative. And I'm projecting that experience > onto others and drawing the conclusion of "Meh.". > > But if you find out more after > >> investigating for next 30 minutes >> > > I'd be interested to hear. ;) > > Cheers, > MarLinn > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 fuuzetsu at fuuzetsu.co.uk Thu Apr 20 20:07:28 2017 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Thu, 20 Apr 2017 21:07:28 +0100 Subject: [Haskell-cafe] Why does `mzip /= liftM2 (,)` In-Reply-To: References: Message-ID: <06e64124-be44-8a5e-d55a-94d85194a8b1@fuuzetsu.co.uk> On 04/20/2017 08:19 PM, MarLinn wrote: > >> The question is why does >> >> ``` >> mzip /= liftM2 (,) >> >> ``` > > I don't have any evidence, but my gut feeling is that indeed mzip == > liftM2 (,) == liftA2 (,), but that MonadZip just predates many advances, > and that it's not used often enough to warrant changing. Especially > because changing stuff in base comes with huge costs and long debates. Normally I would agree but in case of adding instances, there are no real costs or long debates. Indeed to add a lawful instance you could just send a diff to GHC and see it in next version. In my experience there are only arguments where there are multiple possible "reasonable" instances &c. Hence my question in this case. Even if it was legacy, IO was around in 2011 and there seems to be no reason why it wouldn't have been one of the default instances. > Today I would expect something similar to look somewhat more like this: > > ``` > class Applicative f => Unzippative f where > unzipF :: f (a,b) => (f a, f b) > ``` > > I personally can't remember a single time that function would have come > in handy, so I'm happy with Applicative. And I'm projecting that > experience onto others and drawing the conclusion of "Meh.". > I think we have a bunch across projects. > But if you find out more after >> investigating for next 30 minutes > > I'd be interested to hear. ;) Me too! Maybe on weekend if there are no good replies. > Cheers, > MarLinn > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Mateusz K. From olshanskydr at gmail.com Thu Apr 20 21:16:21 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Fri, 21 Apr 2017 00:16:21 +0300 Subject: [Haskell-cafe] Why does `mzip /= liftM2 (,)` In-Reply-To: <06e64124-be44-8a5e-d55a-94d85194a8b1@fuuzetsu.co.uk> References: <06e64124-be44-8a5e-d55a-94d85194a8b1@fuuzetsu.co.uk> Message-ID: Instances for MonadZip not always defined as "liftM2 (,)". Compare: > liftM2 (,) (Alt [1..2]) (Alt ("foo")) Alt {getAlt = [(1,'f'),(1,'o'),(1,'o'),(2,'f'),(2,'o'),(2,'o')]} > mzip (Alt [1..2]) (Alt ("foo")) Alt {getAlt = [(1,'f'),(2,'o')]} 2017-04-20 23:07 GMT+03:00 Mateusz Kowalczyk : > On 04/20/2017 08:19 PM, MarLinn wrote: > > > >> The question is why does > >> > >> ``` > >> mzip /= liftM2 (,) > >> > >> ``` > > > > I don't have any evidence, but my gut feeling is that indeed mzip == > > liftM2 (,) == liftA2 (,), but that MonadZip just predates many advances, > > and that it's not used often enough to warrant changing. Especially > > because changing stuff in base comes with huge costs and long debates. > > Normally I would agree but in case of adding instances, there are no > real costs or long debates. Indeed to add a lawful instance you could > just send a diff to GHC and see it in next version. In my experience > there are only arguments where there are multiple possible "reasonable" > instances &c. Hence my question in this case. > > Even if it was legacy, IO was around in 2011 and there seems to be no > reason why it wouldn't have been one of the default instances. > > > Today I would expect something similar to look somewhat more like this: > > > > ``` > > class Applicative f => Unzippative f where > > unzipF :: f (a,b) => (f a, f b) > > ``` > > > > I personally can't remember a single time that function would have come > > in handy, so I'm happy with Applicative. And I'm projecting that > > experience onto others and drawing the conclusion of "Meh.". > > > > I think we have a bunch across projects. > > > But if you find out more after > >> investigating for next 30 minutes > > > > I'd be interested to hear. ;) > > Me too! Maybe on weekend if there are no good replies. > > > Cheers, > > MarLinn > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ok at cs.otago.ac.nz Fri Apr 21 01:58:57 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 21 Apr 2017 13:58:57 +1200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: References: <5d9f4d48-45da-e254-12e7-8ee3d63f0eaa@durchholz.org> <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> <5C24B0B7-49A7-43FD-A98C-5425E9A3F8A9@cs.otago.ac.nz> Message-ID: <952AA38E-2AA0-40D7-8416-EA32683EA290@cs.otago.ac.nz> > On 20/04/2017, at 8:21 PM, Joachim Durchholz wrote: >> >> Truly strange. You really did not need "horsepower" to use Lisp in practice. >> There were several Lisp implementations for CP/M, and CP/M machines >> were hardly "raw horsepower" by any stretch of the imagination. > > If that had been universally true, nobody would have bothered to think about, let alone buy those Lisp machines. You seem to be confusing the horsepower required to run *LISP* with the horsepower required to run *an IDE*. I never used an MIT-family Lisp machine, but I spent a couple of years using Xerox Lisp machines. Those machines had 16-bit (yes, 16-bit) memory buses (so to fetch one tag+pointer "word" of memory took three memory cycles: check page table, load half word, load other half), and into 4 MB of memory fitted - memory management (Lisp) - device drivers (Lisp) - network stack (Lisp) - (networked) file system (Lisp) - bit mapped graphics (Lisp; later models added colour) - structure editor (Lisp) - WYSIWIG text editor with 16-bit character set (Lisp) - compiler (Lisp) - automatic error correction DWIM (Lisp) - interactive cross reference MasterScope (Lisp) - dynamic profiling better than anything I've used since (Lisp) and -- this is what I was working on -- - 1 MB dedicated to Prolog, including Prolog compiler (Prolog) In terms of memory capacity and "horsepower", the D-machines were roughly comparable to an M68010-based Sun workstation. But the memory and "horsepower" weren't needed to run *Lisp*, they were needed to run all the *other* stuff. Interlisp-D was a very nice system to use. It was forked from Interlisp, which ran on machines with less than a megabyte of memory, but lacked the IDE, network stack, &c. I never had the pleasure of using an MIT-family Lisp machine, although I worked with two people who had, so I can say it was the same issue there. They did *everything* in an *integrated* way in Lisp. Complaining that those machines needed "horsepower" is like complaining that Eclipse needs serious horsepower (my word, doesn't it just) and blaming the C code you are editing in it. Heck, there was even a Scheme system for the Apple ][. > >> OK, a University lab of cheap 8086 PCs does technically count as >> state-sponsored, but hardly "raw horsepower". I suppose the price >> of TI PC-Scheme (USD95) would have put it out of reach of hobbyists >> /sarc. > > Nah, it simply wasn't available unless you knew it existed. > (I certainly didn't know.) No, that's not what "available" means. It was offered for sale. It was advertised. There was a published book about how to use it. It really was not at all hard to find if you looked. > >> I'm very sad to see FUD about Lisp surviving this long. > > Enough of this kind of slur. When you say that Lisp was not used because it required serious "horsepower", you say what is not true. Lisp did not require serious "horsepower". Some of the *applications* that people wanted to write in Lisp required serious "horsepower", but they would have required such no matter what the programming language, and the relevance of Lisp was simply that it made such applications *thinkable* in a way that most other languages did not. As for Python, if we define "PC days" to include 1988, when there were about a dozen Lisps running on 286s, so yes, Python began in late 1989 and 1.0 was released in 2004, so you're right. But I never said Python was eagerly adopted in the "PC days". > I have been refraining from responding in kind, because some unfriendly things could be said about your mindset. My mindset is that SML is better than Lisp and Haskell is better than SML and there are languages pushing even further than Haskell in interesting directions. I stopped counting how many programming languages I had tried when I reached 200. Things have changed a lot. We now have compilers like SMLtoJs http://www.smlserver.org/smltojs/ so that we can compile statically typed mostly-functional code into dynamically typed strange code so that we can run it in a browser. All the old complaints about Lisp, and we end up with JavaScript. But that's OK because it has curly braces. (:-( We have massive amounts of software in the world these days, and as far as I can tell, all of it is more or less broken. Read about the formal verification of seL4. It is downright scary how many bugs there can be in such a small chunk of code. And it's interesting that the people who did it now believe that formal verification can be *cheaper* than testing, for a given target error rate. The great thing about Lisp in the old days was that it could massively reduce the amount of code you had to write, thus reducing the number of errors you made. The great thing about Haskell is that it pushes that even further, and the type system helps to catch errors early. And QuickCheck! What a feature! There are other things, like PVS and Coq, which push verification at compile time further than Haskell (I never did manage to use the PVS verifier, but there's a great book about Coq), and if it turns out that bog standard programmers can't cope with that, then hiring superstandard programmers able to produce closer-to-verified code may be well worth the price. I often struggle to follow the things the brilliant people on this list do with Haskell's type system, but I very much appreciate their aim of producing correct code. From jo at durchholz.org Fri Apr 21 05:38:31 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 21 Apr 2017 07:38:31 +0200 Subject: [Haskell-cafe] Wow Monads! In-Reply-To: <952AA38E-2AA0-40D7-8416-EA32683EA290@cs.otago.ac.nz> References: <0a721e29-1f64-5977-7167-038576b23a55@durchholz.org> <36144252-7948-4862-898F-446BDE486E64@refined-audiometrics.com> <75CE34E7-6880-41EC-BBB2-CE56A4F394D3@refined-audiometrics.com> <1CZcb0Eoj4bOqImHCjFaXl7GjR9Hq38irAT9UZwxqUMgso2CwSjVrMLmU8hypVR_u91x8J1S92d8tOMKcnvmljoRO5afWd0LQLLTtjEYqdI=@protonmail.com> <37782A02-E132-4113-A5A5-21C5A3DA21FA@cs.otago.ac.nz> <2de1c931-ea33-9cf1-6fb6-ecd3370552a3@durchholz.org> <5C24B0B7-49A7-43FD-A98C-5425E9A3F8A9@cs.otago.ac.nz> <952AA38E-2AA0-40D7-8416-EA32683EA290@cs.otago.ac.nz> Message-ID: <29a5c3d4-3ae8-349e-ba36-c8c1798e1c1b@durchholz.org> I'm not going to continue this, you keep insisting that I'm somehow either an idiot or acting maliciously, and neither is a role that I like to be in. I'm slightly pissed off, and that's not a good basis for continuing a constructive exchange, and there's too much risk that we're really mad at each other if we continue this. Regards, Jo From damian.nadales at gmail.com Fri Apr 21 11:59:51 2017 From: damian.nadales at gmail.com (Damian Nadales) Date: Fri, 21 Apr 2017 13:59:51 +0200 Subject: [Haskell-cafe] Vacancy: Functional Software Engineer Message-ID: Hello Cafe, I'm forwarding a job opening in Eindhoven, The Netherlands. """ We are looking for an experienced software developer with good GUI development skills. Proven knowledge on the principles and working of build, test and release management through experience with several tools is required. Part of the work will be in choosing an appropriate GUI build framework catering for the different partner environments. The Model Driven Development Tool is implemented in Haskell. However, no specific Haskell knowledge is required, but hands on experience with a modern functional language is. Please contact Koen.Schilders at enter-group.nl """ Best regards, Damian. From wojtek at power.com.pl Fri Apr 21 18:10:57 2017 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Fri, 21 Apr 2017 20:10:57 +0200 Subject: [Haskell-cafe] In search for an http/2 server Message-ID: <10f3e08c-1d2a-44c7-687f-ead3c192c3c8@power.com.pl> Honorable cafe, I'd like to experiment with http/2. The package wai used to contain Network.Wai.HTTP2, but the ChangeLog says it has been removed in 3.2.0, no further explanation given. Where should I look for an http/2 server these days? -- Kind regards, Wojtek Narczynski From ch.martin at gmail.com Fri Apr 21 20:36:01 2017 From: ch.martin at gmail.com (Chris Martin) Date: Fri, 21 Apr 2017 20:36:01 +0000 Subject: [Haskell-cafe] What does the "S" in "ShowS" signify? Message-ID: The name "ShowS" in Text.Show always been mysterious to me. Can anyone explain why it's called that? -------------- next part -------------- An HTML attachment was scrubbed... URL: From javran.c at gmail.com Fri Apr 21 20:45:48 2017 From: javran.c at gmail.com (Javran Cheng) Date: Fri, 21 Apr 2017 16:45:48 -0400 Subject: [Haskell-cafe] What does the "S" in "ShowS" signify? In-Reply-To: References: Message-ID: also interested in knowing this, I'm not 100% sure but I think it has something to do with diff list. if this is the case, perhaps DShow is a better name? On Fri, Apr 21, 2017 at 4:36 PM, Chris Martin wrote: > The name "ShowS" in Text.Show always been mysterious to me. Can anyone > explain why it's called that? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Javran (Fang) Cheng -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Apr 21 20:48:41 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 21 Apr 2017 16:48:41 -0400 Subject: [Haskell-cafe] What does the "S" in "ShowS" signify? In-Reply-To: References: Message-ID: I always figured the P in ReadP was Parser and the S in ShowS was Show-er, despite it being a duplication (possibly because nobody could come up with a better name). On Fri, Apr 21, 2017 at 4:45 PM, Javran Cheng wrote: > also interested in knowing this, I'm not 100% sure but I think it has > something to do with diff list. if this is the case, perhaps DShow is a > better name? > > On Fri, Apr 21, 2017 at 4:36 PM, Chris Martin wrote: > >> The name "ShowS" in Text.Show always been mysterious to me. Can anyone >> explain why it's called that? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > Javran (Fang) Cheng > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 byorgey at gmail.com Fri Apr 21 22:55:33 2017 From: byorgey at gmail.com (Brent Yorgey) Date: Fri, 21 Apr 2017 22:55:33 +0000 Subject: [Haskell-cafe] Dynamic Programming exercises In-Reply-To: References: Message-ID: You might like to try some exercises from my algorithms class: http://ozark.hendrix.edu/~yorgey/280/static/hw.7.pdf You could also look at the lecture notes and try actually implementing the DP algorithms discussed there: http://ozark.hendrix.edu/~yorgey/280/static/CSCI-280-lecture-notes.pdf (sections 20-22) More generally, any standard algorithms textbook should have a ton of DP exercises. -Brent On Wed, Apr 12, 2017 at 12:47 PM Michael Litchard < litchard.michael at gmail.com> wrote: > I found the below link to be an illuminating read in regards to how to > approach dynamic programming in haskell. Now I would like to test my > understanding on different exercises. > I'd like suggestions on problems that could be solved by the approach > elucidated below. > > http://jelv.is/blog/Lazy-Dynamic-Programming/ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From litchard.michael at gmail.com Fri Apr 21 23:00:09 2017 From: litchard.michael at gmail.com (Michael Litchard) Date: Fri, 21 Apr 2017 16:00:09 -0700 Subject: [Haskell-cafe] Dynamic Programming exercises In-Reply-To: References: Message-ID: Nice! Thank you Brent. On Fri, Apr 21, 2017 at 3:55 PM, Brent Yorgey wrote: > You might like to try some exercises from my algorithms class: > > http://ozark.hendrix.edu/~yorgey/280/static/hw.7.pdf > > You could also look at the lecture notes and try actually implementing the > DP algorithms discussed there: > > http://ozark.hendrix.edu/~yorgey/280/static/CSCI-280-lecture-notes.pdf > (sections 20-22) > > More generally, any standard algorithms textbook should have a ton of DP > exercises. > > -Brent > > > On Wed, Apr 12, 2017 at 12:47 PM Michael Litchard < > litchard.michael at gmail.com> wrote: > >> I found the below link to be an illuminating read in regards to how to >> approach dynamic programming in haskell. Now I would like to test my >> understanding on different exercises. >> I'd like suggestions on problems that could be solved by the approach >> elucidated below. >> >> http://jelv.is/blog/Lazy-Dynamic-Programming/ >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 nickolay.kudasov at gmail.com Sat Apr 22 07:56:39 2017 From: nickolay.kudasov at gmail.com (Nickolay Kudasov) Date: Sat, 22 Apr 2017 07:56:39 +0000 Subject: [Haskell-cafe] In search for an http/2 server In-Reply-To: <10f3e08c-1d2a-44c7-687f-ead3c192c3c8@power.com.pl> References: <10f3e08c-1d2a-44c7-687f-ead3c192c3c8@power.com.pl> Message-ID: Hi Wojtek, I am not entirely sure that's what you want, but there's http2 package [1] that is used by warp. Kind regards, Nick [1] http://hackage.haskell.org/package/http2 On Fri, 21 Apr 2017 at 21:23 Wojtek Narczyński wrote: > Honorable cafe, > > I'd like to experiment with http/2. The package wai used to contain > Network.Wai.HTTP2, but the ChangeLog says it has been removed in 3.2.0, > no further explanation given. Where should I look for an http/2 server > these days? > > -- > Kind regards, > Wojtek Narczynski > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 nickolay.kudasov at gmail.com Sat Apr 22 14:19:27 2017 From: nickolay.kudasov at gmail.com (Nickolay Kudasov) Date: Sat, 22 Apr 2017 14:19:27 +0000 Subject: [Haskell-cafe] In search for an http/2 server In-Reply-To: References: <10f3e08c-1d2a-44c7-687f-ead3c192c3c8@power.com.pl> Message-ID: Hi Wojtek, I should probably elaborate, that warp [1] serves all of HTTP/1, HTTP/1.1 and HTTP/2 requests. So if you're looking for a HTTP/2 server, you can just use warp. Note that the docs say that > For HTTP/2, Warp supports direct and ALPN (in TLS) but not upgrade. Kind regards, Nick [1] https://hackage.haskell.org/package/warp On Sat, 22 Apr 2017 at 10:56 Nickolay Kudasov wrote: > Hi Wojtek, > > I am not entirely sure that's what you want, but there's http2 package [1] > that is used by warp. > > Kind regards, > Nick > > [1] http://hackage.haskell.org/package/http2 > > On Fri, 21 Apr 2017 at 21:23 Wojtek Narczyński > wrote: > >> Honorable cafe, >> >> I'd like to experiment with http/2. The package wai used to contain >> Network.Wai.HTTP2, but the ChangeLog says it has been removed in 3.2.0, >> no further explanation given. Where should I look for an http/2 server >> these days? >> >> -- >> Kind regards, >> Wojtek Narczynski >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.antosha at gmail.com Sat Apr 22 22:18:49 2017 From: michael.antosha at gmail.com (Michael V. Antosha) Date: Sun, 23 Apr 2017 01:18:49 +0300 Subject: [Haskell-cafe] Dynamic Programming exercises In-Reply-To: References: Message-ID: On 4/12/17, Michael Litchard wrote: > > I found the below link to be an illuminating read in regards to how to > approach dynamic programming in haskell. [...] Thank you for mentioning that blog post, Michael! It was a really inspiring reading for me. > I'd like suggestions on problems that could be solved by the approach > elucidated below. I think you could try searching through problem archives at competitive programming sites for problems with tags, say, "dp" or "dynamic programming". Like this one: http://codeforces.com/problemset/tags/dp?order=BY_SOLVED_DESC Specifically, I tried the 455A/456C "Boredom" problem to test the approach you mentioned. http://codeforces.com/problemset/problem/456/C It worked fine for me :) -- Michael V. Antosha http://mivael.in.ua xmpp:m at mivael.in.ua (Jabber ID) From adam at bergmark.nl Sun Apr 23 18:15:33 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 23 Apr 2017 18:15:33 +0000 Subject: [Haskell-cafe] Looking for a new stackage curator Message-ID: Hi everyone, We are looking to expand the stackage curator team again! Please see this document for more information: https://github.com/fpco/stackage/blob/master/become-a-curator.md If you are already convinced you can go straight to https://goo.gl/forms/eD6lTLtuyyHAIcfC2 Re-applications are encouraged! Cheers, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From robstewart57 at gmail.com Mon Apr 24 12:11:08 2017 From: robstewart57 at gmail.com (Rob Stewart) Date: Mon, 24 Apr 2017 12:11:08 +0000 Subject: [Haskell-cafe] Fwd: 2nd Call for Papers: 16th ACM SIGPLAN Erlang Workshop 2017 In-Reply-To: <8943246A3F40B240BE533CA3011C046165B9E3A0@CMS08-02.campus.gla.ac.uk> References: <8943246A3F40B240BE533CA3011C046165B9E36E@CMS08-02.campus.gla.ac.uk> <8943246A3F40B240BE533CA3011C046165B9E3A0@CMS08-02.campus.gla.ac.uk> Message-ID: 2nd CALL FOR PAPERS =============== Sixteenth ACM SIGPLAN Erlang Workshop http://erlang.org/workshop/2017/ ----------------------------------------------------------- Oxford, United Kingdom, 8 September 2017 Satellite event of the 22nd ACM SIGPLAN International Conference on Functional Programming (ICFP 2017) 3 - 9 September, 2017 The Erlang Workshop aims to bring together the open source, academic, and industrial communities of Erlang, to discuss technologies and languages related to Erlang. The Erlang model of concurrent programming has been widely emulated, for example by Akka in Scala, and even new programming languages were designed atop of the Erlang VM, such as Elixir. Therefore we would like to broaden the scope of the workshop to include systems like those mentioned above. The workshop will enable participants to familiarize themselves with recent developments on new techniques and tools, novel applications, draw lessons from users' experiences and identify research problems and common areas relevant to the practice of Erlang, Erlang-like languages, functional programming, distribution, concurrency etc. We invite three types of submissions. 1. Technical papers describing language extensions, critical discussions of the status quo, formal semantics of language constructs, program analysis and transformation, virtual machine extensions and compilation techniques, implementations and interfaces of Erlang in/with other languages, and new tools (profilers, tracers, debuggers, testing frameworks, etc.). The maximum length for technical papers is restricted to 12 pages. 2. Practice and application papers describing uses of Erlang in the "real-world", Erlang libraries for specific tasks, experiences from using Erlang in specific application domains, reusable programming idioms and elegant new ways of using Erlang to approach or solve a particular problem. The maximum length for the practice and application papers is restricted to 12 pages. Note that this is a maximum length; we welcome shorter papers also, and the program committee will evaluate all papers on an equal basis independent of their lengths. 3. Poster presentations describing topics related to the workshop goals. Each includes a maximum of 2 pages of the abstract and summary. Presentations in this category will be given an hour of shared simultaneous demonstration time. Workshop Co-Chairs ------------------ Scott Lystig Fritchie, VMware, USA Natalia Chechina, Glasgow University, UK Program Committee ----------------------------- (Note: the Workshop Co-Chairs are also committee members) Clara Benac Earle, Universidad Politecnica de Madrid, Spain Richard Carlsson, Klarna, Sweden Laura M. Castro, University of A Coruna, Spain Viktoria Fördős, Klarna, Sweden James S. Larson, Google, USA Important Dates ----------------------- Submission deadline: Fri May 26, 2017 Author notification: Fri June 23, 2017 Final submission for the publisher: Sat July 15, 2017 Workshop date: Fri September 8, 2017 Instructions to authors -------------------------------- Papers must be submitted online via EasyChair (via the "Erlang2017" event). The submission page is https://www.easychair.org/conferences/?conf=erlang2017 Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Each submission must adhere to SIGPLAN's republication policy. Violation risks summary rejection of the offending submission. Accepted papers will be published by the ACM and will appear in the ACM Digital Library. The proceedings will be freely available for download from the ACM Digital Library from one week before the start of the conference until two weeks after the conference. Paper submissions will be considered for poster submission in the case they are not accepted as full papers. Venue & Registration Details ------------------------------------------ For registration, please see the ICFP 2017 web site at: http://icfp17.sigplan.org/ Related Links -------------------- ICFP 2017 web site: http://icfp17.sigplan.org/ Past ACM SIGPLAN Erlang workshops: http://www.erlang.org/workshop/ Open Source Erlang: http://www.erlang.org/ EasyChair submission site: https://www.easychair.org/conferences/?conf=erlang2017 Author Information for SIGPLAN Conferences: http://www.sigplan.org/authorInformation.htm Atendee Information for SIGPLAN Events: http://www.sigplan.org/Resources/Policies/CodeOfConduct/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: EW'17-poster.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 113025 bytes Desc: not available URL: From gershomb at gmail.com Mon Apr 24 21:56:03 2017 From: gershomb at gmail.com (Gershom B) Date: Mon, 24 Apr 2017 17:56:03 -0400 Subject: [Haskell-cafe] ANN: Compose Unconference and Exchange [NYC, May 20-21] Message-ID: I'm happy to announce that we now have a venue and dates for the affiliated Unconference and Exchange (aka "hackathon") for the Compose conference in NYC. It will take place the weekend immediately following the main conference, featuring improptu tutorials, collaborative coding, and generally be a good informal opportunity to work and discuss with functional programmers of all sorts. Registration (free) is at: https://www.eventbrite.com/e/cmpse-unconference-and-exchange-2017-tickets-33988530610 Registration for the main conference remains at: https://composeconference.eventbrite.com. Early bird tickets are now gone, so get tickets while you can! We're also happy to announce the topic of our invited keynote by Emily Riehl: A Categorical View of Computational Effects * Unconference information: http://www.composeconference.org/2017/unconference/ * Unconference registration: https://www.eventbrite.com/e/cmpse-unconference-and-exchange-2017-tickets-33988530610 * Full conference abstracts: http://www.composeconference.org/2017/program * Conference Registration: http://composeconference.eventbrite.com * Follow @composeconf on twitter for news: https://twitter.com/composeconf * On freenode irc, chat with fellow attendees at #composeconference * Corporate sponsorships are welcome. Current sponsors list forthcoming. * Policies (diversity and anti-harassment): http://www.composeconference.org/conduct * Email us with any questions at info at composeconference.org * Please forward this announcement to interested parties and lists. From wojtek at power.com.pl Mon Apr 24 22:23:09 2017 From: wojtek at power.com.pl (=?UTF-8?Q?Wojtek_Narczy=c5=84ski?=) Date: Tue, 25 Apr 2017 00:23:09 +0200 Subject: [Haskell-cafe] In search for an http/2 server In-Reply-To: References: <10f3e08c-1d2a-44c7-687f-ead3c192c3c8@power.com.pl> Message-ID: <92252e97-ea8e-7c28-2164-4cce71789a3a@power.com.pl> On 22.04.2017 16:19, Nickolay Kudasov wrote: > > I should probably elaborate, that warp [1] serves all of HTTP/1, > HTTP/1.1 and HTTP/2 requests. > So if you're looking for a HTTP/2 server, you can just use warp. > > Note that the docs say that > > For HTTP/2, Warp supports direct and ALPN (in TLS) but not upgrade. > > Indeed. I just replaced run with runTLS, using this example: https://chromabits.com/posts/2016/02/15/serving-hakyll-site-with-warp/ It worked, just like that. Thank you, localhost.daplie.me. Unfortunately, http/2 is three times slower for my use case (thin html wih 30 * 2MB jpegs). -- Wojtek From andrei.paskevich at lri.fr Tue Apr 25 10:30:58 2017 From: andrei.paskevich at lri.fr (Andrei Paskevich) Date: Tue, 25 Apr 2017 12:30:58 +0200 Subject: [Haskell-cafe] VSTTE 2017 - Deadline Extension Message-ID: <20170425103058.pkuifg7g6qpxkkwp@tikki.lri.fr> *** DEADLINE EXTENSION *** 9th Working Conference on Verified Software: Theories, Tools, and Experiments (VSTTE) https://vstte17.lri.fr July 22-23, 2017, Heidelberg, Germany Co-located with the 29th International Conference on Computer-Aided Verification, CAV 2017 Deadline Extension The deadlines for submitting abstracts and full papers have been extended by one week. The new deadlines are firm. Important Dates * Abstract submission (extended): Mon, May 1, 2017 (AoE) * Full paper submission (extended): Mon, May 8, 2017 (AoE) * Notification: Mon, Jun 5, 2017 * VSTTE: Sat-Sun, Jul 22-23, 2017 * Camera-ready: Mon, Aug 21, 2017 Overview The goal of the VSTTE conference series is to advance the state of the art in the science and technology of software verification, through the interaction of theory development, tool evolution, and experimental validation. We welcome submissions describing significant advances in the production of verified software, i.e., software that has been proved to meet its functional specifications. Submissions of theoretical, practical, and experimental contributions are equally encouraged, including those that focus on specific problems or problem domains. We are especially interested in submissions describing large-scale verification efforts that involve collaboration, theory unification, tool integration, and formalized domain knowledge. We also welcome papers describing novel experiments and case studies evaluating verification techniques and technologies. Topics of interest for VSTTE include education, requirements modeling, specification languages, specification/verification/certification case studies, formal calculi, software design methods, automatic code generation, refinement methodologies, compositional analysis, verification tools (e.g., static analysis, dynamic analysis, model checking, theorem proving, satisfiability), tool integration, benchmarks, challenge problems, and integrated verification environments. Paper Submissions We accept both long (limited to 16 pages, references not included) and short (limited to 10 pages, references not included) paper submissions. Short submissions also cover Verification Pearls describing an elegant proof or proof technique. Submitted research papers and system descriptions must be original and not submitted for publication elsewhere. Each submission will be evaluated by at least three members of the Program Committee. We expect that one author of every accepted paper will present their work at the conference. Paper submissions must be written in English using the LNCS LaTeX format (http://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines) and must include a cogent and self-contained description of the ideas, methods, results, and comparison to existing work. Papers will be submitted via EasyChair at the VSTTE 2017 conference page (https://www.easychair.org/conferences/?conf=vstte2017). The post-conference proceedings of VSTTE 2017 will be published in the LNCS series. Authors of accepted papers will be requested to sign the copyright transfer form. A selection of best papers will be invited for publication in the Journal of Automated Reasoning. Invited Speakers * Christoph Weidenbach (Max Planck Institute for Informatics, Germany) * Santiago Zanella-Beguelin (Microsoft Research, UK) Program Chairs * Andrei Paskevich (Université Paris-Sud, France) * Thomas Wies (New York University, USA) Program Committee * June Andronick (University of New South Wales, Australia) * Christel Baier (TU Dresden, Germany) * Sandrine Blazy (Université de Rennes 1, France) * Arthur Charguéraud (Inria, France) * Ernie Cohen (Amazon Web Services, USA) * Rayna Dimitrova (MPI-SWS, Germany) * Carlo A. Furia (Chalmers University of Technology, Sweden) * Arie Gurfinkel (University of Waterloo, Canada) * Hossein Hojjat (Rochester Institute of Technology, USA) * Marieke Huisman (University of Twente, Netherlands) * Bart Jacobs (KU Leuven, Belgium) * Rajeev Joshi (NASA Jet Propulsion Laboratory, USA) * Zachary Kincaid (Princeton University, USA) * Akash Lal (Microsoft Research, India) * Shuvendu Lahiri (Microsoft Research, USA) * Francesco Logozzo (Facebook, USA) * Peter Müller (ETH Zürich, Switzerland) * Jorge A. Navas (SRI International, USA) * Scott Owens (University of Kent, UK) * Gerhard Schellhorn (Universität Augsburg, Germany) * Peter Schrammel (University of Sussex, UK) * Natarajan Shankar (SRI International, USA) * Mihaela Sighireanu (Université Paris-Diderot, France) * Julien Signoles (CEA LIST, France) * Michael Tautschnig (Queen Mary University of London, UK) * Tachio Terauchi (JAIST, Japan) * Oksana Tkachuk (NASA Ames Research Center, USA) * Mattias Ulbrich (Karlsruhe Institute of Technology, Germany) From chneukirchen at gmail.com Tue Apr 25 11:38:43 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Tue, 25 Apr 2017 13:38:43 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2017-01-26 @ 19:30 Message-ID: <87vapspvi4.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, April 27 at Augustiner-Gaststätte Rumpler (Baumstraße 21) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-apr-2017/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From abela at chalmers.se Tue Apr 25 12:43:37 2017 From: abela at chalmers.se (Andreas Abel) Date: Tue, 25 Apr 2017 14:43:37 +0200 Subject: [Haskell-cafe] Senior Lectureships in Computer Science at Chalmers and Gothenburg U Message-ID: <8ef34a45-d444-3181-c8e9-f283c1c6526f@chalmers.se> We are hiring full-time permanent lecturers! http://www.chalmers.se/en/about-chalmers/vacancies/Pages/default.aspx?rmpage=job&rmjob=4987 http://www.gu.se/english/about_the_university/job-opportunities/vacancies-details/?id=381 The positions are focusing on teaching, but some time will be available for research as well. Excerpt from the description: Major responsibilities The scientific area is Computer Science, interpreted broadly. The position is a full-time tenured appointment with focus on education and pedagogical development. You will teach a variety of topics in Computer Science; there may include courses such as programming, data structures, algorithms and databases. You will also supervise bachelor level projects and master’s theses. Besides teaching, you will keep up with the technical and pedagogical development in the areas of the position and introduce new methods in the curriculum. As a faculty member you will share the responsibility of the administration and management of the department and the educational programmes. You will collaborate with industrial, academic or governmental partners, and take part in the research conducted at the department. In addition, you are encouraged to apply for funding of further pedagogical advancement of our programmes, and for research funding. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From simon at joyful.com Tue Apr 25 20:03:09 2017 From: simon at joyful.com (Simon Michael) Date: Tue, 25 Apr 2017 13:03:09 -0700 Subject: [Haskell-cafe] bounty for vty on Windows Message-ID: <5E336F76-3909-4A6D-BDF5-FE048FE3D341@joyful.com> Hi all, vty is a nice full-screen curses-style API, and the basis for the nice higher-level brick TUI (text UI) framework, that builds on POSIX platforms only. All agree that it would be nice to make it work on Windows too. This would allow building cross-platform TUIs with haskell. Also there are things in vty, such as the Graphics.Vty.Attributes, that would be useful for CLIs too. I summarised current status and have kicked off a bounty towards getting Windows support added to the vty lib. I'm sending this to raise interest and invite your help, be you a person with a Windows machine, a potential bounty donor, or someone interested in improving Haskell's portability and applicability. https://github.com/jtdaugherty/vty/pull/1#issuecomment-297143444 My particular interest is in making hledger-ui[1] cross platform, and in being able to use vty's higher-level terminal styles in CLI tools on all platforms. Best! Simon [1] http://hledger.org/hledger-ui.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikivazou at gmail.com Tue Apr 25 21:57:14 2017 From: nikivazou at gmail.com (Niki Vazou) Date: Tue, 25 Apr 2017 17:57:14 -0400 Subject: [Haskell-cafe] Getting ready for Summer of Haskell 2017 In-Reply-To: References: Message-ID: Hey all, The student applications for Summer of Haskell 2017 are now open! You can apply at: https://goo.gl/forms/OAfyD0Oen2KvKu6t2 The application period is open until the 6th of May, so that should give you plenty of time. At this time, we are also actively *seeking mentors*. In case you would like to mentor a project, please let us know: https://summer.haskell.org/contact.html Thanks to the generous donations of our sponsors, we will be able to sponsor around 10 students this year (depending on the applications we receive). Our sponsors are: - haskell.org kicked things off this year by funding a student and organizing the Summer of Haskell 2017 after a successful Summer of Haskell 2016 . - Asahi Net is a Japanese Internet service provider that has been running stable systems for over 25 years. They are a proud sponsor of the Summer of Haskell, and contribute to the Japanese Haskell community. - Awake Networks is building a next generation network security and analytics platform. They are a proud sponsor of the Summer of Haskell and contribute broadly to the Haskell community. - CodeWorld is an educational project that blends mathematics and Haskell programming into a visual playground. Chris Smith has volunteered to fund two students to work on CodeWorld in particular. - Digital Asset provides Distributed Ledger solutions for financial institutions globally. They have developed a pure, typed, functional, domain specific language for writing contracts, called DAML. They are a proud sponsor of the Summer of Haskell and contribute broadly to the Haskell community. - Facebook uses Haskell in its anti-abuse infrastructure and as part of that effort we open-sourced the Haxl framework which is being used at scale in production to automatically parallelise data-fetching code. We're delighted to be able to support the Haskell community's efforts by sponsoring a student for this year's Summer of Haskell. - Fugue Inc. radically simplifies cloud operations with its software-defined system for dynamically orchestrating and enforcing cloud infrastructure at scale. Fugue uses Haskell in its product and is proud to sponsor a student to improve the ecosystem. - Galois applies cutting-edge computer science and applied mathematics to solve difficult technological problems, delivering practical solutions tailored to our clients’ needs. Haskell and other functional programming languages are key tools we use in providing these solutions. - IOHK is a technology company committed to using peer-to-peer technologies to provide financial services to the three billion people who don't have them. We implement our first-principles cryptographic research in Haskell and we are committed to the development of the Haskell ecosystem. - Tweag I/O is a network of software innovation labs across Europe. We develop novel solutions and products for our clients around the world. Haskell is key to delivering fast, correct and maintainable code. We have shipped Haskell in anything from tiny web services to large high-performance compute clusters with custom hardware. We're particularly keen to help the community grow Haskell into the strongest systems programming language and ecosystem out there. We're very proud to sponsor a student this summer to help make it happen. - Davean has volunteered to fund a student expressly to work on the Hadrian build system for GHC . Best, Niki Vazou & Jasper Van der Jeugt for the Haskell.org Committee On Wed, Apr 5, 2017 at 3:17 PM, Niki Vazou wrote: > We are happy to announce that Summer of Haskell 2017 will host at least 8 > students, funded from the Haskell community and corporate sponsors. > > You can find all information (including the timeline) at the Summer of > Haskell new webpage: > > https://summer.haskell.org/ > > Students can submit applications from April 25th until the May 6th. We > recommend that interested students start thinking about their proposals and > brainstorm with potential mentors. In case you would like to participate as > a student, but you have no idea what to work on, we have a page dedicated > to ideas here: > > https://summer.haskell.org/ideas.html > > Teachers of FP courses at universities around the world are strongly > encouraged to share this announcement with their students. > > Mentors, as well as everyone from the community, are encouraged to > contribute ideas by sending pull requests to the Summer of Haskell > repository (or contacting us): > > https://github.com/haskell-org/summer-of-haskell > > Sponsors are still welcome, as we can add more slots if the necessary > funds become available. Combining our current individual donations with > partial sponsors, we only need $2000 more to fund an additional student. > Please consider making a small donation towards that goal. If you would > like to contribute do not hesitate to contact us or donate directly: > > https://wiki.haskell.org/Donate_to_Haskell.org > > We’d like to thank our current sponsors for making this Summer of Haskell > possible: > > haskell.org kicked things off this year by funding a student and > organizing the Summer of Haskell 2017 after a successful Summer of > Haskell 2016 > > . > > Asahi Net is a Japanese Internet service provider > that has been running stable systems for over 25 years. They are a proud > sponsor of the Summer of Haskell, and contribute to the Japanese Haskell > community. > > Awake Networks is building a next > generation network security and analytics platform. They are a proud > sponsor of the Summer of Haskell and contribute broadly to the Haskell > community. > > CodeWorld is an educational project that blends > mathematics and Haskell programming into a visual playground. Chris Smith > has volunteered to fund two students to work on CodeWorld in particular. > > Facebook uses Haskell in its anti-abuse > infrastructure > , > and as part of that effort we open-sourced the Haxl > framework which is being used at scale > in production to automatically parallelise data-fetching code. We're > delighted to be able to support the Haskell community's efforts by > sponsoring a student for this year's Summer of Haskell. > > Fugue Inc. radically simplifies cloud operations with > its software-defined system for dynamically orchestrating and enforcing > cloud infrastructure at scale. Fugue uses Haskell in its product and is > proud to sponsor a student to improve the ecosystem. > > Galois applies cutting-edge computer science and > applied mathematics to solve difficult technological problems, delivering > practical solutions tailored to our clients’ needs. Haskell and other > functional programming languages are key tools we use in providing these > solutions. > > Tweag I/O is a network of software innovation labs > across Europe. We develop novel solutions and products for our clients > around the world. Haskell is key to delivering fast, correct and > maintainable code. We have shipped Haskell in anything from tiny web > services to large high-performance compute clusters with custom hardware. > We're particularly keen to help the community grow Haskell into the > strongest systems programming language and ecosystem out there. We're very > proud to sponsor a student this summer to help make it happen. > > Finally, Davean has volunteered to fund a student expressly to work on > the Hadrian build system for GHC > . > > Feel free to contact us at (nvazou at cs.umd.edu and m at jaspervdj.be) > if want to help or if you have any ideas, questions, or concerns. > > Best, > > Niki Vazou & Jasper Van der Jeugt > > for the Haskell.org Committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahmoudmurad92 at gmail.com Wed Apr 26 12:02:40 2017 From: mahmoudmurad92 at gmail.com (Mahmoud Murad) Date: Wed, 26 Apr 2017 15:02:40 +0300 Subject: [Haskell-cafe] complex multiplication function in Haskell Message-ID: Hi there, The number 354162 has 6 digits and contains all digits from 1 to 6, and it can be considered as a multiplication of 3 * 54 = 162. so what I need is a function that will take all the real number and return the number that can be split as above, 354162 .. 3 * 54 = 162 I have no idea how to do such a thing! any help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From 14 at mniip.com Wed Apr 26 12:24:21 2017 From: 14 at mniip.com (mniip) Date: Wed, 26 Apr 2017 15:24:21 +0300 Subject: [Haskell-cafe] Partial type family application Message-ID: <20170426122421.GB17944@mniip.com> So I've been thinking of a type system extension: partial type family application. If we look at the type system used by modern GHC, in it, type family application is very distinct from constructor/constraint application: it is somewhat opaque in the sense that a type family must always appear fully applied. As such, it doesn't make sense to talk about a type family's kind, if we have: type family Id (a :: *) :: * where Id x = x then saying that 'Id :: * -> *' would be wrong, because Id cannot be used interchangeably with things that are truly of kind * -> *, such as Maybe or []. The reason for the "fully applied" restriction is that if we allowed partially applied type functions, then their equality would be undecidable. Still, I think, in a lot of cases we could benefit from partially applied type functions, even without extensional equality. Writing type level list folds, filters, zips, you name it. As stated above, we can't add the proposition 'Id :: * -> *' to our type system, so, what if, instead, we added a different kind of arrow kind for type families? I like the look of (~>), so 'Id :: * ~> *'. (~>) :: * -> * -> * This rule of inference, similar to the usual, would supersede all the type family kinding rules: f :: k ~> l, x :: k ------------------- f x :: l As such, the juxtaposition operator would very clearly have two different "kinds": (k -> l) --> k --> l and (k ~> l) --> k --> l, and there is no N-ary "type family application" operator. In order for the type checker to not fall apart, we need to have at least intesional (structural) equality on (~>), which we can have because it is decidable. We could then write stuff like type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where Foldr f z '[] = z Foldr f z (x ': xs) = f x (Foldr f z xs) From 14 at mniip.com Wed Apr 26 12:29:32 2017 From: 14 at mniip.com (mniip) Date: Wed, 26 Apr 2017 15:29:32 +0300 Subject: [Haskell-cafe] Partial type family application In-Reply-To: <20170426122421.GB17944@mniip.com> References: <20170426122421.GB17944@mniip.com> Message-ID: <20170426122932.GA19211@mniip.com> Oops, got cut off :S We could then write stuff like type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where Foldr f z '[] = z Foldr f z (x ': xs) = f x (Foldr f z xs) type family Flip (f :: k ~> l ~> m) (x :: l) (y :: k) :: m where Flip f x y = f y x -- Lift a type constructor into a type family type family Apply (con :: k -> l) (x :: k) :: l where Apply con x = con x type family (.) (f :: l ~> m) (g :: k ~> l) (x :: k) :: l where (.) f g x = f (g x) stuff :: Foldr (Flip (Apply . Apply (,))) () '[Int, String, Char] stuff = ((((), 'x'), "moo"), 3) This idea is very fresh, and I certainly haven't explored all the aspects, so I would welcome constructive (and intuitionistic) criticism regarding both usefulness and mathematical soundness of this. --mniip From greg7mdp at gmail.com Wed Apr 26 12:39:13 2017 From: greg7mdp at gmail.com (Gregory Popovitch) Date: Wed, 26 Apr 2017 08:39:13 -0400 Subject: [Haskell-cafe] complex multiplication function in Haskell In-Reply-To: References: Message-ID: Maybe just enumerate the possibilities 1 * 1 = 1 => 111 1 * 2 = 2 => 112 1 * 3 = 3 => 113 ... 2 * 1 = 2 => 212 ... _____ From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mahmoud Murad Sent: Wednesday, April 26, 2017 8:03 AM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] complex multiplication function in Haskell Hi there, The number 354162 has 6 digits and contains all digits from 1 to 6, and it can be considered as a multiplication of 3 * 54 = 162. so what I need is a function that will take all the real number and return the number that can be split as above, 354162 .. 3 * 54 = 162 I have no idea how to do such a thing! any help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Apr 26 14:08:40 2017 From: david.feuer at gmail.com (David Feuer) Date: Wed, 26 Apr 2017 10:08:40 -0400 Subject: [Haskell-cafe] Partial type family application In-Reply-To: <20170426122932.GA19211@mniip.com> References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> Message-ID: The arrow distinction is something I've speculated about, but I don't see how to handle nullary families and families with implicit kind arguments. These aren't necessarily written with arrows at all. type family F :: * type instance F = Char type family G :: k type instance G = Int type instance G = 'True On Wed, Apr 26, 2017 at 8:29 AM, mniip <14 at mniip.com> wrote: > Oops, got cut off :S > > We could then write stuff like > > type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where > Foldr f z '[] = z > Foldr f z (x ': xs) = f x (Foldr f z xs) > > type family Flip (f :: k ~> l ~> m) (x :: l) (y :: k) :: m where > Flip f x y = f y x > > -- Lift a type constructor into a type family > type family Apply (con :: k -> l) (x :: k) :: l where > Apply con x = con x > > type family (.) (f :: l ~> m) (g :: k ~> l) (x :: k) :: l where > (.) f g x = f (g x) > > stuff :: Foldr (Flip (Apply . Apply (,))) () '[Int, String, Char] > stuff = ((((), 'x'), "moo"), 3) > > This idea is very fresh, and I certainly haven't explored all the > aspects, so I would welcome constructive (and intuitionistic) criticism > regarding both usefulness and mathematical soundness of this. > > --mniip > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From rae at cs.brynmawr.edu Wed Apr 26 14:58:10 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 26 Apr 2017 10:58:10 -0400 Subject: [Haskell-cafe] Partial type family application In-Reply-To: References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> Message-ID: Yes, I believe you’re describing the Right Answer to this problem. I’ve hinted at this in my “Promoting functions to type families paper” (http://cs.brynmawr.edu/~rae/papers/2014/promotion/promotion.pdf) -- see Sections 4.3.1 and 7.1. It’s unfortunate that this clean idea is buried in all the other stuff in that paper. I’ve also mused on this approach in my thesis (http://cs.brynmawr.edu/~rae/papers/2016/thesis/eisenberg-thesis.pdf); see Section 4.2.4 (which seems readable independent of the rest of the thesis). The good news here is that this idea should be realizable independent from Dependent Haskell. It just needs someone to work out the details, propose, get community acceptance, and implement. But, from a theory point of view, I’m confident you’re describing the right direction to take all this in. Richard > On Apr 26, 2017, at 10:08 AM, David Feuer wrote: > > The arrow distinction is something I've speculated about, but I don't > see how to handle nullary families and families with implicit kind > arguments. These aren't necessarily written with arrows at all. > > type family F :: * > type instance F = Char > > type family G :: k > type instance G = Int > type instance G = 'True > > > > On Wed, Apr 26, 2017 at 8:29 AM, mniip <14 at mniip.com> wrote: >> Oops, got cut off :S >> >> We could then write stuff like >> >> type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where >> Foldr f z '[] = z >> Foldr f z (x ': xs) = f x (Foldr f z xs) >> >> type family Flip (f :: k ~> l ~> m) (x :: l) (y :: k) :: m where >> Flip f x y = f y x >> >> -- Lift a type constructor into a type family >> type family Apply (con :: k -> l) (x :: k) :: l where >> Apply con x = con x >> >> type family (.) (f :: l ~> m) (g :: k ~> l) (x :: k) :: l where >> (.) f g x = f (g x) >> >> stuff :: Foldr (Flip (Apply . Apply (,))) () '[Int, String, Char] >> stuff = ((((), 'x'), "moo"), 3) >> >> This idea is very fresh, and I certainly haven't explored all the >> aspects, so I would welcome constructive (and intuitionistic) criticism >> regarding both usefulness and mathematical soundness of this. >> >> --mniip >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jan.stolarek at p.lodz.pl Wed Apr 26 15:05:11 2017 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 26 Apr 2017 16:05:11 +0100 Subject: [Haskell-cafe] Partial type family application In-Reply-To: <20170426122932.GA19211@mniip.com> References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> Message-ID: <201704261605.11957.jan.stolarek@p.lodz.pl> mniip, you might want to take a look at a paper Richard Eisenberg and I wrote together in 2014: Eisenberg, R. A., and Stolarek, J.: Promoting Functions to Type Families in Haskell, ACM SIGPLAN Notices 49(12):95-106 (originally published at: Haskell Symposium 2014, Göteborg, Sweden) Janek Dnia środa, 26 kwietnia 2017, mniip napisał: > Oops, got cut off :S > > We could then write stuff like > > type family Foldr (f :: k ~> l ~> l) (z :: l) (xs :: [k]) :: l where > Foldr f z '[] = z > Foldr f z (x ': xs) = f x (Foldr f z xs) > > type family Flip (f :: k ~> l ~> m) (x :: l) (y :: k) :: m where > Flip f x y = f y x > > -- Lift a type constructor into a type family > type family Apply (con :: k -> l) (x :: k) :: l where > Apply con x = con x > > type family (.) (f :: l ~> m) (g :: k ~> l) (x :: k) :: l where > (.) f g x = f (g x) > > stuff :: Foldr (Flip (Apply . Apply (,))) () '[Int, String, Char] > stuff = ((((), 'x'), "moo"), 3) > > This idea is very fresh, and I certainly haven't explored all the > aspects, so I would welcome constructive (and intuitionistic) criticism > regarding both usefulness and mathematical soundness of this. > > --mniip > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From sergueyz at gmail.com Wed Apr 26 21:42:08 2017 From: sergueyz at gmail.com (Serguey Zefirov) Date: Thu, 27 Apr 2017 00:42:08 +0300 Subject: [Haskell-cafe] Cabal and IPv6 Message-ID: I have found that Cabal does not work on IPv6-only networks (which my machine happen to be part of). The problem is basically this: "ping hackage.haskell.org" does not resolve host while "ping6 hackage.haskell.org" does. Thus cabal cannot do anything useful on that machine. Do anyone have a solution for that? I was unable to find any on the internet. ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Apr 27 00:04:15 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 27 Apr 2017 12:04:15 +1200 Subject: [Haskell-cafe] complex multiplication function in Haskell In-Reply-To: References: Message-ID: > On 27/04/2017, at 12:02 AM, Mahmoud Murad wrote: > > Hi there, > The number 354162 has 6 digits and contains all digits from 1 to 6, and it can be considered as a multiplication of 3 * 54 = 162. > so what I need is a function that will take all the real number and return the number that can be split as above, > 354162 .. 3 * 54 = 162 > I have no idea how to do such a thing! any help! Start by spelling out just what the conditions are. - Are you looking specifically for 6-digit numbers or could it be more? (Because you say "ALL the real number[s]". - Are you sure you want REAL numbers and not INTEGERS? One way to read what you have written is - find a permutation [a,b,c,d,e,f] of [1,2,3,4,5,6] - such that a*(b*10+c) == (d*10+e)*10+f. There are only 6! = 720 permutations of six digits, so not a lot to check. For a computer program, I'd just code that. We can restructure this as - find three different digits 1 <= a,b,c <= 6 - compute def = a*(b*10+c) - check that the digits of def are all 1..6 and all different and different from a,b,c. There are 120 cases to check here. As it happens, Data.List provides permutations Prelude> import Data.List Prelude Data.List> permutations [1..3] [[1,2,3],[2,1,3],[3,2,1],[2,3,1],[3,1,2],[1,3,2]] Prelude Data.List> length (permutations [1..6]) 720 You can combine this with a list comprehension to get the numbers you want. From 14 at mniip.com Thu Apr 27 00:39:55 2017 From: 14 at mniip.com (mniip) Date: Thu, 27 Apr 2017 03:39:55 +0300 Subject: [Haskell-cafe] Partial type family application In-Reply-To: References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> Message-ID: <20170427003955.GA23783@mniip.com> On Wed, Apr 26, 2017 at 10:58:10AM -0400, Richard Eisenberg wrote: > The good news here is that this idea should be realizable independent from Dependent Haskell. It just needs someone to work out the details, propose, get community acceptance, and implement. But, from a theory point of view, I’m confident you’re describing the right direction to take all this in. I'm reading your thesis, and in it you propose to make all -> arrows unmatchable, and all constructors automagically get '-> arrows. Naturally, if we implement just this type extension, then it'd make sense to leave the -> arrow as is and introduce an ~> unmatchable arrow. However this makes transition to fully dependent arrows even more awkward. On the other hand we would have to pull the implicit '-> constructor arrows into this proposal, which makes it not so independent from dependent types, so still awkward. What do you think should be done? --mniip From rae at cs.brynmawr.edu Thu Apr 27 01:20:34 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 26 Apr 2017 21:20:34 -0400 Subject: [Haskell-cafe] Partial type family application In-Reply-To: <20170427003955.GA23783@mniip.com> References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> <20170427003955.GA23783@mniip.com> Message-ID: > On Apr 26, 2017, at 8:39 PM, mniip <14 at mniip.com> wrote: > > I'm reading your thesis, and in it you propose to make all -> arrows > unmatchable, and all constructors automagically get '-> arrows. Yes, that's what it says. > > Naturally, if we implement just this type extension, then it'd make > sense to leave the -> arrow as is and introduce an ~> unmatchable arrow. > However this makes transition to fully dependent arrows even more > awkward. But what *is* the (->) arrow? In a type describing a term, (->) describes an unmatchable function. In a kind describing a type, it describes a matchable function. And this is the tension. -XTypeInType means that types and kinds are the same, so this discrepancy is even stranger. It doesn't really bite, quite, but I very much think that any work in this direction should aim to have (->) be unequivocally unmatchable (because unmatchable functions are the vastly common case, taking both terms and types into account). As far as I can tell, a matchable -> occurs in Haskell today in kind signatures and the type signature of a GADT-style data constructor. These spots are easy to discern syntactically, so it's not hard to keep this legacy behavior in a brave new world with first-class matchable and unmatchable arrows. I would see phasing these out at some point -- it also wouldn't be hard to write a tool to automatically change current usage of arrows to the new one. But perhaps the community wouldn't want this (that is, phase out current usage), and that's fine too. Also: I have no strong opinions at all about the spelling of the new arrow. Using '-> had some nice similarity with other uses of ', but ~> is a notation I've also long considered. > > On the other hand we would have to pull the implicit '-> constructor > arrows into this proposal, which makes it not so independent from > dependent types, so still awkward. Yes, if we say that -> is always unmatchable, then the implicit treatment of -> in certain syntactic situations would have to become part of this proposal, making it a little harder to implement. And if we consider this proposal in the absence of dependent types, your choice of notation might make more sense. (To be clear, "your choice" is, as I understand: -> describes an unmatchable function in terms, -> describes a matchable function in types, and ~> describes an unmatchable function in types.) So I see how the possibility of dependent types colors this proposal. > > What do you think should be done? I still maintain the opinion I present in my thesis, that -> should always be unmatchable and some new symbol (I propose '->, but have no strong opinion) should always be matchable. We would have support for legacy uses of -> in kinds, perhaps disabled with -XCurriedTypeFamilies (just because -XUnsaturatedTypeFamilies isn't quite as tasty). That said, I can see the virtue of the opposing viewpoint and would happily debate this on a ghc-proposal. Richard From cdsmith at gmail.com Thu Apr 27 07:09:42 2017 From: cdsmith at gmail.com (Chris Smith) Date: Thu, 27 Apr 2017 00:09:42 -0700 Subject: [Haskell-cafe] [JOB] Summer contracting opportunity for CodeWorld Message-ID: Hello, Haskellers. I'm happy to announce a summer contracting opportunity helping to create documentation and educational materials for the CodeWorld project. CodeWorld (https://code.world) is a platform (and soon, a curriculum) for teaching mathematics via Haskell programming to children at the U.S. middle school level (ages 11-14). For more information about the CodeWorld project and its motivations, I can refer you to my recent BayHac presentation at https://youtu.be/7CGuI9HcfqQ Start: Early June End: Mid-August (but flexible) Full-time commitment Anticipated compensation: US$1500 / week Working remotely is expected, with the possibility of one week of required travel. As part of this position, you will work closely as a team with two other full-time writers to create detailed educational materials for use with the CodeWorld platform. You will be the team's expert on computer programming and the Haskell programming language. Other team members have expertise in mathematics education, and general and special needs education. The team's over-arching goal will be to produce objectives, instructional video scripts, visual aids, reference documentation (online and offline), pencil-and-paper activities, classroom activity planning, assessments, and any other resources necessary to support the success of this curriculum as a year-long class in schools. You should expect a typical day to include writing, editing and reviewing the content of others, planning objectives and content sequence, brainstorming activities and resources to help with content units, and some debate and consensus-building with the team on important design decisions. All artifacts produced during the job will be released under open source and/or Creative Commons licenses, suitable for use without charge by schools and organizations around the world. Qualifications: - Strong knowledge of Haskell programming language fundamentals. - Excellent writing and communication skills (in English), and in particular, an ability to explain technical ideas to an audience of beginners in a compelling way. - A mathematics and/or education background would be beneficial, but is not required. For this position, you will be a contractor for the New York Haskell User Group. Resumes can be sent to cdsmith at gmail.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg at okmij.org Thu Apr 27 10:42:19 2017 From: oleg at okmij.org (Oleg) Date: Thu, 27 Apr 2017 19:42:19 +0900 Subject: [Haskell-cafe] Partial type family application Message-ID: <20170427104219.GA4121@Magus.localnet> If the goal is to write higher-order type families, we can do that already -- and were able to do for a long time. For example, please see http://okmij.org/ftp/Haskell/TTypeable/TTypeable.hs that was written in 2012 for http://okmij.org/ftp/Haskell/typeEQ.html It shows the type-level function that checks for a membership in a type-level using the equality function supplied by a user as the first argument. Incidentally, here is the definition type instance Member f x NIL = HFalse type instance Member f x (h :/ t) = ORELSE (Apply f (x,h)) (CLOS AC_Member (f,x,t)) It was written before the modern syntax for type-level lists and booleans. This is an example of the general technique of defunctionalization. From 14 at mniip.com Thu Apr 27 17:34:32 2017 From: 14 at mniip.com (mniip) Date: Thu, 27 Apr 2017 20:34:32 +0300 Subject: [Haskell-cafe] Partial type family application In-Reply-To: References: <20170426122421.GB17944@mniip.com> <20170426122932.GA19211@mniip.com> <20170427003955.GA23783@mniip.com> Message-ID: <20170427173432.GA1521@mniip.com> On Wed, Apr 26, 2017 at 09:20:34PM -0400, Richard Eisenberg wrote: > But what *is* the (->) arrow? In a type describing a term, (->) describes an unmatchable function. In a kind describing a type, it describes a matchable function. And this is the tension. -XTypeInType means that types and kinds are the same, so this discrepancy is even stranger. It doesn't really bite, quite, but I very much think that any work in this direction should aim to have (->) be unequivocally unmatchable (because unmatchable functions are the vastly common case, taking both terms and types into account). After some more reading, I think I understand what you mean here. > As far as I can tell, a matchable -> occurs in Haskell today in kind signatures and the type signature of a GADT-style data constructor. Why is a GADT constructor's arrow matchable? A GADT constructor is indistinguishable from a term function in that you can't pattern-match partially applied constructors. > These spots are easy to discern syntactically, so it's not hard to keep this legacy behavior in a brave new world with first-class matchable and unmatchable arrows. I would see phasing these out at some point -- it also wouldn't be hard to write a tool to automatically change current usage of arrows to the new one. But perhaps the community wouldn't want this (that is, phase out current usage), and that's fine too. I could see that very easily being an issue, yes. Perhaps, if we consider unmatchable arrows as a supertype of matchable arrows, then we could secretly assign matchable arrows in the appropriate places even if an unmatchable arrow was written (why would anyone want an explicitly unmatchable arrow?) and not display them in type signatures until appropriate extensions are enabled. That would be backwards compatible with all current code, and the only place you'd need to use the new arrow would be a higher order type family. > Also: I have no strong opinions at all about the spelling of the new arrow. Using '-> had some nice similarity with other uses of ', but ~> is a notation I've also long considered. I don't either, and I came up with ~> in a few seconds. Honestly I don't know what a good candidate for it would be. '-> throws me off because it looks more like \hookrightarrow. > and would happily debate this on a ghc-proposal. On Wed, Apr 26, 2017 at 10:58:10AM -0400, Richard Eisenberg wrote: > The good news here is that this idea should be realizable independent from Dependent Haskell. It just needs someone to work out the details, propose, get community acceptance, and implement. But, from a theory point of view, I’m confident you’re describing the right direction to take all this in. Are you suggesting that this idea is worthy of a GHC proposal? From gershomb at gmail.com Fri Apr 28 02:40:05 2017 From: gershomb at gmail.com (Gershom B) Date: Thu, 27 Apr 2017 22:40:05 -0400 Subject: [Haskell-cafe] Looking for maintainers or comaintainers on my Haskell projects In-Reply-To: References: Message-ID: Did anyone offer to take over ircbrowse?  its currently failing as per:  https://github.com/chrisdone/ircbrowse/issues/27 Cheers, Gershom On February 28, 2017 at 12:22:26 PM, Christopher Done (chrisdone at gmail.com) wrote: > Hi all, > > The short version is: I’ve been battling RSI in my fingers for some years. > I’m doing various things to mitigate that problem, but I have very limited > finger bandwidth these days; enough to work at my usual pace at my job, but > not much in the evenings and weekends, and so I can’t manage to do much on > my hobby projects. I’m also not as motivated these days to work on my set > of open source projects, and am turning my attention to different things. > It’s not great, but that’s life. > > I don’t think that the users of my packages are getting the best > maintainership deal. Rather than be “the absentee maintainer”, I’d prefer a > straight-forward transition of maintainership or ownership to someone who > can put the right energy and time in. > > In terms of packages, there are really two that have a significant > maintenance burden and users aren’t being served very well: > > - HIndent has a significant > amount of issues opened for it regularly, and many of them require > discussion and debate. If someone would like to become a co-maintainer, let > me know. It may (eventually) make sense to move it to a more general GitHub > organization like commercialhaskell or haskell. > - Intero , which > seems to have been a success, has a pretty big maintenance burden on “this > doesn’t work” kind of issues which require investigation. There’s some > Emacs Lisp work to do on it, and some Haskell work on the intero binary, > and a whole lot of platform-specific problems or tooling not working > together. On the other hand people really like this project, and there’s a > lot of tooling potential. > > If you want to take xeno and make it > into a publishable package, please do so. > > The rest of my projects that are on Stackage are: labels > , ace > , ical > , check-email > , freenect > , frisby > , gd > , ini > , lucid > , osdkeys > , pdfinfo > , present > , pure-io > , scrobble > , shell-conduit > , sourcemap > , descriptive > , wrap > , path > , weigh > , haskell-docs > , and > structured-haskell-mode > . If you’re > interested in taking over or co-maintaining any of them, let me know. Some > are interesting, others are boring, some are trivial. > > I have other packages on Hackage, but they’re mostly dead or experiments > that don’t need maintenance anyway. > > I’ve started the process of adding or changing maintainers on my public > services: > > - Haskell News is now a GitHub > organization. Luke Murphy is a co-owner, and has full access to the > DigitalOcean account that is running the service. So if you want to work on > that project, I’m not in the way. > - lpaste has been moved to its own > DigitalOcean account too. If anyone is interested in taking over the > project or co-running it, let me know. > - tryhaskell doesn’t really > require any maintenance, but it’s also on its own DigitalOcean account now > too. > - IRCBrowse is now on its own > DigitalOcean account too. It requires maintenance once in a while. If > anyone is interested in taking over the project or co-running it, let me > know. > > Cheers! > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 S.J.Thompson at kent.ac.uk Fri Apr 28 08:50:56 2017 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Fri, 28 Apr 2017 09:50:56 +0100 Subject: [Haskell-cafe] Trends in Functional Programming in Education TFPIE 2017, Canterbury 22 June, SECOND CALL FOR PAPERS Message-ID: <801F8F64-AE0E-4C5F-8A08-11C7CDDEAAEC@kent.ac.uk> TFPIE 2017 Trends in Functional Programming in Education, 2017 https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ The sixth workshop on Trends in Functional Programming in Education, 2017, which is to be held on the Canterbury campus of the University of Kent on Thursday, 22 June, following the 2017 TFP meeting on 19–21 June. TFPIE workshops have previously been held in St Andrews, Scotland (2012), Provo Utah, USA (2013), Soesterberg, The Netherlands (2014), and Sophia-Antipolis, France (2015), College Park, USA (2016). A particular topic of this year's TFPIE will be MOOCs and other online learning, and as well as a session on this, we're looking forward to announcing a keynote speaker in this area very soon. The goal of TFPIE is to gather researchers, teachers and professionals that use, or are interested in the use of, functional programming in education. TFPIE aims to be a venue where novel ideas, classroom-tested ideas and work-in-progress on the use of functional programming in education are discussed. The one-day workshop will foster a spirit of open discussion by having a review process for publication after the workshop. The program chair of TFPIE 2017 will screen submissions to ensure that all presentations are within scope and are of interest to participants. After the workshop, presenters will be invited to submit revised versions of their articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Second call for papers TFPIE 2017 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: - FP and beginning CS students - FP and Computational Thinking - FP and Artificial Intelligence - FP in Robotics - FP and Music - Advanced FP for undergraduates - FP in graduate education - Engaging students in research using FP - FP in Programming Languages - FP in the high school curriculum - FP as a stepping stone to other CS topics - FP and Philosophy - The pedagogy of teaching FP - FP and e-learning: MOOCs, automated assessment etc. - Best Lectures – more details below In addition to papers, we are requesting best lecture presentations. What’s your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. Submission Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 16 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2017 After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles for publication in the journal Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Programme committee Dr Laura Castro, University of A Coruña Prof Ralf Lämmel, University of Koblenz-Landau Dr Elena Machkasova, University of Minnesota, Morris Prof Michel Mauny, Inria, Paris Dr Jeremy Singer, University of Glasgow Prof Simon Thompson, University of Kent (chair) Important dates Submissions of draft papers: 10 May, 2017 Notification: 17 May, 2017 Registration: 11 June, 2017 Workshop: 22 June 2017 Submission for formal review: 18 August, 2017 Notification of acceptance: 6 October, 2017 Camera ready paper: 3 November, 2017 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 From ramin.honary at gmail.com Fri Apr 28 10:14:36 2017 From: ramin.honary at gmail.com (Ramin Honary) Date: Fri, 28 Apr 2017 19:14:36 +0900 Subject: [Haskell-cafe] Should I report a bug on GHC 7.10.3, or is it past it's end-of-life? Message-ID: I'm getting an "internal error: evacuate: strange closure type" in GHC 7.10.3. Should I report it? Would it even do any good? It doesn't seem there is any more development on the 7.10 branch anymore. If it is still being developed, should I try updating my GHC to a more recent build of 7.10.3? Looking at the core dump file, it appears to be a problem in the garbage collector. I've done a bit of work trying get around the bug, including using -dcore-lint and -O0, and updating my dependency libraries, and I can still reproduce the issue very regularly in my own environment by calling a single method in my code base, either in GHCi or in a compiled binary test program. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Apr 28 10:22:17 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 28 Apr 2017 11:22:17 +0100 Subject: [Haskell-cafe] Should I report a bug on GHC 7.10.3, or is it past it's end-of-life? In-Reply-To: References: Message-ID: You should try the latest version. There are quite a few reports of errors like this for 7.10 on the issue tracker but seems like they are resolved in 8.0. On Fri, Apr 28, 2017 at 11:14 AM, Ramin Honary wrote: > I'm getting an "internal error: evacuate: strange closure type" in GHC > 7.10.3. Should I report it? Would it even do any good? It doesn't seem there > is any more development on the 7.10 branch anymore. If it is still being > developed, should I try updating my GHC to a more recent build of 7.10.3? > > Looking at the core dump file, it appears to be a problem in the garbage > collector. I've done a bit of work trying get around the bug, including > using -dcore-lint and -O0, and updating my dependency libraries, and I can > still reproduce the issue very regularly in my own environment by calling a > single method in my code base, either in GHCi or in a compiled binary test > program. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From david.feuer at gmail.com Fri Apr 28 16:08:19 2017 From: david.feuer at gmail.com (David Feuer) Date: Fri, 28 Apr 2017 12:08:19 -0400 Subject: [Haskell-cafe] Should I report a bug on GHC 7.10.3, or is it past it's end-of-life? In-Reply-To: References: Message-ID: To answer the original question, 7.10 is done; there will not be a 7.10.4. If you find bugs in 7.10 and can't test them in 8.0, you can still file them. Reporting bugs in pre-7.10 versions that can't be reproduced in more recent versions is not likely to be useful. On Fri, Apr 28, 2017 at 6:14 AM, Ramin Honary wrote: > I'm getting an "internal error: evacuate: strange closure type" in GHC > 7.10.3. Should I report it? Would it even do any good? It doesn't seem there > is any more development on the 7.10 branch anymore. If it is still being > developed, should I try updating my GHC to a more recent build of 7.10.3? > > Looking at the core dump file, it appears to be a problem in the garbage > collector. I've done a bit of work trying get around the bug, including > using -dcore-lint and -O0, and updating my dependency libraries, and I can > still reproduce the issue very regularly in my own environment by calling a > single method in my code base, either in GHCi or in a compiled binary test > program. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 gtener at gmail.com Fri Apr 28 17:33:40 2017 From: gtener at gmail.com (=?UTF-8?Q?Krzysztof_Skrz=C4=99tnicki?=) Date: Fri, 28 Apr 2017 19:33:40 +0200 Subject: [Haskell-cafe] bounty for vty on Windows In-Reply-To: <5E336F76-3909-4A6D-BDF5-FE048FE3D341@joyful.com> References: <5E336F76-3909-4A6D-BDF5-FE048FE3D341@joyful.com> Message-ID: Hi, Possibly related are the console changes introduced with Windows 10 Creators Update. A lot of compat issues are said to be resolved. See https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ for details. Thanks, Krzysztof On Tue, Apr 25, 2017 at 10:03 PM, Simon Michael wrote: > Hi all, > > vty is a nice full-screen curses-style API, and the basis for the nice > higher-level brick TUI (text UI) framework, that builds on POSIX platforms > only. All agree that it would be nice to make it work on Windows too. This > would allow building cross-platform TUIs with haskell. Also there are > things in vty, such as the Graphics.Vty.Attributes, that would be useful > for CLIs too. > > I summarised current status and have kicked off a bounty towards getting > Windows support added to the vty lib. I'm sending this to raise interest > and invite your help, be you a person with a Windows machine, a potential > bounty donor, or someone interested in improving Haskell's portability and > applicability. > > https://github.com/jtdaugherty/vty/pull/1#issuecomment-297143444 > > My particular interest is in making hledger-ui[1] cross platform, and in > being able to use vty's higher-level terminal styles in CLI tools on all > platforms. > > Best! > Simon > > [1] *http://hledger.org/hledger-ui.html > * > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 evincarofautumn at gmail.com Fri Apr 28 18:13:31 2017 From: evincarofautumn at gmail.com (Jon Purdy) Date: Fri, 28 Apr 2017 11:13:31 -0700 Subject: [Haskell-cafe] Should I report a bug on GHC 7.10.3, or is it past it's end-of-life? In-Reply-To: References: Message-ID: For what it’s worth, I think it’s a good idea to file some bugs for recent old versions, even with the understanding that they won’t be fixed. It gives someone who has yet to update (for whatever reason) some chance of finding a definitive source that the bug doesn’t manifest in a newer version, giving them a concrete case to upgrade. On Apr 28, 2017 09:10, "David Feuer" wrote: To answer the original question, 7.10 is done; there will not be a 7.10.4. If you find bugs in 7.10 and can't test them in 8.0, you can still file them. Reporting bugs in pre-7.10 versions that can't be reproduced in more recent versions is not likely to be useful. On Fri, Apr 28, 2017 at 6:14 AM, Ramin Honary wrote: > I'm getting an "internal error: evacuate: strange closure type" in GHC > 7.10.3. Should I report it? Would it even do any good? It doesn't seem there > is any more development on the 7.10 branch anymore. If it is still being > developed, should I try updating my GHC to a more recent build of 7.10.3? > > Looking at the core dump file, it appears to be a problem in the garbage > collector. I've done a bit of work trying get around the bug, including > using -dcore-lint and -O0, and updating my dependency libraries, and I can > still reproduce the issue very regularly in my own environment by calling a > single method in my code base, either in GHCi or in a compiled binary test > program. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 simon at joyful.com Fri Apr 28 19:50:21 2017 From: simon at joyful.com (Simon Michael) Date: Fri, 28 Apr 2017 12:50:21 -0700 Subject: [Haskell-cafe] bounty for vty on Windows In-Reply-To: References: <5E336F76-3909-4A6D-BDF5-FE048FE3D341@joyful.com> Message-ID: Thanks, I will add that to the issue page if you don't get there first. Best, -Simon > On Apr 28, 2017, at 10:33 AM, Krzysztof Skrzętnicki wrote: > > Hi, > > Possibly related are the console changes introduced with Windows 10 Creators Update. A lot of compat issues are said to be resolved. See https://blogs.msdn.microsoft.com/commandline/2017/04/11/windows-10-creators-update-whats-new-in-bashwsl-windows-console/ for details. > > Thanks, > Krzysztof > > On Tue, Apr 25, 2017 at 10:03 PM, Simon Michael > wrote: > Hi all, > > vty is a nice full-screen curses-style API, and the basis for the nice higher-level brick TUI (text UI) framework, that builds on POSIX platforms only. All agree that it would be nice to make it work on Windows too. This would allow building cross-platform TUIs with haskell. Also there are things in vty, such as the Graphics.Vty.Attributes, that would be useful for CLIs too. > > I summarised current status and have kicked off a bounty towards getting Windows support added to the vty lib. I'm sending this to raise interest and invite your help, be you a person with a Windows machine, a potential bounty donor, or someone interested in improving Haskell's portability and applicability. > > https://github.com/jtdaugherty/vty/pull/1#issuecomment-297143444 > > My particular interest is in making hledger-ui[1] cross platform, and in being able to use vty's higher-level terminal styles in CLI tools on all platforms. > > Best! > Simon > > [1] http://hledger.org/hledger-ui.html > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 hjgtuyl at chello.nl Fri Apr 28 20:09:46 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 28 Apr 2017 22:09:46 +0200 Subject: [Haskell-cafe] ANN: wxHaskell 0.92.3.0 Message-ID: L.S., I am happy to announce a new version of wxHaskell: 0.92.3.0 Windows users can still use wxInstall Achelanne 0.1 to install this new version of wxHaskell.[0][1] Changes in wxHaskell since 0.92.2: - Improvements for compilation on BSD platform - Improved commandline handling - Sample program PaintGC.hs added - Compilation can now be done with an alternative wx-config.exe - Simplification of Windows build process with Stack - Several bugs solved Thanks to everyone who contributed! What is wxHaskell? ------------------ wxHaskell[2] is a portable and native GUI library for Haskell. The goal of the project is to provide an industrial strength GUI library for Haskell, but without the burden of developing (and maintaining) one ourselves. wxHaskell is therefore built on top of wxWidgets[3] – a comprehensive C++ library that is portable across all major GUI platforms; including GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library (in development since 1992) that supports a wide range of widgets with the native look-and-feel. Links ----- See the homepage of wxHaskell for more information: https://wiki.haskell.org/WxHaskell Repository: https://github.com/wxHaskell/wxHaskell Tickets: https://sourceforge.net/p/wxhaskell/_list/tickets The packages are: - wxc https://hackage.haskell.org/package/wxc - wxdirect https://hackage.haskell.org/package/wxdirect - wxcore https://hackage.haskell.org/package/wxcore - wx https://hackage.haskell.org/package/wx Regards, Henk-Jan van Tuyl [0] http://sourceforge.net/projects/wxhaskell/files/wxInstall/ [1] https://wiki.haskell.org/WxHaskell/Windows#Installing_the_easy_way [2] https://wiki.haskell.org/WxHaskell [3] https://wxwidgets.org/ -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From emertens at gmail.com Fri Apr 28 23:52:51 2017 From: emertens at gmail.com (Eric Mertens) Date: Fri, 28 Apr 2017 23:52:51 +0000 Subject: [Haskell-cafe] th-abstraction: A new library for inspecting datatypes from Template Haskell Message-ID: Hello, I've uploaded a new library to Hackage that helps normalize the information one can get by reifying the type constructor of a type declared with data or newtype. https://hackage.haskell.org/package/th-abstraction https://github.com/glguy/th-abstraction I've found that I was duplicating a lot of code when trying to maintain compatibility across a range of Template Haskell versions when using the 'reify' operation. Currently I'm testing against GHC versions as old as 7.4.2 and as new as 8.2.1-rc1. This package eliminates some of the noise that comes from reify's syntax-oriented constructors and eliminates the differences across normal and GADT syntax. I expect to add more Template Haskell functionality to this package over time as needed with a focus on being able to maintain compatibility across a wide range of template-haskell package versions. I hope others are able to find it useful! Best regards, Eric Mertens "glguy" -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Apr 29 01:13:24 2017 From: gershomb at gmail.com (Gershom B) Date: Fri, 28 Apr 2017 21:13:24 -0400 Subject: [Haskell-cafe] Cabal and IPv6 In-Reply-To: References: Message-ID: Good question! At the moment we don’t have ipv6 enabled on our cdn — it looks like it was only recently made available to configure that way for general use [1]. I’ve talked to other admins, and I hope we can just turn on the switch and have it work going forward. Until then, here’s the ipv6 address of the current origin hackage server, which can perhaps be used in the meantime? 2001:4800:7821:103:be76:4eff:fe04:b11a [1] https://www.fastly.com/blog/ipv6-fastly Cheers, Gershom On April 26, 2017 at 5:43:37 PM, Serguey Zefirov (sergueyz at gmail.com) wrote: > I have found that Cabal does not work on IPv6-only networks (which my > machine happen to be part of). > > The problem is basically this: "ping hackage.haskell.org" does not resolve > host while "ping6 hackage.haskell.org" does. Thus cabal cannot do anything > useful on that machine. > > Do anyone have a solution for that? I was unable to find any on the > internet. ;) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From jo at durchholz.org Sat Apr 29 05:58:10 2017 From: jo at durchholz.org (jo at durchholz.org) Date: Sat, 29 Apr 2017 07:58:10 +0200 Subject: [Haskell-cafe] Cabal and IPv6 In-Reply-To: References: Message-ID: ping doesn't seem to have an ip-version-agnostic setting. cabal could try both ping and ping6. Question is: Why does cabal even require ping? pinging a host is useful in network monitoring, but I have yet to see a situation where it is even helpful to establish a connection. > Good question! At the moment we don’t have ipv6 enabled on our cdn — > it looks like it was only recently made available to configure that way > for general use [1]. I’ve talked to other admins, and I hope we can just > turn on the switch and have it work going forward. Until then, here’s > the ipv6 address of the current origin hackage server, which can perhaps > be used in the meantime? > > 2001:4800:7821:103:be76:4eff:fe04:b11a > > [1] https://www.fastly.com/blog/ipv6-fastly > > Cheers, > Gershom > > On April 26, 2017 at 5:43:37 PM, Serguey Zefirov (sergueyz at gmail.com) > wrote: >> I have found that Cabal does not work on IPv6-only networks (which my >> machine happen to be part of). >> >> The problem is basically this: "ping hackage.haskell.org" does not >> resolve >> host while "ping6 hackage.haskell.org" does. Thus cabal cannot do >> anything >> useful on that machine. >> >> Do anyone have a solution for that? I was unable to find any on the >> internet. ;) >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From hvriedel at gmail.com Sat Apr 29 07:11:33 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Sat, 29 Apr 2017 09:11:33 +0200 Subject: [Haskell-cafe] Cabal and IPv6 In-Reply-To: References: Message-ID: Hello! While the primary upstream doesn't have an AAAA record, one of the mirrors[1] does have a fully functioning AAAA record, and I'd expect hackage-security's mirror fallback logic to fallback to that one. If you're using a recent cabal 1.24, you will have to enable the hackage-security capable transport by enabling the "secure" repos by making sure the "secure: True" line is active like so in your ~/.cabal/config repository hackage.haskell.org url: http://hackage.haskell.org/ secure: True Starting with the soon to be released cabal 2.0 version, hackage-security is enabled by default. If this still doesn't work for you, please file an issue at https://github.com/haskell/cabal/issues [1]: http://objects-us-west-1.dream.io/hackage-mirror/" On Wed, Apr 26, 2017 at 11:42 PM, Serguey Zefirov wrote: > I have found that Cabal does not work on IPv6-only networks (which my > machine happen to be part of). > > The problem is basically this: "ping hackage.haskell.org" does not resolve > host while "ping6 hackage.haskell.org" does. Thus cabal cannot do anything > useful on that machine. > > Do anyone have a solution for that? I was unable to find any on the > internet. ;) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 brucker at spamfence.net Sat Apr 29 15:01:21 2017 From: brucker at spamfence.net (Achim D. Brucker) Date: Sat, 29 Apr 2017 16:01:21 +0100 Subject: [Haskell-cafe] Deadline Extension: International Workshop on OCL and Textual Modeling (OCL 2017) Message-ID: <20170429150121.mp3djvyfh3y7smfo@fujikawa.home.brucker.ch> (Apologies for duplicates) New Deadline: May 7, 2017 CALL FOR PAPERS 17th International Workshop on OCL and Textual Modeling Co-located with STAF 2017 SOFTWARE TECHNOLOGIES: APPLICATIONS AND FOUNDATIONS July 20, 2017, Marburg, Germany http://oclworkshop.github.io Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but they have weaknesses: for example, detailed visual representations bear the risk of becoming overcrowded faster than textual models and some of the visual features lack the level of precision required to create complete and unambiguous specifications. These weaknesses of graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Venue This workshop will be organized as a part of STAF 2017 Conferenze in Marburg, Germany. It was previously organized as part of the MODELS conference. Similar to its predecessors , the workshop addresses both people from academia and industry . The aim is to provide a forum for addressing integration of OCL and other textual modeling languages , as well as tools for textual modeling , and for disseminating good practice and discussing the new requirements for textual modeling . ## Workshop Format The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. ## Submissions Two types of papers will be considered: * Short contributions (between 6 and 8 pages) describing new ideas, innovative tools or position papers. * Full papers (between 12 and 16 pages). in LNCS format. Submissions should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2017). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a post-conference edition of [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: May 7, 2017 (extended) - Notification: May 25, 2017 - Workshop date: July 20, 2017 -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From alan.zimm at gmail.com Sat Apr 29 16:40:41 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 29 Apr 2017 18:40:41 +0200 Subject: [Haskell-cafe] State of Haskell IDE Engine Message-ID: Some of you have been wondering what has happened to the haskell-ide-engine[1], and whether it may perhaps have died. Development has resumed, based mainly on the existence of an enabling technology in the Language Server Protocol[2] which is starting to have implementations for IDEs and Languages[3]. It was always the intention to leverage off common infrastructure at the IDE side, and this protocol is making that possible. The current state for haskell-ide-engine is that support is provided in master[4], which has been tested in emacs using[5] (and [6] until the branch is merged). It is also tested against vscode[7] using the vscode-hie-server plugin[8]. Current features include - diagnostics provided via hlint and ghc-mod (using flycheck in emacs) - hover support giving the type under the cursor - ability to apply hlint suggestions as codeActions, via apply-refact - HaRe refactorings exposed in the emacs version. The vscode plugin lags in this, my skills are limited There is a lot of development happening on the emacs lsp-mode, as it benefits many languages, not just haskell, and so developers from other languages are also contributing. The LSP support for haskell-ide-engine is supplied by a separate library[9] which is being used in at least 3 other LSP servers to my knowledge. These will be made public when/if it suits their creators to do so. The general plan going forward is to focus HIE on being an LSP server. Other transports will not be removed, but the driving paradigm will be LSP support. The longer term plan is to use this as a platform to drive more interactivity back into GHC, starting with exploring incremental parsing driven by the document change notifications provided in the LSP protocol, and supported in haskell-lsp[9]. Alan [1] https://github.com/haskell/haskell-ide-engine/issues/218 [2] https://github.com/Microsoft/language-server-protocol [3] https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations [4] https://github.com/haskell/haskell-ide-engine [5] https://github.com/alanz/lsp-haskell [6] https://github.com/alanz/lsp-mode/tree/project-ask [7] http://code.visualstudio.com/ [8] https://github.com/alanz/vscode-hie-server [9] https://github.com/alanz/haskell-lsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Sat Apr 29 21:34:05 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sat, 29 Apr 2017 21:34:05 +0000 Subject: [Haskell-cafe] State of Haskell IDE Engine In-Reply-To: References: Message-ID: I'm very glad to hear this, huge thanks for taking the time to work on this! One question: why does the haskell LSP require a separate plugin? I thought LSP was meant to not require any editor plugins to use a different backend? Alan & Kim Zimmerman schrieb am Sa., 29. Apr. 2017 um 18:43 Uhr: > Some of you have been wondering what has happened to the > haskell-ide-engine[1], > and whether it may perhaps have died. > > Development has resumed, based mainly on the existence of an enabling > technology > in the Language Server Protocol[2] which is starting to have > implementations > for IDEs and Languages[3]. > > It was always the intention to leverage off common infrastructure at the > IDE > side, and this protocol is making that possible. > > The current state for haskell-ide-engine is that support is provided in > master[4], which has been tested in emacs using[5] (and [6] until the > branch is > merged). > > It is also tested against vscode[7] using the vscode-hie-server plugin[8]. > > Current features include > > - diagnostics provided via hlint and ghc-mod (using flycheck in emacs) > - hover support giving the type under the cursor > - ability to apply hlint suggestions as codeActions, via apply-refact > - HaRe refactorings exposed in the emacs version. The vscode plugin lags > in > this, my skills are limited > > There is a lot of development happening on the emacs lsp-mode, as it > benefits > many languages, not just haskell, and so developers from other languages > are > also contributing. > > The LSP support for haskell-ide-engine is supplied by a separate library[9] > which is being used in at least 3 other LSP servers to my knowledge. These > will > be made public when/if it suits their creators to do so. > > The general plan going forward is to focus HIE on being an LSP server. > Other > transports will not be removed, but the driving paradigm will be LSP > support. > > The longer term plan is to use this as a platform to drive more > interactivity > back into GHC, starting with exploring incremental parsing driven by the > document change notifications provided in the LSP protocol, and supported > in > haskell-lsp[9]. > > Alan > > [1] https://github.com/haskell/haskell-ide-engine/issues/218 > [2] https://github.com/Microsoft/language-server-protocol > [3] > https://github.com/Microsoft/language-server-protocol/wiki/Protocol-Implementations > [4] https://github.com/haskell/haskell-ide-engine > [5] https://github.com/alanz/lsp-haskell > [6] https://github.com/alanz/lsp-mode/tree/project-ask > [7] http://code.visualstudio.com/ > [8] https://github.com/alanz/vscode-hie-server > [9] https://github.com/alanz/haskell-lsp > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Sat Apr 29 21:42:43 2017 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 29 Apr 2017 23:42:43 +0200 Subject: [Haskell-cafe] State of Haskell IDE Engine In-Reply-To: References: Message-ID: It needs a plugin at the IDE to tell it that there is a language server, and how to start it. I was hoping that could be done by configuration, but it appears not. Also, support for registering server-specific commands (such as HaRe refactorings) is still immature. Hopefully this will improve in future, there are some issues under discussion for it[1] Alan [1] https://github.com/Microsoft/language-server-protocol/issues/61 On 29 April 2017 at 23:34, Benno Fünfstück wrote: > I'm very glad to hear this, huge thanks for taking the time to work on > this! > > One question: why does the haskell LSP require a separate plugin? I > thought LSP was meant to not require any editor plugins to use a different > backend? > > Alan & Kim Zimmerman schrieb am Sa., 29. Apr. 2017 > um 18:43 Uhr: > >> Some of you have been wondering what has happened to the >> haskell-ide-engine[1], >> and whether it may perhaps have died. >> >> Development has resumed, based mainly on the existence of an enabling >> technology >> in the Language Server Protocol[2] which is starting to have >> implementations >> for IDEs and Languages[3]. >> >> It was always the intention to leverage off common infrastructure at the >> IDE >> side, and this protocol is making that possible. >> >> The current state for haskell-ide-engine is that support is provided in >> master[4], which has been tested in emacs using[5] (and [6] until the >> branch is >> merged). >> >> It is also tested against vscode[7] using the vscode-hie-server plugin[8]. >> >> Current features include >> >> - diagnostics provided via hlint and ghc-mod (using flycheck in emacs) >> - hover support giving the type under the cursor >> - ability to apply hlint suggestions as codeActions, via apply-refact >> - HaRe refactorings exposed in the emacs version. The vscode plugin >> lags in >> this, my skills are limited >> >> There is a lot of development happening on the emacs lsp-mode, as it >> benefits >> many languages, not just haskell, and so developers from other languages >> are >> also contributing. >> >> The LSP support for haskell-ide-engine is supplied by a separate >> library[9] >> which is being used in at least 3 other LSP servers to my knowledge. >> These will >> be made public when/if it suits their creators to do so. >> >> The general plan going forward is to focus HIE on being an LSP server. >> Other >> transports will not be removed, but the driving paradigm will be LSP >> support. >> >> The longer term plan is to use this as a platform to drive more >> interactivity >> back into GHC, starting with exploring incremental parsing driven by the >> document change notifications provided in the LSP protocol, and supported >> in >> haskell-lsp[9]. >> >> Alan >> >> [1] https://github.com/haskell/haskell-ide-engine/issues/218 >> [2] https://github.com/Microsoft/language-server-protocol >> [3] https://github.com/Microsoft/language-server-protocol/wiki/ >> Protocol-Implementations >> [4] https://github.com/haskell/haskell-ide-engine >> [5] https://github.com/alanz/lsp-haskell >> [6] https://github.com/alanz/lsp-mode/tree/project-ask >> [7] http://code.visualstudio.com/ >> [8] https://github.com/alanz/vscode-hie-server >> [9] https://github.com/alanz/haskell-lsp >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Apr 30 04:02:46 2017 From: ben at well-typed.com (Ben Gamari) Date: Sun, 30 Apr 2017 00:02:46 -0400 Subject: [Haskell-cafe] State of Haskell IDE Engine In-Reply-To: References: Message-ID: <87tw56ee55.fsf@ben-laptop.smart-cactus.org> Alan & Kim Zimmerman writes: > Some of you have been wondering what has happened to the > haskell-ide-engine[1], and whether it may perhaps have died. > > Development has resumed, based mainly on the existence of an enabling > technology in the Language Server Protocol[2] which is starting to > have implementations for IDEs and Languages[3]. > I'm really happy that this effort is still underway. I'm also quite happy to hear that we will be able to build on LSP. last summer at Zurihac Simon Meier was very excited about the potential of LSP. Hopefully HIE will be the project he was hoping for. What is the state of LSP support in the vim/emacs worlds? I suppose haskell-mode will need to learn to speak the protocol? Thanks Alan! 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 ketil at malde.org Sun Apr 30 07:44:09 2017 From: ketil at malde.org (Ketil Malde) Date: Sun, 30 Apr 2017 09:44:09 +0200 Subject: [Haskell-cafe] hash map/associative structure Message-ID: <87fugq2vcm.fsf@malde.org> Hi, I've been using Judy arrays as a fast and even more importatnly, compact associative structure. Infortunately, I'm getting occasional segfaults, and I'm unable to find anything wrong with my code. Others also report something similar. The Debian maintainer of libjudy made a version without some dubious optimizations, but that didn't help...at least not substantially. So the question is, what is a good replacement? I just need Word64 -> Integral, but again, I expect to fill all of main memory with data, so memory compactness is important. Anything using trees and boxed values (e.g. Data.IntMap and friends) out. I only need to be able to insert, modify (add one), and finally extract the key-value pairs (e.g. 'elems'). Any suggestions? -k -- If I haven't seen further, it is by standing in the footprints of giants From julian at getcontented.com.au Sun Apr 30 12:35:05 2017 From: julian at getcontented.com.au (Julian Leviston) Date: Sun, 30 Apr 2017 22:35:05 +1000 Subject: [Haskell-cafe] How can I find out which functions can be run on an expression? In-Reply-To: References: Message-ID: <3CDC41AD-73F2-4E98-B0F3-F841761DF4DA@getcontented.com.au> I'd like to programmatically find out which functions in a module could possibly apply to a particular expression. I also posted this to stack overflow. To make this concrete: {-# LANGUAGE TemplateHaskell #-} module Test where -- we'll import template-haskell from Lens -- so we can create prisms automatically for our 'AST' import qualified Control.Lens.TH as LTH --- some 'AST' in a toy language data CExp = CLit Int -- a literal integer | CAdd CExp CExp -- addition | CMul CExp CExp -- multiplication | CSub CExp CExp -- subtraction deriving Show -- an eval for our AST eval :: CExp -> Int eval exp = case exp of CLit i -> i CAdd e1 e2 -> eval e1 + eval e2 CMul e1 e2 -> eval e1 * eval e2 CSub e1 e2 -> eval e1 - eval e2 -- a function to build a sum using add with our AST, from a list of Int values listToSums :: [Int] -> CExp listToSums = foldr CAdd (CLit 0) . fmap CLit -- here we make prisms for looking at particular values -- in the CExp AST LTH.makePrisms ''CExp -- let's have an expression: theList1 :: CExp theList1 = listToSums [1..38] Now, at this point, I'd like a function that can give me a list of all the top level functions of a particular module (including this one) that are able to be applied to the expression theList1. This will include the prisms that were created with makePrisms. It would be fine if it uses the hint library's Interpreter monad. I've been experimenting with it a bit, and while I can get a list of all of the definitions at the top level of any module, and I can find the types of them, too (more or less), I'm a bit lost about how to pass an expression in as an argument to these functions then check if that exprssions will typecheck. If I can do that, I can run filter across all of the functions in a module, which lets me find out which ones are applicable. Many thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg7mdp at gmail.com Sun Apr 30 13:31:10 2017 From: greg7mdp at gmail.com (Gregory Popovitch) Date: Sun, 30 Apr 2017 09:31:10 -0400 Subject: [Haskell-cafe] hash map/associative structure In-Reply-To: <87fugq2vcm.fsf@malde.org> References: <87fugq2vcm.fsf@malde.org> Message-ID: <479827232770420287AF675EB0DF9038@gregava> My sparsepp (https://github.com/greg7mdp/sparsepp) is very compact (low memory usage) and pretty fast, but it doesn't have Haskell bindings. It is a hash map built on a sparse array. Thanks, greg -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Ketil Malde Sent: Sunday, April 30, 2017 3:44 AM To: haskell-cafe at haskell.org; biohaskell at biohaskell.org Subject: [Haskell-cafe] hash map/associative structure Hi, I've been using Judy arrays as a fast and even more importatnly, compact associative structure. Infortunately, I'm getting occasional segfaults, and I'm unable to find anything wrong with my code. Others also report something similar. The Debian maintainer of libjudy made a version without some dubious optimizations, but that didn't help...at least not substantially. So the question is, what is a good replacement? I just need Word64 -> Integral, but again, I expect to fill all of main memory with data, so memory compactness is important. Anything using trees and boxed values (e.g. Data.IntMap and friends) out. I only need to be able to insert, modify (add one), and finally extract the key-value pairs (e.g. 'elems'). Any suggestions? -k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.