From dedgrant at gmail.com Tue Aug 1 01:00:32 2017 From: dedgrant at gmail.com (Darren Grant) Date: Mon, 31 Jul 2017 18:00:32 -0700 Subject: [Haskell-cafe] Many packages blocked on Stackage nightly for GHC 8.2.1 In-Reply-To: References: Message-ID: Thank you for continuing to take on this communication work, curators and authors. The responsiveness has been phenomenal. Cheers, Darren On Jul 31, 2017 14:15, "Dan Burton" wrote: > Please be advised that many packages were dropped from the Stackage > nightly build plan in order to arrive at a successful build with the new > ghc. (Note that this does not affect the build plans for LTS 9.) This is to > be expected whenever ghc gets a major version bump. For details, see: > https://github.com/fpco/stackage/blob/master/MAINTAINERS.md > > We have attempted to contact package authors whose packages were dropped. > However, comprehensive notification is not fully automated, and there may > be many who have not been directly contacted. You can check your section of > build-constraints.yaml, as well as stackage.org/nightly, to see which of > your packages are currently absent from the build plan. > > You may restore your packages to the nightly build plan (once they are > buildable with ghc 8.2.1) in the same way they were added: by opening a PR, > uncommenting your packages in build-constraints.yaml. > > Thank you for your efforts to keep the Haskell ecosystem up to date. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olshanskydr at gmail.com Tue Aug 1 08:06:27 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Tue, 1 Aug 2017 11:06:27 +0300 Subject: [Haskell-cafe] Problems with Type family and Typeable In-Reply-To: References: <60512fb0-2f2e-0a42-a609-cc28c5ae3d8b@gmail.com> Message-ID: I didn't see any blog post or something else about it. But I had such experience: non-lazy type level if type-level Fib 2017-07-31 20:13 GMT+03:00 Kai Zhang : > Dmitry, where did you learn this? Is there a blog post that I can read? > Thanks! > > > On Mon, Jul 31, 2017 at 6:15 AM Dmitry Olshansky > wrote: > >> Additionally, as I understand now, you will have better compile-time >> performance if write >> >> type Elem x xs = Elem' 'False x xs >> >> type family Elem' (b::Bool) x xs :: Bool where >> Elem' 'True _ _ = 'True >> Elem' 'False a (x ': xs) = Elem' (a == x) a xs >> Elem' 'False _ '[] = 'False >> >> All type calculation is not enough lazy! >> >> 2017-07-31 15:41 GMT+03:00 Li-yao Xia : >> >>> Hello, >>> >>> >>> "Data.Type.Equality.EqStar s t || Elem s ts" resolves to True or False, >>> which are values of type Bool. >>> To understand why that constraint can't be solved, think about how such >>> a function is compiled. At run time, types are erased. >>> A "Proxy p" value carries no more information than unit "()", and a >>> "Tagged _ a" value is in fact just an "a" value. >>> So elemTag is compiled to something equivalent to a function of this >>> type, which has no way of performing the comparison you requested since the >>> type-level boolean was erased: >>> >>> -- Original function >>> elemTag :: Proxy s -> Tagged (t ': ts) a -> Bool >>> >>> -- After type erasure >>> elemTag :: () -> a -> Bool >>> >>> As suggested by the type error, you can reify the boolean "Elem s (t ': >>> ts)" by adding a Typeable constraint, which gets compiled to an additional >>> run time argument. >>> >>> elemTag :: forall a s t ts >>> . Typeable (Elem s (t ': ts)) >>> => Proxy s >>> -> Tagged (t ': ts) a >>> -> Bool >>> >>> >>> Li-yao >>> >>> >>> >>> >>> On 07/31/2017 07:15 AM, Kai Zhang wrote: >>> >>>> I got an error when compiling the following codes: >>>> >>>> {-# LANGUAGE TypeOperators #-} >>>> {-# LANGUAGE DataKinds #-} >>>> {-# LANGUAGE TypeFamilies #-} >>>> {-# LANGUAGE ScopedTypeVariables #-} >>>> {-# LANGUAGE UndecidableInstances #-} >>>> >>>> import Data.Type.Bool >>>> import Data.Type.Equality >>>> import Data.Tagged (Tagged(..)) >>>> import Data.Typeable >>>> >>>> type family Elem x xs :: Bool where >>>> Elem _ '[] = 'False >>>> Elem a (x ': xs) = a == x || Elem a xs >>>> >>>> elemTag :: forall a s t ts . Proxy s >>>> -> Tagged (t ': ts) a -> Bool >>>> elemTag _ _ = if typeOf (Proxy :: Proxy (Elem s (t ': ts))) == typeOf >>>> (Proxy :: Proxy 'True) >>>> then True >>>> else False >>>> >>>> GHC says: >>>> >>>> • No instance for (Typeable >>>> (Data.Type.Equality.EqStar s t || Elem s ts)) >>>> arising from a use of ‘typeOf’ >>>> • In the first argument of ‘(==)’, namely >>>> ‘typeOf (Proxy :: Proxy (Elem s (t : ts)))’ >>>> In the expression: >>>> typeOf (Proxy :: Proxy (Elem s (t : ts))) >>>> == typeOf (Proxy :: Proxy True) >>>> In the expression: >>>> if typeOf (Proxy :: Proxy (Elem s (t : ts))) >>>> == typeOf (Proxy :: Proxy True) then >>>> True >>>> else >>>> False >>>> >>>> My question: why is ghc unable to deduce that >>>> "Data.Type.Equality.EqStar s >>>> t || Elem s ts" resolves to "Bool" which should be an instance of >>>> Typeable? >>>> How to fix this? >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view 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 clintonmead at gmail.com Wed Aug 2 12:05:44 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Wed, 2 Aug 2017 22:05:44 +1000 Subject: [Haskell-cafe] What code is generated for binary functions of data types with multiple constructors? Message-ID: Assume the following: 1. We have a type T with multiple constructors, but lets assume we're on a 64 bit machine and have at least 4 but no more than 7 constructors so we can still use pointer tagging. 2. And a function "f :: T -> T -> T" 3. Each combination of constructors (16 in the 4 constructor case, 49 in the 7 constructor case) has an implementation (naturally many of these will call helper functions). There's no wildcard matches. How will GHC generate the code for "f"? Will pushing through LLVM make any difference? Do we take the number of the first constructor, and then multiply the number of the second constructor by say 7, and then do one jump via a jump table? Is there a bunch of nested jump tables, each with 7 options? Is there a fall through if statement? Something else? I understand this probably a complex answer and perhaps doesn't have a simple answer, but I just wanted to get some sort of idea in my head of how GHC attempts to resolve code like this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at smallbone.se Wed Aug 2 17:27:04 2017 From: nick at smallbone.se (Nick Smallbone) Date: Wed, 02 Aug 2017 19:27:04 +0200 Subject: [Haskell-cafe] What can be UNPACK'ed? References: <20170728134541.GA19583@weber> <20170729123545.GG20262@weber> <87lgn4cmdn.fsf@smallbone.se> <20170731215845.GE26348@weber> Message-ID: <87d18dc23b.fsf@smallbone.se> Tom Ellis writes: > On Mon, Jul 31, 2017 at 11:44:20PM +0200, Nick Smallbone wrote: >> * The type must not be just a type variable >> (i.e., the constructor must be known at compile time) > > Eventually I'd like to see if we can relax this condition but first ... (Take everything I say here with a pinch of salt: I'm not a GHC developer.) IIUC, relaxing this would be difficult because GHC compiles using type erasure. For example, if I have a type data Whatever a = Whatever !a then values of type Whatever Int and Whatever Float are represented in exactly the same way at runtime. However, if we were to unpack the 'a', then they would internally have to be turned into two different types: data WhateverInt = Whatever Int# data WhateverFloat = Whatever Float# This would in turn mean that a polymorphic function f :: Whatever a -> ... would have to be compiled into two separate versions, one for Whatever Int and one for Whatever Float, which is something that GHC doesn't do. >> * The field's type must have only one constructor > > Do you know the rationale for this? It seems like there should be no > problem unpacking a constructor tag plus payload, even if the payload size > varies, as long as the maximum payload size in known. One thing is that UNPACK right now can be implemented just by a simple program transformation. When you declare a datatype with an unpacked field, such as data T a b = C {-# UNPACK #-} !Int {-# UNPACK #-} !(a, b), then GHC secretly replaces the datatype with the unpacked version, in this case: data T a b = UnpackedC Int# a b Then all uses of the constructor C are rewritten to use UnpackedC instead. The resulting program is still type-correct - in fact, it is still a normal Haskell (well, GHC core) program. This transformation happens quite early on during compilation and AIUI the rest of the compiler doesn't have to know about unpacking at all. If you try to unpack a field that has multiple constructors this way, it's not clear what the unpacked datatype should look like - I suppose it'd need to be some kind of union. So at least it's not immediately obvious how to do this... Nick From jclites at mac.com Wed Aug 2 19:53:23 2017 From: jclites at mac.com (Jeff Clites) Date: Wed, 02 Aug 2017 12:53:23 -0700 Subject: [Haskell-cafe] What code is generated for binary functions of data types with multiple constructors? In-Reply-To: References: Message-ID: <22164B75-C6E7-42B9-9777-B691E27F4A0D@mac.com> I don't have a definitive answer, but multiple function definitions desugar to "case of" pattern match expressions, and to nested pattern matches for multiple parameters such as this. That is what shows up in transformation to Core and then to STG. So the question boils down to whether nested pattern matches get optimized in the subsequent code generation. You can get GHC to dump the generated assembly (or intermediate LLVM or Cmm), but I can't tell based on a quick test--there's too much output so it's hard to find the important part (and I don't know offhand how LLVM compiles switch statements, which may be relevant). So someone with knowledge of the compiler internals may have a more informative answer, but maybe that's a little helpful. JEff > On Aug 2, 2017, at 5:05 AM, Clinton Mead wrote: > > Assume the following: > > 1. We have a type T with multiple constructors, but lets assume we're on a 64 bit machine and have at least 4 but no more than 7 constructors so we can still use pointer tagging. > 2. And a function "f :: T -> T -> T" > 3. Each combination of constructors (16 in the 4 constructor case, 49 in the 7 constructor case) has an implementation (naturally many of these will call helper functions). There's no wildcard matches. > > How will GHC generate the code for "f"? Will pushing through LLVM make any difference? > > Do we take the number of the first constructor, and then multiply the number of the second constructor by say 7, and then do one jump via a jump table? > > Is there a bunch of nested jump tables, each with 7 options? > > Is there a fall through if statement? > > Something else? > > I understand this probably a complex answer and perhaps doesn't have a simple answer, but I just wanted to get some sort of idea in my head of how GHC attempts to resolve code like this. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 wolfgang-it at jeltsch.info Wed Aug 2 21:25:54 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Thu, 03 Aug 2017 00:25:54 +0300 Subject: [Haskell-cafe] Haskell in Leipzig 2017: submission deadline shifted by two weeks Message-ID: <1501709154.10668.28.camel@jeltsch.info> Hi! We have shifted the submission deadline for Haskell in Leipzig 2017 by two weeks. The new deadline is at 18 August 2017. Looking forward to your contribution. 😉 Event:    Haskell in Leipzig 2017 Time:     October 26–28, 2017 Place:    HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions ============= Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of   * talks (about 30 minutes),   * tutorials (about 90 minutes),   * demonstrations, artistic performances, or other extraordinary     things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at     https://easychair.org/conferences/?conf=hal2017 until Friday, August 18, 2017. You will be notified by Friday, September 8, 2017. Hacking Projects ================ Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker ===============   * Ivan Perez, University of Nottingham, UK Invited Performer =================   * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Program Committee =================   * Edward Amsden, Plow Technologies, USA   * Heinrich Apfelmus, Germany   * Jurriaan Hage, Utrecht University, The Netherlands   * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany   * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair)   * Andres Löh, Well-Typed LLP, Germany   * Keiko Nakata, SAP SE, Germany   * Henrik Nilsson, University of Nottingham, UK   * Ertuğrul Söylemez, Intelego GmbH, Germany   * Henning Thielemann, Germany   * Niki Vazou, University of Maryland, USA   * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it at jeltsch.info. From casey_newsome98 at ymail.com Thu Aug 3 22:50:50 2017 From: casey_newsome98 at ymail.com (Casey Newsome) Date: Thu, 3 Aug 2017 22:50:50 +0000 (UTC) Subject: [Haskell-cafe] Question? References: <142085455.5403418.1501800650144.ref@mail.yahoo.com> Message-ID: <142085455.5403418.1501800650144@mail.yahoo.com> Hello, I am a new user of Haskell. I was wondering if this is where I can ask a question on a program I am attempting to write. If this is the wrong place. I apologize. Sorry if there was an inconvenience, Casey :D  -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Thu Aug 3 23:12:21 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 3 Aug 2017 19:12:21 -0400 Subject: [Haskell-cafe] Question? In-Reply-To: <142085455.5403418.1501800650144@mail.yahoo.com> References: <142085455.5403418.1501800650144.ref@mail.yahoo.com> <142085455.5403418.1501800650144@mail.yahoo.com> Message-ID: This is my informal sense of the norms here: The posts on haskell-cafe can be pretty intense. For questions like "how should I use this?" or "what's wrong with my program?" the haskell-beginners list is probably usually better. If it's an esoteric library, though, haskell-cafe can be an appropriate forum. On Thu, Aug 3, 2017 at 6:50 PM, Casey Newsome via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hello, I am a new user of Haskell. I was wondering if this is where I can > ask a question on a program I am attempting to write. If this is the wrong > place. I apologize. > > > > > Sorry if there was an inconvenience, Casey :D > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- 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 zemyla at gmail.com Thu Aug 3 23:16:27 2017 From: zemyla at gmail.com (Zemyla) Date: Thu, 3 Aug 2017 18:16:27 -0500 Subject: [Haskell-cafe] Low-level idea: Aligned tagged ByteArray# Message-ID: I had an idea for a way to attach small-but-necessary amounts of information to a ByteArray# or MutableByteArray# (and potentially also to Array# and ArrayArray#). The type would look something like "TaggedByteArray# 8#". This, for instance, would represent the address of a primitive array of bytes, with an alignment of 8, and with the last 3 bits having a number between 0 and 7 in them. Code to access the elements of the ByteArray# would disregard the last bits, and the garbage collector would simply ensure that the tag was retained after collection passes. "ByteArray#" itself would simply become an alias for "TaggedByteArray# 1#", and the existing functions would have their types changed to work with the new TaggedByteArray#s. The primary potential problems I see are how to have a KnownNat-style typeclass before Integer is defined, and how to store both the array and the tag in an ArrayArray#. From codygman.consulting at gmail.com Fri Aug 4 00:37:47 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Thu, 3 Aug 2017 19:37:47 -0500 Subject: [Haskell-cafe] Question? In-Reply-To: References: <142085455.5403418.1501800650144.ref@mail.yahoo.com> <142085455.5403418.1501800650144@mail.yahoo.com> Message-ID: I always just post questions to haskell-cafe and it works out well. I think it's fine to post here. On Aug 3, 2017 6:15 PM, "Jeffrey Brown" wrote: > This is my informal sense of the norms here: > > The posts on haskell-cafe can be pretty intense. For questions like "how > should I use this?" or "what's wrong with my program?" the > haskell-beginners list is probably usually better. If it's an esoteric > library, though, haskell-cafe can be an appropriate forum. > > On Thu, Aug 3, 2017 at 6:50 PM, Casey Newsome via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Hello, I am a new user of Haskell. I was wondering if this is where I can >> ask a question on a program I am attempting to write. If this is the wrong >> place. I apologize. >> >> >> >> >> Sorry if there was an inconvenience, Casey :D >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > 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 csasarak at mailbox.org Fri Aug 4 02:04:48 2017 From: csasarak at mailbox.org (Chris Sasarak) Date: Thu, 03 Aug 2017 22:04:48 -0400 Subject: [Haskell-cafe] Question? In-Reply-To: References: <142085455.5403418.1501800650144.ref@mail.yahoo.com> <142085455.5403418.1501800650144@mail.yahoo.com> Message-ID: <87fud8jdfj.fsf@mailbox.org> haskell-beginners is sometimes low traffic, I'd recommend asking here. -Chris Cody Goodman writes: > I always just post questions to haskell-cafe and it works out well. I think > it's fine to post here. > > On Aug 3, 2017 6:15 PM, "Jeffrey Brown" wrote: > >> This is my informal sense of the norms here: >> >> The posts on haskell-cafe can be pretty intense. For questions like "how >> should I use this?" or "what's wrong with my program?" the >> haskell-beginners list is probably usually better. If it's an esoteric >> library, though, haskell-cafe can be an appropriate forum. >> >> On Thu, Aug 3, 2017 at 6:50 PM, Casey Newsome via Haskell-Cafe < >> haskell-cafe at haskell.org> wrote: >> >>> Hello, I am a new user of Haskell. I was wondering if this is where I can >>> ask a question on a program I am attempting to write. If this is the wrong >>> place. I apologize. >>> >>> >>> >>> >>> Sorry if there was an inconvenience, Casey :D >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> >> -- >> 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. >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 78emil at gmail.com Fri Aug 4 11:41:01 2017 From: 78emil at gmail.com (Emil Axelsson) Date: Fri, 4 Aug 2017 14:41:01 +0300 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox Message-ID: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> Hi! I have a small file Test.hs alone in a directory: {-# LANGUAGE DeriveGeneric #-} module Test where import Data.Hashable import Data.Scientific import GHC.Generics data Sc = Sc Scientific deriving (Generic) instance Hashable Sc To be able to load this file, I set up a Cabal sandbox: $ ghc --numeric-version 8.0.2 $ cabal --numeric-version 1.24.0.2 $ cabal sandbox init ... $ cabal install hashable-1.2.6.0 scientific ... (Note: not the latest version of hashable.) Now, if I try to run GHCi and point it to the sandbox' package database I get this error: $ ghci -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Test.hs:12:14: error: • No instance for (Hashable Scientific) arising from a use of ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ • In the expression: hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc In an equation for ‘hashWithSalt’: hashWithSalt = hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc In the instance declaration for ‘Hashable Sc’ Somehow it mixes in version 1.2.6.1 of hashable, even though this package isn't installed (neither in the sandbox nor the global database). It turns out that wrapping the command in `cabal exec` fixes the problem: $ cabal exec -- ghci -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Ok, modules loaded: Test. *Test> Any idea what's going on? / Emil From 78emil at gmail.com Fri Aug 4 12:57:26 2017 From: 78emil at gmail.com (Emil Axelsson) Date: Fri, 4 Aug 2017 15:57:26 +0300 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> Message-ID: <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> Thanks for your reply! But I actually don't want `cabal repl`. The bigger picture is explained here: http://fun-discoveries.blogspot.com/2017/08/building-haskell-projects-with-ghc.html Towards the end of that post I suggest using `cabal exec` to integrate with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that shouldn't be needed since `cabal-cargs` already sets the `-package-db` flag for GHC. So my question is why `cabal exec` is needed (in this particular case) even though `-package-db` is given? I know `cabal exec` sets a few environment variables (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so Cabal seems to be doing its job. But it's not clear why ghci gets confused when these variables are not set (and `-package-db` is given), but not when the variables are set. Cheers / Emil Den 2017-08-04 kl. 15:31, skrev nek0: > Hi Emil, > > What you want is hidden behind the `cabal repl` command, which starts > ghci with the package-db of the sandbox. > > Greetings, > > nek0 > > On 4.8.2017 13:41, Emil Axelsson wrote: >> Hi! >> >> I have a small file Test.hs alone in a directory: >> >> {-# LANGUAGE DeriveGeneric #-} >> >> module Test where >> >> import Data.Hashable >> import Data.Scientific >> import GHC.Generics >> >> data Sc = Sc Scientific deriving (Generic) >> >> instance Hashable Sc >> >> To be able to load this file, I set up a Cabal sandbox: >> >> $ ghc --numeric-version >> 8.0.2 >> >> $ cabal --numeric-version >> 1.24.0.2 >> >> $ cabal sandbox init >> ... >> >> $ cabal install hashable-1.2.6.0 scientific >> ... >> >> (Note: not the latest version of hashable.) >> >> Now, if I try to run GHCi and point it to the sandbox' package database >> I get this error: >> >> $ ghci >> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >> [1 of 1] Compiling Test ( Test.hs, interpreted ) >> >> Test.hs:12:14: error: >> • No instance for (Hashable Scientific) >> arising from a use of >> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >> • In the expression: >> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >> In an equation for ‘hashWithSalt’: >> hashWithSalt >> = hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >> In the instance declaration for ‘Hashable Sc’ >> >> Somehow it mixes in version 1.2.6.1 of hashable, even though this >> package isn't installed (neither in the sandbox nor the global database). >> >> It turns out that wrapping the command in `cabal exec` fixes the problem: >> >> $ cabal exec -- ghci >> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d Test.hs >> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >> [1 of 1] Compiling Test ( Test.hs, interpreted ) >> Ok, modules loaded: Test. >> *Test> >> >> Any idea what's going on? >> >> / Emil >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 mark.santolucito at yale.edu Fri Aug 4 13:15:48 2017 From: mark.santolucito at yale.edu (Mark Santolucito) Date: Fri, 4 Aug 2017 15:15:48 +0200 Subject: [Haskell-cafe] Call for participation: FARM (early reg ends today) Message-ID: 5th ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Oxford, UK September 9, 2017 (co-located with ICFP 2017) http://functional-art.org/2017 The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. This year FARM presents paper and demo sessions during the day, as well as a performance in the evening. The evening performance feature computer music performances of artists integrating functional programming techniques into their work. To register for FARM, visit the ICFP registration page - early registration ends August 4. Some funding support is available for the main ICFP conference and related workshops like FARM. This information can be found on the travel support page. Registration ------------ You can register via the ICFP 2017 registration:http://icfp17.sigplan.org/attending/registration Early registration deadline is August 4. Program --------------- 9:00 - 9:10 Welcome Michael Sperber, Jean Bresson 09:10 - 10:00 A Categorial Grammar for Music and Its Use in Automatic Melody Generation Halley Young Demo - Representation of Musical Notation in Haskell Edward Lilley 10:30 - 11:30 Demo - The Arpeggigon: A Functional Reactive Musical Automaton Henrik Nilsson Demo - Vivid: Sound Synthesis with Haskell and SuperCollider Tom Murphy Demo - African Polyphony and Polyrhythm Chris Ford 12:00 - 12:30 Modelling the Way Mathematics Is Actually Done Joe Corneli, Ursula Martin, Dave Murray-Rust, Alison Pease, Raymond Puzio, Gabriela Rino Nesin 14:00 - 15:00 FAUST Tutorial for Functional Programmers Yann Orlarey, Stéphane Letz, Dominique Fober, Romain Michon 15:30 - 16:20 GALE: A Functional Graphic Adventure Library and Engine Ivan Perez Demo - Ait: A Concatenative Language for Creative Programming Stian Veum Mollersen 16:50 - 17:40 Unified Media Programming: An Algebraic Approach Simon Archipoff, David Janin Demo - Octopus: A High-Level Fast 3D Animation Language Simon Archipoff, David Janin Performances 19:30-22:00 @ Old Fire Station Workshop Organisation --------------------- - Workshop Chair: Mike Sperber, Active Group GmbH - Program Chair: Jean Bresson, UMR STMS IRCAM/CNRS/UPMC Sorbonne Universités - Publicity Chair: Mark Santolucito, Yale University - Performance Chair: Alex McLean, Deutsches Museum, Munich Program Committee: --------------------- - Renick Bell, Tama Art University, Tokyo - Beatrice Berard, LIP6, Universite Pierre et Marie Curie - Jean Bresson, UMR STMS IRCAM/CNRS/UPMC Sorbonne Universités - Richard Gabriel, IBM Research - Jean-Louis Giavitto, UMR STMS IRCAM/CNRS/UPMC Sorbonne Universités - Stéphane Letz, Grame - José Pedro Magalhães, Standard Chartered Bank - Ivan Perez Dominguez, University of Nottingham - Donya Quick, Southern Methodist University - Christophe Rhodes, Goldsmiths, University of London - Andrew Sorensen, Australian National University - Michael Sperber, Active Group GmbH - Charlotte Truchet, LINA, UMR 6241, Université de Nantes -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Aug 4 13:58:38 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 4 Aug 2017 09:58:38 -0400 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> Message-ID: ghc including ghci does not know about sandboxes. At all. That is what cabal/stack exec is for; it runs a command inside the sandbox. There are sandboxing mechanisms that don't require this, but they require your shell dotfiles to be set up in a way almost nobody does these days (proper separation of environment variables; otherwise you get things like the sandbox's package database, but the wrong $PATH). hsenv used to work that way. On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com > wrote: > Thanks for your reply! But I actually don't want `cabal repl`. The bigger > picture is explained here: > > http://fun-discoveries.blogspot.com/2017/08/building-haskell > -projects-with-ghc.html > > Towards the end of that post I suggest using `cabal exec` to integrate > with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that > shouldn't be needed since `cabal-cargs` already sets the `-package-db` flag > for GHC. > > So my question is why `cabal exec` is needed (in this particular case) > even though `-package-db` is given? > > I know `cabal exec` sets a few environment variables > (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and > `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so > Cabal seems to be doing its job. But it's not clear why ghci gets confused > when these variables are not set (and `-package-db` is given), but not when > the variables are set. > > Cheers > > / Emil > > Den 2017-08-04 kl. 15:31, skrev nek0: > >> Hi Emil, >> >> What you want is hidden behind the `cabal repl` command, which starts >> ghci with the package-db of the sandbox. >> >> Greetings, >> >> nek0 >> >> On 4.8.2017 13:41, Emil Axelsson wrote: >> >>> Hi! >>> >>> I have a small file Test.hs alone in a directory: >>> >>> {-# LANGUAGE DeriveGeneric #-} >>> >>> module Test where >>> >>> import Data.Hashable >>> import Data.Scientific >>> import GHC.Generics >>> >>> data Sc = Sc Scientific deriving (Generic) >>> >>> instance Hashable Sc >>> >>> To be able to load this file, I set up a Cabal sandbox: >>> >>> $ ghc --numeric-version >>> 8.0.2 >>> >>> $ cabal --numeric-version >>> 1.24.0.2 >>> >>> $ cabal sandbox init >>> ... >>> >>> $ cabal install hashable-1.2.6.0 scientific >>> ... >>> >>> (Note: not the latest version of hashable.) >>> >>> Now, if I try to run GHCi and point it to the sandbox' package database >>> I get this error: >>> >>> $ ghci >>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>> >>> Test.hs:12:14: error: >>> • No instance for (Hashable Scientific) >>> arising from a use of >>> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >>> • In the expression: >>> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >>> In an equation for ‘hashWithSalt’: >>> hashWithSalt >>> = hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt >>> @Sc >>> In the instance declaration for ‘Hashable Sc’ >>> >>> Somehow it mixes in version 1.2.6.1 of hashable, even though this >>> package isn't installed (neither in the sandbox nor the global database). >>> >>> It turns out that wrapping the command in `cabal exec` fixes the problem: >>> >>> $ cabal exec -- ghci >>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>> Test.hs >>> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>> Ok, modules loaded: Test. >>> *Test> >>> >>> Any idea what's going on? >>> >>> / Emil >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From 78emil at gmail.com Fri Aug 4 14:22:48 2017 From: 78emil at gmail.com (Emil Axelsson) Date: Fri, 4 Aug 2017 17:22:48 +0300 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> Message-ID: <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> I guess I get your point in the general case with various tools working together. But in this case, only ghci is used, and it seems that it gets some information from the variables `CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH` (set by `cabal exec`) that it doesn't get from the flag `-package-db`. At least I find that a little strange. / Emil Den 2017-08-04 kl. 16:58, skrev Brandon Allbery: > ghc including ghci does not know about sandboxes. At all. That is what > cabal/stack exec is for; it runs a command inside the sandbox. > > There are sandboxing mechanisms that don't require this, but they require > your shell dotfiles to be set up in a way almost nobody does these days > (proper separation of environment variables; otherwise you get things like > the sandbox's package database, but the wrong $PATH). hsenv used to work > that way. > > On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com > > wrote: > >> Thanks for your reply! But I actually don't want `cabal repl`. The bigger >> picture is explained here: >> >> http://fun-discoveries.blogspot.com/2017/08/building-haskell >> -projects-with-ghc.html >> >> Towards the end of that post I suggest using `cabal exec` to integrate >> with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that >> shouldn't be needed since `cabal-cargs` already sets the `-package-db` flag >> for GHC. >> >> So my question is why `cabal exec` is needed (in this particular case) >> even though `-package-db` is given? >> >> I know `cabal exec` sets a few environment variables >> (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and >> `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so >> Cabal seems to be doing its job. But it's not clear why ghci gets confused >> when these variables are not set (and `-package-db` is given), but not when >> the variables are set. >> >> Cheers >> >> / Emil >> >> Den 2017-08-04 kl. 15:31, skrev nek0: >> >>> Hi Emil, >>> >>> What you want is hidden behind the `cabal repl` command, which starts >>> ghci with the package-db of the sandbox. >>> >>> Greetings, >>> >>> nek0 >>> >>> On 4.8.2017 13:41, Emil Axelsson wrote: >>> >>>> Hi! >>>> >>>> I have a small file Test.hs alone in a directory: >>>> >>>> {-# LANGUAGE DeriveGeneric #-} >>>> >>>> module Test where >>>> >>>> import Data.Hashable >>>> import Data.Scientific >>>> import GHC.Generics >>>> >>>> data Sc = Sc Scientific deriving (Generic) >>>> >>>> instance Hashable Sc >>>> >>>> To be able to load this file, I set up a Cabal sandbox: >>>> >>>> $ ghc --numeric-version >>>> 8.0.2 >>>> >>>> $ cabal --numeric-version >>>> 1.24.0.2 >>>> >>>> $ cabal sandbox init >>>> ... >>>> >>>> $ cabal install hashable-1.2.6.0 scientific >>>> ... >>>> >>>> (Note: not the latest version of hashable.) >>>> >>>> Now, if I try to run GHCi and point it to the sandbox' package database >>>> I get this error: >>>> >>>> $ ghci >>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>> >>>> Test.hs:12:14: error: >>>> • No instance for (Hashable Scientific) >>>> arising from a use of >>>> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >>>> • In the expression: >>>> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >>>> In an equation for ‘hashWithSalt’: >>>> hashWithSalt >>>> = hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt >>>> @Sc >>>> In the instance declaration for ‘Hashable Sc’ >>>> >>>> Somehow it mixes in version 1.2.6.1 of hashable, even though this >>>> package isn't installed (neither in the sandbox nor the global database). >>>> >>>> It turns out that wrapping the command in `cabal exec` fixes the problem: >>>> >>>> $ cabal exec -- ghci >>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>> Test.hs >>>> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>> Ok, modules loaded: Test. >>>> *Test> >>>> >>>> Any idea what's going on? >>>> >>>> / Emil >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view 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 allbery.b at gmail.com Fri Aug 4 15:45:05 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 4 Aug 2017 11:45:05 -0400 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> Message-ID: GHC_PACKAGE_PATH is the only one of those that it knows about. And the difference is that --package-db appends to the package database path, whereas GHC_PACKAGE_PATH sets the entire path. You would need an additional option to override the *user* entry on the standard package db path with that of the sandbox, to be compatible with how sandboxes work using only command line options. On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com> wrote: > I guess I get your point in the general case with various tools working > together. But in this case, only ghci is used, and it seems that it gets > some information from the variables `CABAL_SANDBOX_CONFIG`, > `CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH` (set by `cabal exec`) > that it doesn't get from the flag `-package-db`. > > At least I find that a little strange. > > / Emil > > Den 2017-08-04 kl. 16:58, skrev Brandon Allbery: > >> ghc including ghci does not know about sandboxes. At all. That is what >> cabal/stack exec is for; it runs a command inside the sandbox. >> >> There are sandboxing mechanisms that don't require this, but they require >> your shell dotfiles to be set up in a way almost nobody does these days >> (proper separation of environment variables; otherwise you get things like >> the sandbox's package database, but the wrong $PATH). hsenv used to work >> that way. >> >> On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com >> > wrote: >> >> Thanks for your reply! But I actually don't want `cabal repl`. The bigger >>> picture is explained here: >>> >>> http://fun-discoveries.blogspot.com/2017/08/building-haskell >>> -projects-with-ghc.html >>> >>> Towards the end of that post I suggest using `cabal exec` to integrate >>> with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that >>> shouldn't be needed since `cabal-cargs` already sets the `-package-db` >>> flag >>> for GHC. >>> >>> So my question is why `cabal exec` is needed (in this particular case) >>> even though `-package-db` is given? >>> >>> I know `cabal exec` sets a few environment variables >>> (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and >>> `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so >>> Cabal seems to be doing its job. But it's not clear why ghci gets >>> confused >>> when these variables are not set (and `-package-db` is given), but not >>> when >>> the variables are set. >>> >>> Cheers >>> >>> / Emil >>> >>> Den 2017-08-04 kl. 15:31, skrev nek0: >>> >>> Hi Emil, >>>> >>>> What you want is hidden behind the `cabal repl` command, which starts >>>> ghci with the package-db of the sandbox. >>>> >>>> Greetings, >>>> >>>> nek0 >>>> >>>> On 4.8.2017 13:41, Emil Axelsson wrote: >>>> >>>> Hi! >>>>> >>>>> I have a small file Test.hs alone in a directory: >>>>> >>>>> {-# LANGUAGE DeriveGeneric #-} >>>>> >>>>> module Test where >>>>> >>>>> import Data.Hashable >>>>> import Data.Scientific >>>>> import GHC.Generics >>>>> >>>>> data Sc = Sc Scientific deriving (Generic) >>>>> >>>>> instance Hashable Sc >>>>> >>>>> To be able to load this file, I set up a Cabal sandbox: >>>>> >>>>> $ ghc --numeric-version >>>>> 8.0.2 >>>>> >>>>> $ cabal --numeric-version >>>>> 1.24.0.2 >>>>> >>>>> $ cabal sandbox init >>>>> ... >>>>> >>>>> $ cabal install hashable-1.2.6.0 scientific >>>>> ... >>>>> >>>>> (Note: not the latest version of hashable.) >>>>> >>>>> Now, if I try to run GHCi and point it to the sandbox' package database >>>>> I get this error: >>>>> >>>>> $ ghci >>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>> >>>>> Test.hs:12:14: error: >>>>> • No instance for (Hashable Scientific) >>>>> arising from a use of >>>>> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >>>>> • In the expression: >>>>> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >>>>> In an equation for ‘hashWithSalt’: >>>>> hashWithSalt >>>>> = hashable-1.2.6.1:Data.Hashable >>>>> .Class.$dmhashWithSalt >>>>> @Sc >>>>> In the instance declaration for ‘Hashable Sc’ >>>>> >>>>> Somehow it mixes in version 1.2.6.1 of hashable, even though this >>>>> package isn't installed (neither in the sandbox nor the global >>>>> database). >>>>> >>>>> It turns out that wrapping the command in `cabal exec` fixes the >>>>> problem: >>>>> >>>>> $ cabal exec -- ghci >>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>> Test.hs >>>>> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>> Ok, modules loaded: Test. >>>>> *Test> >>>>> >>>>> Any idea what's going on? >>>>> >>>>> / Emil >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> To (un)subscribe, modify options or view archives go to: >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> Only members subscribed via the mailman list are allowed to post. >>>>> >>>>> _______________________________________________ >>>> >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> >> -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From 78emil at gmail.com Fri Aug 4 16:10:09 2017 From: 78emil at gmail.com (Emil Axelsson) Date: Fri, 4 Aug 2017 19:10:09 +0300 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> Message-ID: Ah, I see. I still don't understand what went wrong in this particular case, but at least it makes sense that there's a difference between `-package-db` and `cabal exec`. I'll leave it at that. Thanks! / Emil Den 2017-08-04 kl. 18:45, skrev Brandon Allbery: > GHC_PACKAGE_PATH is the only one of those that it knows about. And the > difference is that --package-db appends to the package database path, > whereas GHC_PACKAGE_PATH sets the entire path. You would need an additional > option to override the *user* entry on the standard package db path with > that of the sandbox, to be compatible with how sandboxes work using only > command line options. > > On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com> wrote: > >> I guess I get your point in the general case with various tools working >> together. But in this case, only ghci is used, and it seems that it gets >> some information from the variables `CABAL_SANDBOX_CONFIG`, >> `CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH` (set by `cabal exec`) >> that it doesn't get from the flag `-package-db`. >> >> At least I find that a little strange. >> >> / Emil >> >> Den 2017-08-04 kl. 16:58, skrev Brandon Allbery: >> >>> ghc including ghci does not know about sandboxes. At all. That is what >>> cabal/stack exec is for; it runs a command inside the sandbox. >>> >>> There are sandboxing mechanisms that don't require this, but they require >>> your shell dotfiles to be set up in a way almost nobody does these days >>> (proper separation of environment variables; otherwise you get things like >>> the sandbox's package database, but the wrong $PATH). hsenv used to work >>> that way. >>> >>> On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com >>> > wrote: >>> >>> Thanks for your reply! But I actually don't want `cabal repl`. The bigger >>>> picture is explained here: >>>> >>>> http://fun-discoveries.blogspot.com/2017/08/building-haskell >>>> -projects-with-ghc.html >>>> >>>> Towards the end of that post I suggest using `cabal exec` to integrate >>>> with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that >>>> shouldn't be needed since `cabal-cargs` already sets the `-package-db` >>>> flag >>>> for GHC. >>>> >>>> So my question is why `cabal exec` is needed (in this particular case) >>>> even though `-package-db` is given? >>>> >>>> I know `cabal exec` sets a few environment variables >>>> (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and >>>> `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so >>>> Cabal seems to be doing its job. But it's not clear why ghci gets >>>> confused >>>> when these variables are not set (and `-package-db` is given), but not >>>> when >>>> the variables are set. >>>> >>>> Cheers >>>> >>>> / Emil >>>> >>>> Den 2017-08-04 kl. 15:31, skrev nek0: >>>> >>>> Hi Emil, >>>>> >>>>> What you want is hidden behind the `cabal repl` command, which starts >>>>> ghci with the package-db of the sandbox. >>>>> >>>>> Greetings, >>>>> >>>>> nek0 >>>>> >>>>> On 4.8.2017 13:41, Emil Axelsson wrote: >>>>> >>>>> Hi! >>>>>> >>>>>> I have a small file Test.hs alone in a directory: >>>>>> >>>>>> {-# LANGUAGE DeriveGeneric #-} >>>>>> >>>>>> module Test where >>>>>> >>>>>> import Data.Hashable >>>>>> import Data.Scientific >>>>>> import GHC.Generics >>>>>> >>>>>> data Sc = Sc Scientific deriving (Generic) >>>>>> >>>>>> instance Hashable Sc >>>>>> >>>>>> To be able to load this file, I set up a Cabal sandbox: >>>>>> >>>>>> $ ghc --numeric-version >>>>>> 8.0.2 >>>>>> >>>>>> $ cabal --numeric-version >>>>>> 1.24.0.2 >>>>>> >>>>>> $ cabal sandbox init >>>>>> ... >>>>>> >>>>>> $ cabal install hashable-1.2.6.0 scientific >>>>>> ... >>>>>> >>>>>> (Note: not the latest version of hashable.) >>>>>> >>>>>> Now, if I try to run GHCi and point it to the sandbox' package database >>>>>> I get this error: >>>>>> >>>>>> $ ghci >>>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>>> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>>> >>>>>> Test.hs:12:14: error: >>>>>> • No instance for (Hashable Scientific) >>>>>> arising from a use of >>>>>> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >>>>>> • In the expression: >>>>>> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt @Sc >>>>>> In an equation for ‘hashWithSalt’: >>>>>> hashWithSalt >>>>>> = hashable-1.2.6.1:Data.Hashable >>>>>> .Class.$dmhashWithSalt >>>>>> @Sc >>>>>> In the instance declaration for ‘Hashable Sc’ >>>>>> >>>>>> Somehow it mixes in version 1.2.6.1 of hashable, even though this >>>>>> package isn't installed (neither in the sandbox nor the global >>>>>> database). >>>>>> >>>>>> It turns out that wrapping the command in `cabal exec` fixes the >>>>>> problem: >>>>>> >>>>>> $ cabal exec -- ghci >>>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>>> Test.hs >>>>>> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>>> Ok, modules loaded: Test. >>>>>> *Test> >>>>>> >>>>>> Any idea what's going on? >>>>>> >>>>>> / Emil >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> To (un)subscribe, modify options or view 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 allbery.b at gmail.com Fri Aug 4 16:17:55 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 4 Aug 2017 12:17:55 -0400 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> Message-ID: The db path i searched in order from left to right; --package-db appends on the right, whereas stack and cabal normally replace the second entry on the path. (The first is special; it *must* contain the base package with the runtime system. iirc this has caused stack issues in the past, when it needed to override some package other than base living in the first package db. It's also why cabal can't hide stuff installed in the global db.) So with --package-db, cabal will see the user package db before the sandbox --- when it needs to see the sandbox either before or in place of the user db. On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com> wrote: > Ah, I see. I still don't understand what went wrong in this particular > case, but at least it makes sense that there's a difference between > `-package-db` and `cabal exec`. > > I'll leave it at that. > > Thanks! > > / Emil > > Den 2017-08-04 kl. 18:45, skrev Brandon Allbery: > >> GHC_PACKAGE_PATH is the only one of those that it knows about. And the >> difference is that --package-db appends to the package database path, >> whereas GHC_PACKAGE_PATH sets the entire path. You would need an >> additional >> option to override the *user* entry on the standard package db path with >> that of the sandbox, to be compatible with how sandboxes work using only >> command line options. >> >> On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com> wrote: >> >> I guess I get your point in the general case with various tools working >>> together. But in this case, only ghci is used, and it seems that it gets >>> some information from the variables `CABAL_SANDBOX_CONFIG`, >>> `CABAL_SANDBOX_PACKAGE_PATH` and `GHC_PACKAGE_PATH` (set by `cabal exec`) >>> that it doesn't get from the flag `-package-db`. >>> >>> At least I find that a little strange. >>> >>> / Emil >>> >>> Den 2017-08-04 kl. 16:58, skrev Brandon Allbery: >>> >>> ghc including ghci does not know about sandboxes. At all. That is what >>>> cabal/stack exec is for; it runs a command inside the sandbox. >>>> >>>> There are sandboxing mechanisms that don't require this, but they >>>> require >>>> your shell dotfiles to be set up in a way almost nobody does these days >>>> (proper separation of environment variables; otherwise you get things >>>> like >>>> the sandbox's package database, but the wrong $PATH). hsenv used to work >>>> that way. >>>> >>>> On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com >>>> > wrote: >>>> >>>> Thanks for your reply! But I actually don't want `cabal repl`. The >>>> bigger >>>> >>>>> picture is explained here: >>>>> >>>>> http://fun-discoveries.blogspot.com/2017/08/building-haskell >>>>> -projects-with-ghc.html >>>>> >>>>> Towards the end of that post I suggest using `cabal exec` to integrate >>>>> with a Cabal sandbox; however, as Daniel Trstenjak pointed out, that >>>>> shouldn't be needed since `cabal-cargs` already sets the `-package-db` >>>>> flag >>>>> for GHC. >>>>> >>>>> So my question is why `cabal exec` is needed (in this particular case) >>>>> even though `-package-db` is given? >>>>> >>>>> I know `cabal exec` sets a few environment variables >>>>> (`CABAL_SANDBOX_CONFIG`, `CABAL_SANDBOX_PACKAGE_PATH` and >>>>> `GHC_PACKAGE_PATH`). I've checked that these are all set correctly, so >>>>> Cabal seems to be doing its job. But it's not clear why ghci gets >>>>> confused >>>>> when these variables are not set (and `-package-db` is given), but not >>>>> when >>>>> the variables are set. >>>>> >>>>> Cheers >>>>> >>>>> / Emil >>>>> >>>>> Den 2017-08-04 kl. 15:31, skrev nek0: >>>>> >>>>> Hi Emil, >>>>> >>>>>> >>>>>> What you want is hidden behind the `cabal repl` command, which starts >>>>>> ghci with the package-db of the sandbox. >>>>>> >>>>>> Greetings, >>>>>> >>>>>> nek0 >>>>>> >>>>>> On 4.8.2017 13:41, Emil Axelsson wrote: >>>>>> >>>>>> Hi! >>>>>> >>>>>>> >>>>>>> I have a small file Test.hs alone in a directory: >>>>>>> >>>>>>> {-# LANGUAGE DeriveGeneric #-} >>>>>>> >>>>>>> module Test where >>>>>>> >>>>>>> import Data.Hashable >>>>>>> import Data.Scientific >>>>>>> import GHC.Generics >>>>>>> >>>>>>> data Sc = Sc Scientific deriving (Generic) >>>>>>> >>>>>>> instance Hashable Sc >>>>>>> >>>>>>> To be able to load this file, I set up a Cabal sandbox: >>>>>>> >>>>>>> $ ghc --numeric-version >>>>>>> 8.0.2 >>>>>>> >>>>>>> $ cabal --numeric-version >>>>>>> 1.24.0.2 >>>>>>> >>>>>>> $ cabal sandbox init >>>>>>> ... >>>>>>> >>>>>>> $ cabal install hashable-1.2.6.0 scientific >>>>>>> ... >>>>>>> >>>>>>> (Note: not the latest version of hashable.) >>>>>>> >>>>>>> Now, if I try to run GHCi and point it to the sandbox' package >>>>>>> database >>>>>>> I get this error: >>>>>>> >>>>>>> $ ghci >>>>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>>>> Test.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for >>>>>>> help >>>>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>>>> >>>>>>> Test.hs:12:14: error: >>>>>>> • No instance for (Hashable Scientific) >>>>>>> arising from a use of >>>>>>> ‘hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt’ >>>>>>> • In the expression: >>>>>>> hashable-1.2.6.1:Data.Hashable.Class.$dmhashWithSalt >>>>>>> @Sc >>>>>>> In an equation for ‘hashWithSalt’: >>>>>>> hashWithSalt >>>>>>> = hashable-1.2.6.1:Data.Hashable >>>>>>> .Class.$dmhashWithSalt >>>>>>> @Sc >>>>>>> In the instance declaration for ‘Hashable Sc’ >>>>>>> >>>>>>> Somehow it mixes in version 1.2.6.1 of hashable, even though this >>>>>>> package isn't installed (neither in the sandbox nor the global >>>>>>> database). >>>>>>> >>>>>>> It turns out that wrapping the command in `cabal exec` fixes the >>>>>>> problem: >>>>>>> >>>>>>> $ cabal exec -- ghci >>>>>>> -package-db=.cabal-sandbox/x86_64-linux-ghc-8.0.2-packages.conf.d >>>>>>> Test.hs >>>>>>> GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help >>>>>>> [1 of 1] Compiling Test ( Test.hs, interpreted ) >>>>>>> Ok, modules loaded: Test. >>>>>>> *Test> >>>>>>> >>>>>>> Any idea what's going on? >>>>>>> >>>>>>> / Emil >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> To (un)subscribe, modify options or view archives go to: >>>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>>> Only members subscribed via the mailman list are allowed to post. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>> >>>>>> Haskell-Cafe mailing list >>>>> To (un)subscribe, modify options or view archives go to: >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> Only members subscribed via the mailman list are allowed to post. >>>>> >>>>> >>>> >>>> >>>> >>>> >> -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Fri Aug 4 16:33:33 2017 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 4 Aug 2017 18:33:33 +0200 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> Message-ID: <20170804163333.GA3129@octa> Hi Emil, On Fri, Aug 04, 2017 at 07:10:09PM +0300, Emil Axelsson wrote: > Ah, I see. I still don't understand what went wrong in this particular case, > but at least it makes sense that there's a difference between `-package-db` > and `cabal exec`. can you please test if `cabal-cargs` behaves in the same way as `cabal exec` if you add a `-no-user-package-db` or/and replace `-packabe-db` by `-user-package-db`. Greetings, Daniel From hexagoxel at hexagoxel.de Fri Aug 4 13:01:51 2017 From: hexagoxel at hexagoxel.de (lennart spitzner) Date: Fri, 4 Aug 2017 15:01:51 +0200 Subject: [Haskell-cafe] [ANN] brittany - haskell source code formatting tool - hackage release Message-ID: <14f23926-b296-865d-7eeb-1a232427fd07@hexagoxel.de> Greetings, I am happy to (finally) announce the first hackage release of brittany, a configurable haskell source code formatter based on ghc-exactprint [2]. https://hackage.haskell.org/package/brittany https://github.com/lspitzner/brittany *Introduction* Brittany aims to nicely layout the code and retain empty lines and comments as they appear in the input. For that it uses a fundamentally different approach (see [7]/theory) than other formatters. The project is not finished, yet it already is usable and produces better results than other formatters in many cases. Of course these words come from its creator, so see for yourself: I have included some examples at the bottom of this mail; see [3] and [4] for some more. I wish to stress that this project will only progress at a very slow speed barring support from the community. I hereby offer to work on this and ask for funding. See the "future" paragraph below. *Changelog* Since the "alpha-release" announced previously [5] the most important changes are: - Release under the AGPL-v3; - Release on hackage; - Make horizontal alignment less aggressive by default (see example [6]); - Add high-level documentation (see [7]). This might be of interest to anyone considering to write a formatter (haskell or even otherwise); - Improve testsuite setup; - Improve layouting in many many cases and fix various bugs; - Add a library interface (this integrates with haskell-ide-engine [8]); Brittany still.. - does not touch anything other than top-level type signatures and bindings (imports, classes, instances, data decls, .. are not modified); - contains some bugs (but it checks its own output for validity and aborts); - does not handle many "uncommon" syntactic constructs/extentions (e.g. arrow notation); In preparation of this release the `butcher` and `czipwith` packages were published on hackage as well. I will cover those in separate announcements. *Building* Brittany currently requires ghc-8.0 (no support for previous ghc versions is planned, but 8.2 will be). Now that this package is on hackage, cabal users should be able to install it directly; stack users will currently have to clone and go from there (a stack.yaml is provided). Detailed building guides for cabal, cabal-new and stack are in the project README. Inclusion in stackage is coming as soon as all dependencies are included. *Known issues* - Bad performance for large inputs (really noticeable at >1k loc). The cause is already determined - quadratic instead of linear complexity in one specific function (see issue #34 [9]). Should be fixable and has high priority. - The config (file) lacks documentation. - Comments are not always reproduced exactly when reformatting. There is a lack of testcases for comments in the testsuite. There is the known case of comments in List/MonadComprehensions that currently breaks idempotency (the comments move further left each roundtrip through brittany) where a solution will most likely involve some non-trivial changes in ghc-exactprint (see [10]). - As mentioned above: only certain module elements are transformed, and not all syntactical constructs are supported. re-layouting of imports, data decls, classes and instances are on the radar, but all require a good amount of work. - CPP is not officially supported. This is mostly a WONTFIX. One can enable it by force, and it works to a degree, but it is relatively easy to find cases where it will break (conditional code not being reformatted, leading to syntax errors and theoretically also to change semantics)). - No fine-grained (per file or even per-function) control/configuration, e.g. it is not yet possible to add some pragma/comment to disable reformatting this one carefully layouted-by-hand function that brittany messes up. - No adaption to ghc-8.2 yet. *Future/Outlook* As far as I can tell brittany already works rather well - I use it all the time, even though I still run into issues from time to time. Still, brittany is not finished (these projects never really are, are they?). Up on my list are ghc-8.2 adaption, fixing the performance bug mentioned above, layouting of data decls, layouting of instances, and controlling behaviour/config via flags in the source (as comments). But implementing new functionality costs a lot of time, even with the DSL used internally: One has to understand the GHC AST (which is not always documented), think of all possible interactions ("do users really use record syntax when having more than one constructor?" "are GADT records a thing?"), write the layouting transformation and test it. I have already invested a good amount of my free time into this project but its scope is too large and I decided to put a limit on my personal investment. This means that barring some form of support from the community I don't see new features being implemented at any certain pace. This leaves the following paths: 1) This project is supported monetarily: I hereby offer to (part-time) work on this provided appropriate funding. I am not sure who exactly might be interested in providing this kind of support - I am no student anymore so GSoC is out of the question. Feel free to contact me on- or off-list if interested. 2) (More) Contributors add tests, report (and maybe fix) bugs and most importantly implement new functionality (layouting for any syntactic constructs of the haskell language not yet supported, etc.) I realize that this is not a trivial project to dive into, and there is a good amount of stuff one has to get familiar with before one can start making use of the abstractions (the DSL) provided. On the other hand, I _think_ that the project source code is relatively well-structured (although in-source comments are really sparse, admittedly) and the high-level (markdown) documentation will scare everyone away due to their length will allow understanding the project relatively quickly. 3) The project will progress only rather slowly. Regardless I plan to continue maintaining this project, fix bugs as they come up and also work on expanding functionality when I find the time. *Contributing* In ascending order of involvement, you can contribute by: - Reporting issues, especially instances of bad layouting (especially when it is not a pure matter of opinion); - Add to the testsuite, specifically to the `tests.blt` file of the `littests` test. It contains a large number of tests already, but the coverage is not very good. - If you want to really help implementing more stuff, the high-level docs [7] are the right place to get a rough overview, especially the theory document [11]. I have not documented how to write new layouters yet, so for now I recommend looking at the existing ones, e.g. in `Expr.hs`. -- lennart [1] https://hackage.haskell.org/package/brittany https://github.com/lspitzner/brittany/ [2] https://mpickering.github.io/posts/2015-07-23-ghc-exactprint.html https://hackage.haskell.org/package/ghc-exactprint [3] https://github.com/lspitzner/brittany/blob/da692a4341399390018fb03773e15865d967fb8c/doc/showcases/BrittanyComparison.md [4] https://github.com/lspitzner/brittany/tree/master/doc/showcases [5] https://mail.haskell.org/pipermail/haskell-cafe/2016-September/124793.html [6] https://github.com/lspitzner/brittany/blob/da692a4341399390018fb03773e15865d967fb8c/doc/showcases/Layout_Alignment.md#items-that-are-not-single-line-break-up-alignment [7] https://github.com/lspitzner/brittany/blob/master/doc/implementation/index.md [8] https://github.com/haskell/haskell-ide-engine [9] https://github.com/lspitzner/brittany/issues/34 [10] https://github.com/alanz/ghc-exactprint/issues/53 [11] https://github.com/lspitzner/brittany/blob/master/doc/implementation/theory.md -- some layouting examples - would be (re)produced in exactly this way by brittany: > main = do > > now <- getCurrentTime > let (_, _, week) = toWeekDate . utctDay $ now > putStrLn $ ("it's "++) $ case week of > 6 -> "the weekend" > 7 -> "the weekend" > _ -> "a weekday" > > localtime <- utcToLocalZonedTime now > let hr = todHour . localTimeOfDay . zonedTimeToLocalTime $ localtime > case hr of > _ | hr < 12 -> putStrLn "it's before noon" > | otherwise -> putStrLn "it's after noon" > -- Newlines are used sparingly: Only after "do" and when the > -- `liftBaseOpDiscard` application would lead to overflowing 80 columns. > main :: IO () > main = do > pool <- createPostgresqlPool (toS databaseConnectionString) 10 > initiate $ \chan -> forever $ do > flip runDbConn pool $ do > makeSureQueueIsFull chan > void $ liftBaseOpDiscard (consumeMsgs chan responseQueue Ack) > (uncurry processMsg) > threadDelay 1000000 > -- Alignment of patterns > go [] "" = True > go [WildCard ] "" = True > go (WildCard :rest) (c:cs) = go rest (c : cs) || go (WildCard : rest) cs > go (Union globs:rest) cs = any (\glob -> go (glob ++ rest) cs) globs > go [] (_:_) = False > go (_:_) "" = False From 78emil at gmail.com Fri Aug 4 17:51:49 2017 From: 78emil at gmail.com (Emil Axelsson) Date: Fri, 4 Aug 2017 20:51:49 +0300 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <20170804163333.GA3129@octa> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> <20170804163333.GA3129@octa> Message-ID: <29d75055-ceca-5a43-8a06-6c1dd7ab471e@gmail.com> Den 2017-08-04 kl. 19:33, skrev Daniel Trstenjak: > > Hi Emil, > > On Fri, Aug 04, 2017 at 07:10:09PM +0300, Emil Axelsson wrote: >> Ah, I see. I still don't understand what went wrong in this particular case, >> but at least it makes sense that there's a difference between `-package-db` >> and `cabal exec`. > > can you please test if `cabal-cargs` behaves in the same way as `cabal exec` > if you add a `-no-user-package-db` or/and replace `-packabe-db` by `-user-package-db`. Yes! `-no-user-package-db` does the trick. I have to admit I had forgotten completely about the user DB. When running `cabal sandbox hc-pkg list` I only see the global one and the one in the sandbox. But `ghc-pkg` shows the user DB and indeed it contains `hashable-1.2.6.1` which was causing me trouble. Cool, problem solved. Would it make sense then for `cabal-cargs` to always emit `-no-user-package-db` when it discovers a sandbox? Cheers / Emil > Greetings, > Daniel > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Aug 4 18:02:15 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 4 Aug 2017 14:02:15 -0400 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <29d75055-ceca-5a43-8a06-6c1dd7ab471e@gmail.com> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> <20170804163333.GA3129@octa> <29d75055-ceca-5a43-8a06-6c1dd7ab471e@gmail.com> Message-ID: Strictly speaking, the second option (specifying the sandbox as the user db) is a more correct match with what cabal-install does. On Friday, August 4, 2017, Emil Axelsson <78emil at gmail.com> wrote: > Den 2017-08-04 kl. 19:33, skrev Daniel Trstenjak: > >> >> Hi Emil, >> >> On Fri, Aug 04, 2017 at 07:10:09PM +0300, Emil Axelsson wrote: >> >>> Ah, I see. I still don't understand what went wrong in this particular >>> case, >>> but at least it makes sense that there's a difference between >>> `-package-db` >>> and `cabal exec`. >>> >> >> can you please test if `cabal-cargs` behaves in the same way as `cabal >> exec` >> if you add a `-no-user-package-db` or/and replace `-packabe-db` by >> `-user-package-db`. >> > > Yes! `-no-user-package-db` does the trick. > > I have to admit I had forgotten completely about the user DB. When running > `cabal sandbox hc-pkg list` I only see the global one and the one in the > sandbox. But `ghc-pkg` shows the user DB and indeed it contains > `hashable-1.2.6.1` which was causing me trouble. > > Cool, problem solved. > > Would it make sense then for `cabal-cargs` to always emit > `-no-user-package-db` when it discovers a sandbox? > > Cheers > > / Emil > > Greetings, >> Daniel >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Fri Aug 4 18:12:50 2017 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Fri, 4 Aug 2017 20:12:50 +0200 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> <20170804163333.GA3129@octa> <29d75055-ceca-5a43-8a06-6c1dd7ab471e@gmail.com> Message-ID: <4C6DAF1B-E922-4300-A37F-71416DAE81ED@gmail.com> > Strictly speaking, the second option (specifying the sandbox as the user db) is a more correct match with what cabal-install does Ok, is there then a need for the `-no-user-package-db`? From allbery.b at gmail.com Fri Aug 4 18:14:38 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 4 Aug 2017 14:14:38 -0400 Subject: [Haskell-cafe] Running ghci in a Cabal sandbox In-Reply-To: <4C6DAF1B-E922-4300-A37F-71416DAE81ED@gmail.com> References: <752e4322-4c60-b739-8ac3-6acdfc7fc258@gmail.com> <8fc134d5-18d6-18ad-be17-6baa49841674@chelnok.de> <9c7bd5fd-ebe5-aae6-a3a4-849c28c37a54@gmail.com> <30d23f60-8429-5b9c-bc17-3d1e4a478c19@gmail.com> <20170804163333.GA3129@octa> <29d75055-ceca-5a43-8a06-6c1dd7ab471e@gmail.com> <4C6DAF1B-E922-4300-A37F-71416DAE81ED@gmail.com> Message-ID: Not for this case; it's more for setups that want to skip that slot entirely (possibly stack, possibly third party setups --- I suspect some of the big in-house folks would use it for custom sandboxing). On Friday, August 4, 2017, Daniel Trstenjak wrote: > > > Strictly speaking, the second option (specifying the sandbox as the user > db) is a more correct match with what cabal-install does > > Ok, is there then a need for the `-no-user-package-db`? > > > > > > -- 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 manny at fpcomplete.com Sat Aug 5 14:49:59 2017 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Sat, 5 Aug 2017 07:49:59 -0700 Subject: [Haskell-cafe] ANN: stack-1.5.1 released Message-ID: See https://haskellstack.org for installation and upgrade instructions. Bug fixes: * Stack eagerly tries to parse all cabal files related to a snapshot. Starting with Stackage Nightly 2017-07-31, snapshots are using GHC 8.2.1, and the `ghc.cabal` file implicitly referenced uses the (not yet supported) Cabal 2.0 file format. Future releases of Stack will both be less eager about cabal file parsing and support Cabal 2.0. This patch simply bypasses the error for invalid parsing. From conal at conal.net Sat Aug 5 21:22:20 2017 From: conal at conal.net (Conal Elliott) Date: Sat, 5 Aug 2017 14:22:20 -0700 Subject: [Haskell-cafe] Job opening: compiling to categories Message-ID: I have a job opening to work closely with me (at Target Digital) on the GHC plugin described in the paper *Compiling to Categories* as well as on applications, including machine learning. I’m especially looking for someone used to working inside of GHC and/or on GHC plugins. Mathematically oriented, solid background in programming language theory, denotationally inclined. Remote work is perfectly fine (and is what I do). – Conal -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Sun Aug 6 02:45:04 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sat, 5 Aug 2017 21:45:04 -0500 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector Message-ID: I want to do this so I can use the Data.Vector.Unboxed.Generic functions requiring the Vector constraint, namely the maxIndex function. Implementing maxIndex for Data.Vector.Unboxed.Mutable.MVector would be useful as well, but I'm even more confused at how to do that or where to begin. Here is some stubbed out code demonstrating this. {-# Language ScopedTypeVariables #-} module Main where import Control.Monad.Primitive import qualified Data.Vector.Unboxed import qualified Data.Vector.Generic as VG import qualified Data.Vector.Unboxed.Mutable as VM import qualified Data.Vector.Unboxed as V toImmutable :: VM.MVector RealWorld Int -> V.Vector Int toImmutable = undefined main :: IO () main = do v :: VM.MVector RealWorld Int <- VM.new 1 VM.write v 0 (3 :: Int) x <- VM.read v 0 -- y <- VG.head . toImmutable $ v -- print y print $ VM.length v {- Thanks, Cody -} -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos.robinson at gmail.com Sun Aug 6 02:56:15 2017 From: amos.robinson at gmail.com (Amos Robinson) Date: Sun, 06 Aug 2017 02:56:15 +0000 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you are sure you won't modify the mutable vector after making it immutable. https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Generic.html#v:freeze On Sun, 6 Aug 2017 at 12:46 Cody Goodman wrote: > I want to do this so I can use the Data.Vector.Unboxed.Generic functions > requiring the Vector constraint, namely the maxIndex function. Implementing > maxIndex for Data.Vector.Unboxed.Mutable.MVector would be useful as well, > but I'm even more confused at how to do that or where to begin. > > Here is some stubbed out code demonstrating this. > > {-# Language ScopedTypeVariables #-} > module Main where > > import Control.Monad.Primitive > import qualified Data.Vector.Unboxed > import qualified Data.Vector.Generic as VG > import qualified Data.Vector.Unboxed.Mutable as VM > import qualified Data.Vector.Unboxed as V > > toImmutable :: VM.MVector RealWorld Int -> V.Vector Int > toImmutable = undefined > > main :: IO () > main = do > v :: VM.MVector RealWorld Int <- VM.new 1 > VM.write v 0 (3 :: Int) > x <- VM.read v 0 > -- y <- VG.head . toImmutable $ v > -- print y > print $ VM.length v > > {- > Thanks, > > > Cody > -} > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 codygman.consulting at gmail.com Sun Aug 6 02:59:19 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sat, 5 Aug 2017 21:59:19 -0500 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: I see the type is: freeze :: (PrimMonad m, Vector v a) => Mutable v (PrimState m) a -> m (v a) So there is a Vector constrant that MVector will not have. Does the Mutable type family get around this somehow? There doesn't seem to be a freeze function specifically for Data.Vector.Unboxed.Mutable.MVector listed at: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Unboxed-Mutable.html Thanks, Cody On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson wrote: > I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you are > sure you won't modify the mutable vector after making it immutable. > https://hackage.haskell.org/package/vector-0.12.0.1/docs/ > Data-Vector-Generic.html#v:freeze > > On Sun, 6 Aug 2017 at 12:46 Cody Goodman > wrote: > >> I want to do this so I can use the Data.Vector.Unboxed.Generic functions >> requiring the Vector constraint, namely the maxIndex function. Implementing >> maxIndex for Data.Vector.Unboxed.Mutable.MVector would be useful as >> well, but I'm even more confused at how to do that or where to begin. >> >> Here is some stubbed out code demonstrating this. >> >> {-# Language ScopedTypeVariables #-} >> module Main where >> >> import Control.Monad.Primitive >> import qualified Data.Vector.Unboxed >> import qualified Data.Vector.Generic as VG >> import qualified Data.Vector.Unboxed.Mutable as VM >> import qualified Data.Vector.Unboxed as V >> >> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >> toImmutable = undefined >> >> main :: IO () >> main = do >> v :: VM.MVector RealWorld Int <- VM.new 1 >> VM.write v 0 (3 :: Int) >> x <- VM.read v 0 >> -- y <- VG.head . toImmutable $ v >> -- print y >> print $ VM.length v >> >> {- >> Thanks, >> >> >> Cody >> -} >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 amos.robinson at gmail.com Sun Aug 6 03:05:38 2017 From: amos.robinson at gmail.com (Amos Robinson) Date: Sun, 06 Aug 2017 03:05:38 +0000 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: Mutable is the type family from Vector to MVector. So the result type will be an instance of Vector, but the input MVector doesn't need to be. It's a little confusing that freeze is in Data.Unboxed.Vector, not .Mutable: https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Unboxed.html#v:freeze On Sun, 6 Aug 2017 at 12:59 Cody Goodman wrote: > I see the type is: > > freeze :: (PrimMonad > > m, Vector > > v a) => Mutable > > v (PrimState > > m) a -> m (v a) > > > So there is a Vector constrant that MVector will not have. Does the > Mutable type family get around this somehow? > > > There doesn't seem to be a freeze function specifically for > Data.Vector.Unboxed.Mutable.MVector listed at: > https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Unboxed-Mutable.html > > Thanks, > > Cody > > On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson > wrote: > >> I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you are >> sure you won't modify the mutable vector after making it immutable. >> >> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Generic.html#v:freeze >> >> On Sun, 6 Aug 2017 at 12:46 Cody Goodman >> wrote: >> >>> I want to do this so I can use the Data.Vector.Unboxed.Generic functions >>> requiring the Vector constraint, namely the maxIndex function. Implementing >>> maxIndex for Data.Vector.Unboxed.Mutable.MVector would be useful as well, >>> but I'm even more confused at how to do that or where to begin. >>> >>> Here is some stubbed out code demonstrating this. >>> >>> {-# Language ScopedTypeVariables #-} >>> module Main where >>> >>> import Control.Monad.Primitive >>> import qualified Data.Vector.Unboxed >>> import qualified Data.Vector.Generic as VG >>> import qualified Data.Vector.Unboxed.Mutable as VM >>> import qualified Data.Vector.Unboxed as V >>> >>> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >>> toImmutable = undefined >>> >>> main :: IO () >>> main = do >>> v :: VM.MVector RealWorld Int <- VM.new 1 >>> VM.write v 0 (3 :: Int) >>> x <- VM.read v 0 >>> -- y <- VG.head . toImmutable $ v >>> -- print y >>> print $ VM.length v >>> >>> {- >>> Thanks, >>> >>> >>> Cody >>> -} >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 codygman.consulting at gmail.com Sun Aug 6 03:22:40 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sat, 5 Aug 2017 22:22:40 -0500 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: I'm not back at a computer yet, but so I and others reading these archives in the future know: Does that mean that freeze from Data.Vector.Generic.freeze should work for me then? On Sat, Aug 5, 2017 at 10:05 PM, Amos Robinson wrote: > Mutable is the type family from Vector to MVector. So the result type will > be an instance of Vector, but the input MVector doesn't need to be. > It's a little confusing that freeze is in Data.Unboxed.Vector, not > .Mutable: https://hackage.haskell.org/package/vector-0. > 12.0.1/docs/Data-Vector-Unboxed.html#v:freeze > > On Sun, 6 Aug 2017 at 12:59 Cody Goodman > wrote: > >> I see the type is: >> >> freeze :: (PrimMonad >> >> m, Vector >> >> v a) => Mutable >> >> v (PrimState >> >> m) a -> m (v a) >> >> >> So there is a Vector constrant that MVector will not have. Does the >> Mutable type family get around this somehow? >> >> >> There doesn't seem to be a freeze function specifically for >> Data.Vector.Unboxed.Mutable.MVector listed at: >> https://hackage.haskell.org/package/vector-0.12.0.1/docs/ >> Data-Vector-Unboxed-Mutable.html >> >> Thanks, >> >> Cody >> >> On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson >> wrote: >> >>> I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you >>> are sure you won't modify the mutable vector after making it immutable. >>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/ >>> Data-Vector-Generic.html#v:freeze >>> >>> On Sun, 6 Aug 2017 at 12:46 Cody Goodman >>> wrote: >>> >>>> I want to do this so I can use the Data.Vector.Unboxed.Generic >>>> functions requiring the Vector constraint, namely the maxIndex function. >>>> Implementing maxIndex for Data.Vector.Unboxed.Mutable.MVector would be >>>> useful as well, but I'm even more confused at how to do that or where to >>>> begin. >>>> >>>> Here is some stubbed out code demonstrating this. >>>> >>>> {-# Language ScopedTypeVariables #-} >>>> module Main where >>>> >>>> import Control.Monad.Primitive >>>> import qualified Data.Vector.Unboxed >>>> import qualified Data.Vector.Generic as VG >>>> import qualified Data.Vector.Unboxed.Mutable as VM >>>> import qualified Data.Vector.Unboxed as V >>>> >>>> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >>>> toImmutable = undefined >>>> >>>> main :: IO () >>>> main = do >>>> v :: VM.MVector RealWorld Int <- VM.new 1 >>>> VM.write v 0 (3 :: Int) >>>> x <- VM.read v 0 >>>> -- y <- VG.head . toImmutable $ v >>>> -- print y >>>> print $ VM.length v >>>> >>>> {- >>>> Thanks, >>>> >>>> >>>> Cody >>>> -} >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view 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 amos.robinson at gmail.com Sun Aug 6 03:32:09 2017 From: amos.robinson at gmail.com (Amos Robinson) Date: Sun, 06 Aug 2017 03:32:09 +0000 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: Yes, I believe Data.Vector.Generic.freeze will work. But I would use the one from Data.Vector.Unboxed unless you really need the generic version. Sometimes the extra constraints in the generic version can be a bit cumbersome, requiring extra type annotations where the specific versions don't. On Sun, 6 Aug 2017 at 13:22 Cody Goodman wrote: > I'm not back at a computer yet, but so I and others reading these archives > in the future know: Does that mean that freeze from > Data.Vector.Generic.freeze should work for me then? > > On Sat, Aug 5, 2017 at 10:05 PM, Amos Robinson > wrote: > >> Mutable is the type family from Vector to MVector. So the result type >> will be an instance of Vector, but the input MVector doesn't need to be. >> It's a little confusing that freeze is in Data.Unboxed.Vector, not >> .Mutable: >> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Unboxed.html#v:freeze >> >> On Sun, 6 Aug 2017 at 12:59 Cody Goodman >> wrote: >> >>> I see the type is: >>> >>> freeze :: (PrimMonad >>> >>> m, Vector >>> >>> v a) => Mutable >>> >>> v (PrimState >>> >>> m) a -> m (v a) >>> >>> >>> So there is a Vector constrant that MVector will not have. Does the >>> Mutable type family get around this somehow? >>> >>> >>> There doesn't seem to be a freeze function specifically for >>> Data.Vector.Unboxed.Mutable.MVector listed at: >>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Unboxed-Mutable.html >>> >>> Thanks, >>> >>> Cody >>> >>> On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson >>> wrote: >>> >>>> I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you >>>> are sure you won't modify the mutable vector after making it immutable. >>>> >>>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Data-Vector-Generic.html#v:freeze >>>> >>>> On Sun, 6 Aug 2017 at 12:46 Cody Goodman >>>> wrote: >>>> >>>>> I want to do this so I can use the Data.Vector.Unboxed.Generic >>>>> functions requiring the Vector constraint, namely the maxIndex function. >>>>> Implementing maxIndex for Data.Vector.Unboxed.Mutable.MVector would be >>>>> useful as well, but I'm even more confused at how to do that or where to >>>>> begin. >>>>> >>>>> Here is some stubbed out code demonstrating this. >>>>> >>>>> {-# Language ScopedTypeVariables #-} >>>>> module Main where >>>>> >>>>> import Control.Monad.Primitive >>>>> import qualified Data.Vector.Unboxed >>>>> import qualified Data.Vector.Generic as VG >>>>> import qualified Data.Vector.Unboxed.Mutable as VM >>>>> import qualified Data.Vector.Unboxed as V >>>>> >>>>> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >>>>> toImmutable = undefined >>>>> >>>>> main :: IO () >>>>> main = do >>>>> v :: VM.MVector RealWorld Int <- VM.new 1 >>>>> VM.write v 0 (3 :: Int) >>>>> x <- VM.read v 0 >>>>> -- y <- VG.head . toImmutable $ v >>>>> -- print y >>>>> print $ VM.length v >>>>> >>>>> {- >>>>> Thanks, >>>>> >>>>> >>>>> Cody >>>>> -} >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> To (un)subscribe, modify options or view 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 codygman.consulting at gmail.com Sun Aug 6 03:54:05 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sat, 5 Aug 2017 22:54:05 -0500 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: Thanks! I'll try it out in a bit. On Aug 5, 2017 10:32 PM, "Amos Robinson" wrote: > Yes, I believe Data.Vector.Generic.freeze will work. But I would use the > one from Data.Vector.Unboxed unless you really need the generic version. > Sometimes the extra constraints in the generic version can be a bit > cumbersome, requiring extra type annotations where the specific versions > don't. > > On Sun, 6 Aug 2017 at 13:22 Cody Goodman > wrote: > >> I'm not back at a computer yet, but so I and others reading these >> archives in the future know: Does that mean that freeze from >> Data.Vector.Generic.freeze should work for me then? >> >> On Sat, Aug 5, 2017 at 10:05 PM, Amos Robinson >> wrote: >> >>> Mutable is the type family from Vector to MVector. So the result type >>> will be an instance of Vector, but the input MVector doesn't need to be. >>> It's a little confusing that freeze is in Data.Unboxed.Vector, not >>> .Mutable: https://hackage.haskell.org/package/vector-0. >>> 12.0.1/docs/Data-Vector-Unboxed.html#v:freeze >>> >>> On Sun, 6 Aug 2017 at 12:59 Cody Goodman >>> wrote: >>> >>>> I see the type is: >>>> >>>> freeze :: (PrimMonad >>>> >>>> m, Vector >>>> >>>> v a) => Mutable >>>> >>>> v (PrimState >>>> >>>> m) a -> m (v a) >>>> >>>> >>>> So there is a Vector constrant that MVector will not have. Does the >>>> Mutable type family get around this somehow? >>>> >>>> >>>> There doesn't seem to be a freeze function specifically for >>>> Data.Vector.Unboxed.Mutable.MVector listed at: >>>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/ >>>> Data-Vector-Unboxed-Mutable.html >>>> >>>> Thanks, >>>> >>>> Cody >>>> >>>> On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson >>>> wrote: >>>> >>>>> I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you >>>>> are sure you won't modify the mutable vector after making it immutable. >>>>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/ >>>>> Data-Vector-Generic.html#v:freeze >>>>> >>>>> On Sun, 6 Aug 2017 at 12:46 Cody Goodman < >>>>> codygman.consulting at gmail.com> wrote: >>>>> >>>>>> I want to do this so I can use the Data.Vector.Unboxed.Generic >>>>>> functions requiring the Vector constraint, namely the maxIndex function. >>>>>> Implementing maxIndex for Data.Vector.Unboxed.Mutable.MVector would >>>>>> be useful as well, but I'm even more confused at how to do that or where to >>>>>> begin. >>>>>> >>>>>> Here is some stubbed out code demonstrating this. >>>>>> >>>>>> {-# Language ScopedTypeVariables #-} >>>>>> module Main where >>>>>> >>>>>> import Control.Monad.Primitive >>>>>> import qualified Data.Vector.Unboxed >>>>>> import qualified Data.Vector.Generic as VG >>>>>> import qualified Data.Vector.Unboxed.Mutable as VM >>>>>> import qualified Data.Vector.Unboxed as V >>>>>> >>>>>> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >>>>>> toImmutable = undefined >>>>>> >>>>>> main :: IO () >>>>>> main = do >>>>>> v :: VM.MVector RealWorld Int <- VM.new 1 >>>>>> VM.write v 0 (3 :: Int) >>>>>> x <- VM.read v 0 >>>>>> -- y <- VG.head . toImmutable $ v >>>>>> -- print y >>>>>> print $ VM.length v >>>>>> >>>>>> {- >>>>>> Thanks, >>>>>> >>>>>> >>>>>> Cody >>>>>> -} >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> To (un)subscribe, modify options or view 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 codygman.consulting at gmail.com Sun Aug 6 05:32:14 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sun, 6 Aug 2017 00:32:14 -0500 Subject: [Haskell-cafe] Convert Data.Vector.Unboxed.Mutable.MVector to Data.Vector.Unboxed.Vector In-Reply-To: References: Message-ID: Indeed, it worked (thanks again!): {-# Language ScopedTypeVariables #-} module Main where import Control.Monad.Primitive import qualified Data.Vector.Unboxed import qualified Data.Vector.Generic as VG import qualified Data.Vector.Unboxed.Mutable as VM import qualified Data.Vector.Unboxed as V main :: IO () main = do v :: VM.MVector RealWorld Int <- VM.new 1 VM.write v 0 (3 :: Int) x <- VM.read v 0 v' <- V.freeze v print $ VG.head v' print $ VM.length v On Sat, Aug 5, 2017 at 10:54 PM, Cody Goodman wrote: > Thanks! I'll try it out in a bit. > > On Aug 5, 2017 10:32 PM, "Amos Robinson" wrote: > >> Yes, I believe Data.Vector.Generic.freeze will work. But I would use the >> one from Data.Vector.Unboxed unless you really need the generic version. >> Sometimes the extra constraints in the generic version can be a bit >> cumbersome, requiring extra type annotations where the specific versions >> don't. >> >> On Sun, 6 Aug 2017 at 13:22 Cody Goodman >> wrote: >> >>> I'm not back at a computer yet, but so I and others reading these >>> archives in the future know: Does that mean that freeze from >>> Data.Vector.Generic.freeze should work for me then? >>> >>> On Sat, Aug 5, 2017 at 10:05 PM, Amos Robinson >>> wrote: >>> >>>> Mutable is the type family from Vector to MVector. So the result type >>>> will be an instance of Vector, but the input MVector doesn't need to be. >>>> It's a little confusing that freeze is in Data.Unboxed.Vector, not >>>> .Mutable: https://hackage.haskell.org/package/vector-0.12.0. >>>> 1/docs/Data-Vector-Unboxed.html#v:freeze >>>> >>>> On Sun, 6 Aug 2017 at 12:59 Cody Goodman >>>> wrote: >>>> >>>>> I see the type is: >>>>> >>>>> freeze :: (PrimMonad >>>>> >>>>> m, Vector >>>>> >>>>> v a) => Mutable >>>>> >>>>> v (PrimState >>>>> >>>>> m) a -> m (v a) >>>>> >>>>> >>>>> So there is a Vector constrant that MVector will not have. Does the >>>>> Mutable type family get around this somehow? >>>>> >>>>> >>>>> There doesn't seem to be a freeze function specifically for >>>>> Data.Vector.Unboxed.Mutable.MVector listed at: >>>>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat >>>>> a-Vector-Unboxed-Mutable.html >>>>> >>>>> Thanks, >>>>> >>>>> Cody >>>>> >>>>> On Sat, Aug 5, 2017 at 9:56 PM, Amos Robinson >>>> > wrote: >>>>> >>>>>> I think you want "Data.Vector.Generic.freeze", or unsafeFreeze if you >>>>>> are sure you won't modify the mutable vector after making it immutable. >>>>>> https://hackage.haskell.org/package/vector-0.12.0.1/docs/Dat >>>>>> a-Vector-Generic.html#v:freeze >>>>>> >>>>>> On Sun, 6 Aug 2017 at 12:46 Cody Goodman < >>>>>> codygman.consulting at gmail.com> wrote: >>>>>> >>>>>>> I want to do this so I can use the Data.Vector.Unboxed.Generic >>>>>>> functions requiring the Vector constraint, namely the maxIndex function. >>>>>>> Implementing maxIndex for Data.Vector.Unboxed.Mutable.MVector would >>>>>>> be useful as well, but I'm even more confused at how to do that or where to >>>>>>> begin. >>>>>>> >>>>>>> Here is some stubbed out code demonstrating this. >>>>>>> >>>>>>> {-# Language ScopedTypeVariables #-} >>>>>>> module Main where >>>>>>> >>>>>>> import Control.Monad.Primitive >>>>>>> import qualified Data.Vector.Unboxed >>>>>>> import qualified Data.Vector.Generic as VG >>>>>>> import qualified Data.Vector.Unboxed.Mutable as VM >>>>>>> import qualified Data.Vector.Unboxed as V >>>>>>> >>>>>>> toImmutable :: VM.MVector RealWorld Int -> V.Vector Int >>>>>>> toImmutable = undefined >>>>>>> >>>>>>> main :: IO () >>>>>>> main = do >>>>>>> v :: VM.MVector RealWorld Int <- VM.new 1 >>>>>>> VM.write v 0 (3 :: Int) >>>>>>> x <- VM.read v 0 >>>>>>> -- y <- VG.head . toImmutable $ v >>>>>>> -- print y >>>>>>> print $ VM.length v >>>>>>> >>>>>>> {- >>>>>>> Thanks, >>>>>>> >>>>>>> >>>>>>> Cody >>>>>>> -} >>>>>>> _______________________________________________ >>>>>>> Haskell-Cafe mailing list >>>>>>> To (un)subscribe, modify options or view 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 pieter at laeremans.org Mon Aug 7 12:57:29 2017 From: pieter at laeremans.org (Pieter Laeremans) Date: Mon, 07 Aug 2017 14:57:29 +0200 Subject: [Haskell-cafe] Combining pool and Conduit Message-ID: <1502110649.3099399.1065545936.2DEB68CF@webmail.messagingengine.com> Hello, I would like to combine a "Connection Pool" with the conduit library. I have an application were a stream of results from a web api needs to be analysed and stored in a database. Since the analysis is composed of different parts, I combine some parts together ( .|) Some of those parts need a database connection to do their work. Initially I created a Connection and passed it around to each part that needed it, this is sub-optimal. So I wanted to try the "resource-pool" library to address this problem. (https://hackage.haskell.org/package/resource-pool) So instead of a Connection I pass around a (Pool Connection) But I run into problems , and I don't know how to fix them. Here is a simple snippet of code that demonstrates the problem: ------------------------------------------- {-# LANGUAGE RankNTypes #-} module Lib where import Data.Pool import Database.HDBC import Database.HDBC.ODBC import Data.Conduit import Conduit createConnectionPool :: Pool Connection createConnectionPool = undefined processFoo :: Pool Connection -> Consumer String IO () processFoo pool = withResource pool $ \conn -> do mapM_C print ------------------------- I can not get this to compile: src/Lib.hs:15:19: error: • No instance for (MonadBaseControl IO (ConduitM String o IO)) arising from a use of ‘withResource’ • In the expression: withResource pool In the expression: withResource pool $ \ conn -> do { mapM_C print } In an equation for ‘processFoo’: processFoo pool = withResource pool $ \ conn -> do { mapM_C print } But I have no Idea how to tackle this problem. Any suggestions ? Thanks, Pieter -- Pieter Laeremans pieter at laeremans.org From michael at snoyman.com Mon Aug 7 18:15:32 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 7 Aug 2017 21:15:32 +0300 Subject: [Haskell-cafe] Combining pool and Conduit In-Reply-To: <1502110649.3099399.1065545936.2DEB68CF@webmail.messagingengine.com> References: <1502110649.3099399.1065545936.2DEB68CF@webmail.messagingengine.com> Message-ID: Because ConduitM is based on continuations, you can't safely acquire resources inside of it. In order to make safe allocations, you need to use ResourceT. I wrote a blog post two months ago with a lot more information on ResourceT: https://www.fpcomplete.com/blog/2017/06/understanding-resourcet Because of this, you cannot use `withResource`. The error message you're getting is confusing, but this is where it's coming from: because of its continuations, ConduitM cannot provide a MonadBaseControl instance. Instead, you'll need to use the `takeResource` and either `destroyResource` or `putResource` functions, plus something like `bracketP` or `allocate`. On Mon, Aug 7, 2017 at 3:57 PM, Pieter Laeremans wrote: > Hello, > > I would like to combine a "Connection Pool" with the conduit library. > > I have an application were a stream of results from a web api needs to > be analysed and stored in a database. > Since the analysis is composed of different parts, I combine some parts > together ( .|) > > Some of those parts need a database connection to do their work. > Initially I created a Connection and passed it around to each part that > needed it, this is sub-optimal. So I wanted to try the "resource-pool" > library to address this problem. > (https://hackage.haskell.org/package/resource-pool) > > So instead of a Connection I pass around a (Pool Connection) But I run > into problems , and I don't know how to fix them. > > Here is a simple snippet of code that demonstrates the problem: > > > ------------------------------------------- > {-# LANGUAGE RankNTypes #-} > > module Lib where > > import Data.Pool > import Database.HDBC > import Database.HDBC.ODBC > import Data.Conduit > import Conduit > > createConnectionPool :: Pool Connection > createConnectionPool = undefined > > processFoo :: Pool Connection -> Consumer String IO () > processFoo pool = withResource pool $ \conn -> do > mapM_C print > > ------------------------- > > I can not get this to compile: > > src/Lib.hs:15:19: error: > • No instance for (MonadBaseControl IO (ConduitM String o IO)) > arising from a use of ‘withResource’ > • In the expression: withResource pool > In the expression: > withResource pool $ \ conn -> do { mapM_C print } > In an equation for ‘processFoo’: > processFoo pool = withResource pool $ \ conn -> do { mapM_C > print } > > But I have no Idea how to tackle this problem. Any suggestions ? > > Thanks, > > Pieter > > -- > Pieter Laeremans > pieter at laeremans.org > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Mon Aug 7 18:35:10 2017 From: publicityifl at gmail.com (publicityifl at gmail.com) Date: Mon, 07 Aug 2017 18:35:10 +0000 Subject: [Haskell-cafe] Extended deadline: IFL 2017 (29th Symposium on Implementation and Application of Functional Languages) Message-ID: <94eb2c129af25a2cef05562e1bb3@google.com>
Hello,

Please, find below the third call for papers for IFL 2017. Note that some
of the deadlines have been extended. Details are given below.
Please forward these to anyone you think may be interested.
Apologies for any duplicates you may receive.

best regards,
Jurriaan Hage
Publicity Chair of IFL

---

IFL 2017 - CALL FOR PAPERS: DEADLINES EXTENDED
==============================================

29th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES
=======================================================================

University of Bristol, UK

In cooperation with ACM SIGPLAN

Wednesday 30 August - Friday 1 September, 2017

http://iflconference.org/

Scope
-----

The goal of the IFL symposia is to bring together researchers actively engaged
in the implementation and application of functional and function-based
programming languages. IFL 2017 will be a venue for researchers to present and
discuss new ideas and concepts, work in progress, and publication-ripe results
related to the implementation and application of functional languages and
function-based programming.

Peer-review
-----------

Following the IFL tradition, IFL 2017 will use a post-symposium review process
to produce the formal proceedings. All participants of IFL 2017 are invited to
submit either a draft paper or an extended abstract describing work to be
presented at the symposium. At no time may work submitted to IFL be
simultaneously submitted to other venues; submissions must adhere to ACM

SIGPLAN's republication policy:

http://www.sigplan.org/Resources/Policies/Republication

The submissions will be screened by the program committee chair to make sure
they are within the scope of IFL, and will appear in the draft proceedings
distributed at the symposium. Submissions appearing in the draft proceedings
are not peer-reviewed publications. Hence, publications that appear only in the
draft proceedings are not subject to the ACM SIGPLAN republication policy.

After the symposium, authors will be given the opportunity to incorporate the
feedback from discussions at the symposium and will be invited to submit a
revised full article for the formal review process. From the revised
submissions, the program committee will select papers for the formal
proceedings considering their correctness, novelty, originality, relevance,
significance, and clarity. The formal proceedings will appear in the
International Conference Proceedings Series of the ACM Digital Library.

Important dates
---------------

Note that the original deadlines for submission and registration have
been extended.

|                      |                                                           |
| ----------------------| -----------------------------------------------------------|
| Thu 17 August   2017 | Submission deadline draft papers                          |
| Fri 18 August   2017 | Notification of acceptance for presentation               |
| Mon 21 August   2017 | Early registration deadline                               |
| Mon 21 August   2017 | Submission deadline for pre-symposium proceedings         |
| Fri 25 August   2017 | Late registration deadline                                |
| Wed 30 August   2017 - Fri 1 September 2017 | IFL Symposium                      |
| Mon  4 December 2017 | Submission deadline for post-symposium proceedings        |
| Wed 31 January  2018 | Notification of acceptance for post-symposium proceedings |
| Mon 12 March    2018 | Camera-ready version for post-symposium proceedings       |

Submission details
------------------

Prospective authors are encouraged to submit papers or extended abstracts to be
published in the draft proceedings and to present them at the symposium. All
contributions must be written in English. Papers must use the new ACM two
columns conference format, which can be found at:

http://www.acm.org/publications/proceedings-template

For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For
the post-symposium proceedings the page limit of 12 pages is firm.

Authors submit through EasyChair:

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

Topics
------

IFL welcomes submissions describing practical and theoretical work as well as
submissions describing applications and tools in the context of functional
programming. If you are not sure whether your work is appropriate for IFL 2017,
please contact the PC chair at nicolas.wu at bristol.ac.uk. Topics of interest include, but are not limited to:

- language concepts
- type systems, type checking, type inferencing
- compilation techniques
- staged compilation
- run-time function specialization
- run-time code generation
- partial evaluation
- (abstract) interpretation
- metaprogramming
- generic programming
- automatic program generation
- array processing
- concurrent/parallel programming
- concurrent/parallel program execution
- embedded systems
- web applications
- (embedded) domain specific languages
- security
- novel memory management techniques
- run-time profiling performance measurements
- debugging and tracing
- virtual/abstract machine architectures
- validation, verification of functional programs
- tools and programming techniques
- (industrial) applications

Peter Landin Prize
------------------

The Peter Landin Prize is awarded to the best paper presented at the symposium
every year. The honored article is selected by the program committee based on
the submissions received for the formal review process. The prize carries a
cash award equivalent to 150 Euros.


Programme committee
-------------------

Chair: Nicolas Wu, University of Bristol, UK

- Kenichi Asai, Ochanomizu University, Japan
- Sandrine Blazy, University of Rennes 1, France
- Carlos Camarao, Universidade Federal de Minas Gerais, Brazil
- Stephen Dolan, University of Cambridge, UK
- Jurriaan Hage, Utrecht University, Netherlands
- Yukiyoshi Kameyama, University of Tsukuba, Japan
- Benjamin Lerner, Brown University, USA
- Bas Lijnse, Radboud University, Netherlands
- Garrett Morris, University of Kansas, USA
- Miguel Pagano, Universidad Nacional de Córdoba, Argentina
- Tomas Petricek, Alan Turing Institute, UK
- Maciej Piróg, University of Wroclaw, Poland
- Exequiel Rivas, Universidad Nacional de Rosario, Argentina
- Neil Sculthorpe, Nottingham Trent University, UK
- Melinda Toth, Eotvos Lorand University, Hungary
- Phil Trinder, Glasgow University, UK
- Kanae Tsushima, National Institute of Informatics, Japan
- Marcos Viera, Universidad de la Republica, Uruguay
- Meng Wang, University of Kent, UK

Venue
-----

The IFL 2017 will be held in association with the Department of
Computer Science, University of Bristol, UK. Bristol is located in
South West England, and can be easily reached from Bristol Airport.

See the website for more information on the venue.

 

powered by GSM. Free mail merge and email marketing software for Gmail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieter at laeremans.org Mon Aug 7 19:02:55 2017 From: pieter at laeremans.org (Pieter Laeremans) Date: Mon, 7 Aug 2017 21:02:55 +0200 Subject: [Haskell-cafe] Combining pool and Conduit In-Reply-To: References: <1502110649.3099399.1065545936.2DEB68CF@webmail.messagingengine.com> Message-ID: <3003C90B-75C3-4483-8A3F-A2FFA0C1AFDB@laeremans.org> Thans a lot! Pieter Laeremans > On 7 Aug 2017, at 20:15, Michael Snoyman wrote: > > Because ConduitM is based on continuations, you can't safely acquire resources inside of it. In order to make safe allocations, you need to use ResourceT. I wrote a blog post two months ago with a lot more information on ResourceT: > > https://www.fpcomplete.com/blog/2017/06/understanding-resourcet > > Because of this, you cannot use `withResource`. The error message you're getting is confusing, but this is where it's coming from: because of its continuations, ConduitM cannot provide a MonadBaseControl instance. Instead, you'll need to use the `takeResource` and either `destroyResource` or `putResource` functions, plus something like `bracketP` or `allocate`. > >> On Mon, Aug 7, 2017 at 3:57 PM, Pieter Laeremans wrote: >> Hello, >> >> I would like to combine a "Connection Pool" with the conduit library. >> >> I have an application were a stream of results from a web api needs to >> be analysed and stored in a database. >> Since the analysis is composed of different parts, I combine some parts >> together ( .|) >> >> Some of those parts need a database connection to do their work. >> Initially I created a Connection and passed it around to each part that >> needed it, this is sub-optimal. So I wanted to try the "resource-pool" >> library to address this problem. >> (https://hackage.haskell.org/package/resource-pool) >> >> So instead of a Connection I pass around a (Pool Connection) But I run >> into problems , and I don't know how to fix them. >> >> Here is a simple snippet of code that demonstrates the problem: >> >> >> ------------------------------------------- >> {-# LANGUAGE RankNTypes #-} >> >> module Lib where >> >> import Data.Pool >> import Database.HDBC >> import Database.HDBC.ODBC >> import Data.Conduit >> import Conduit >> >> createConnectionPool :: Pool Connection >> createConnectionPool = undefined >> >> processFoo :: Pool Connection -> Consumer String IO () >> processFoo pool = withResource pool $ \conn -> do >> mapM_C print >> >> ------------------------- >> >> I can not get this to compile: >> >> src/Lib.hs:15:19: error: >> • No instance for (MonadBaseControl IO (ConduitM String o IO)) >> arising from a use of ‘withResource’ >> • In the expression: withResource pool >> In the expression: >> withResource pool $ \ conn -> do { mapM_C print } >> In an equation for ‘processFoo’: >> processFoo pool = withResource pool $ \ conn -> do { mapM_C >> print } >> >> But I have no Idea how to tackle this problem. Any suggestions ? >> >> Thanks, >> >> Pieter >> >> -- >> Pieter Laeremans >> pieter at laeremans.org >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Mon Aug 7 19:03:26 2017 From: michael at snoyman.com (Michael Snoyman) Date: Mon, 07 Aug 2017 19:03:26 +0000 Subject: [Haskell-cafe] Combining pool and Conduit In-Reply-To: <3003C90B-75C3-4483-8A3F-A2FFA0C1AFDB@laeremans.org> References: <1502110649.3099399.1065545936.2DEB68CF@webmail.messagingengine.com> <3003C90B-75C3-4483-8A3F-A2FFA0C1AFDB@laeremans.org> Message-ID: No problem On Mon, Aug 7, 2017, 10:02 PM Pieter Laeremans wrote: > Thans a lot! > > > Pieter Laeremans > > On 7 Aug 2017, at 20:15, Michael Snoyman wrote: > > Because ConduitM is based on continuations, you can't safely acquire > resources inside of it. In order to make safe allocations, you need to use > ResourceT. I wrote a blog post two months ago with a lot more information > on ResourceT: > > https://www.fpcomplete.com/blog/2017/06/understanding-resourcet > > Because of this, you cannot use `withResource`. The error message you're > getting is confusing, but this is where it's coming from: because of its > continuations, ConduitM cannot provide a MonadBaseControl instance. > Instead, you'll need to use the `takeResource` and either `destroyResource` > or `putResource` functions, plus something like `bracketP` or `allocate`. > > On Mon, Aug 7, 2017 at 3:57 PM, Pieter Laeremans > wrote: > >> Hello, >> >> I would like to combine a "Connection Pool" with the conduit library. >> >> I have an application were a stream of results from a web api needs to >> be analysed and stored in a database. >> Since the analysis is composed of different parts, I combine some parts >> together ( .|) >> >> Some of those parts need a database connection to do their work. >> Initially I created a Connection and passed it around to each part that >> needed it, this is sub-optimal. So I wanted to try the "resource-pool" >> library to address this problem. >> (https://hackage.haskell.org/package/resource-pool) >> >> So instead of a Connection I pass around a (Pool Connection) But I run >> into problems , and I don't know how to fix them. >> >> Here is a simple snippet of code that demonstrates the problem: >> >> >> ------------------------------------------- >> {-# LANGUAGE RankNTypes #-} >> >> module Lib where >> >> import Data.Pool >> import Database.HDBC >> import Database.HDBC.ODBC >> import Data.Conduit >> import Conduit >> >> createConnectionPool :: Pool Connection >> createConnectionPool = undefined >> >> processFoo :: Pool Connection -> Consumer String IO () >> processFoo pool = withResource pool $ \conn -> do >> mapM_C print >> >> ------------------------- >> >> I can not get this to compile: >> >> src/Lib.hs:15:19: error: >> • No instance for (MonadBaseControl IO (ConduitM String o IO)) >> arising from a use of ‘withResource’ >> • In the expression: withResource pool >> In the expression: >> withResource pool $ \ conn -> do { mapM_C print } >> In an equation for ‘processFoo’: >> processFoo pool = withResource pool $ \ conn -> do { mapM_C >> print } >> >> But I have no Idea how to tackle this problem. Any suggestions ? >> >> Thanks, >> >> Pieter >> >> -- >> Pieter Laeremans >> pieter at laeremans.org >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Tue Aug 8 16:30:52 2017 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 8 Aug 2017 12:30:52 -0400 Subject: [Haskell-cafe] type (++) = (<>) In-Reply-To: <201707031729.v63HTHu5001972@coolidge.cs.Dartmouth.EDU> References: <201707031729.v63HTHu5001972@coolidge.cs.Dartmouth.EDU> Message-ID: There was a great deal of monomorphization that went into the Haskell 98 standard under the nominal goal of trying to help newcomers to the language with simpler error messages. For more you can read old mailing list posts from that timeframe. As a technical aside, (<>) is used for Monoid (and soon will upgrade to Semigroup) not MonadPlus, so the symbols have diverged in sentiment. Not only that, but (++) and (<>) get mixed in existing pretty printing code a good deal, and have different fixities, and must, lest a bunch of code silently change semantics. This was one reason why (<>) was added (to match existing practice in the pretty printing libraries) rather than generalizing (++). Once we've added (<>), generalizing (++) becomes less urgent and actually has some cons. Notably, there is a subset of the community that finds the current form of map and (++) potentially useful for teaching about lists. If they generalized to become fmap and (<|>) or (<>) then we create a redundant notation for an existing thing, with no roadmap for replacing one with the other, and lose the teaching tool. As a general guideline, the core libraries committee has been trying to avoid introducing redundant names that have the exact same type signature, with possibly different fixity, but where one is exported from the class and the other isn't, because it makes it yet another detail you have to memorize to know which one is the one in the class and can be refined: the types simply don't tell you. Having one version that is strictly more general enables one subset of the community to simply forget about the other one and move on, and another subset that aren't fans of rampant abstraction to use the one with more specific type when they want to clearly signal intent. I'd be slightly more open to discussions about eventual removal or exile of the redundant members to an appropriate module than generalization under that guideline, but that isn't a hill I'd want to die on. (++) is pretty well embedded in Haskell's DNA. *tl;dr* It happened at first because of a great wave of monomorphization, and there is at least a defensible reason why it hasn't generalized back in the presence of other changes that have happened in the meantime. -Edward On Mon, Jul 3, 2017 at 1:29 PM, Doug McIlroy wrote: > > What do you think of making (++) the same as (<>) > > This seems to be a call for returning to the old situation in > which (++) was an operator of class MonadPlus. Why was that > abolished in Haskell 98? > > Doug > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at brisammon.fastmail.fm Tue Aug 8 17:45:50 2017 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Tue, 8 Aug 2017 13:45:50 -0400 Subject: [Haskell-cafe] FFI and a struct containing a string and allocating memory space Message-ID: <20170808134550.0c79359f7945b5dd57ffc59c@brisammon.fastmail.fm> If I have a struct like struct EventInfo { char * event_name; int year; int month; int date; } and an associated haskell datatype that I want to marshall into it, it seems to me that I can't take advantage of the speed advantages of alloca (and its friends like "with") The only safe way I've thought of to do this is to do this is to have the poke function for EventInfo (the associated haskell type) call malloc (or newCAString or something) and then poking the string into the newly allocated space. I realized after a few successful runs of using withCString in the poke function for EventInfo, that I don't think that this (calling withCString from the poke function) was a safe approach, and I'm thinking it was just dumb luck that this worked at all. Thoughts? Am I on the right track? Am I missing any better approaches? (I'm using Haskell 8.0.1 and a Storable instance for EventInfo, BTW) From chpatrick at gmail.com Tue Aug 8 18:03:16 2017 From: chpatrick at gmail.com (Patrick Chilton) Date: Tue, 8 Aug 2017 20:03:16 +0200 Subject: [Haskell-cafe] FFI and a struct containing a string and allocating memory space In-Reply-To: <20170808134550.0c79359f7945b5dd57ffc59c@brisammon.fastmail.fm> References: <20170808134550.0c79359f7945b5dd57ffc59c@brisammon.fastmail.fm> Message-ID: You could make your own `withEventInfo :: EventInfo -> (Ptr CEventInfo -> IO a) -> IO a` that calls withCString internally, and gives the passed function a pointer that is valid for the execution of the function. You could also use inline-c and create a struct EventInfo when you need it, and then you know that your bindings are typesafe, which you don't get with Storable etc. On Tue, Aug 8, 2017 at 7:45 PM, Brian Sammon < haskell-cafe at brisammon.fastmail.fm> wrote: > If I have a struct like > struct EventInfo { > char * event_name; > int year; > int month; > int date; > } > > and an associated haskell datatype that I want to marshall into it, it > seems to me that I can't take advantage of the speed advantages of alloca > (and its friends like "with") > > The only safe way I've thought of to do this is to do this is to have the > poke function for EventInfo (the associated haskell type) call malloc (or > newCAString or something) and then poking the string into the newly > allocated space. > I realized after a few successful runs of using withCString in the poke > function for EventInfo, that I don't think that this (calling withCString > from the poke function) was a safe approach, and I'm thinking it was just > dumb luck that this worked at all. > > Thoughts? Am I on the right track? Am I missing any better approaches? > > (I'm using Haskell 8.0.1 and a Storable instance for EventInfo, BTW) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lindsey at composition.al Tue Aug 8 20:19:35 2017 From: lindsey at composition.al (Lindsey Kuper) Date: Tue, 8 Aug 2017 13:19:35 -0700 Subject: [Haskell-cafe] DSLDI 2017: Final Call for Talk Proposals (deadline extended) Message-ID: ********************************************************************* FINAL CALL FOR TALK PROPOSALS DSLDI 2017 Fifth Workshop on Domain-Specific Language Design and Implementation October 22, 2017 Vancouver, Canada Co-located with SPLASH http://2017.splashcon.org/track/dsldi-2017 https://twitter.com/wsdsldi ********************************************************************* **Deadline for talk proposals extended to Friday, 11 August 2017** Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. ## Workshop Goal Domain-Specific Language Design and Implementation (DSLDI) is a workshop intended to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. ## Workshop Format DSLDI is a single-day workshop and will consist of an invited speaker followed by moderated audience discussions structured around a series of short talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI’s area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice ## Call for Talk Proposals We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 11th, 2017 * Notification: September 11th, 2017 * Workshop: October 22nd, 2017 * Submission website: https://dsldi17.hotcrp.com/ ## Workshop Organization Co-chairs: * Lindsey Kuper (lindsey at composition.al), Intel Labs * Eric Walkingshaw (eric.walkingshaw at oregonstate.edu), Oregon State University Follow us on Twitter at https://twitter.com/wsdsldi Program committee: * Nada Amin (EPFL/University of Cambridge) * Eric Holk (Google) * Gabriele Keller (Data61, CSIRO (formerly NICTA) and UNSW) * Rebekah Leslie-Hurd (Intel Labs) * Chris Martens (NCSU) * Lee Pike (Galois) * Jonathan Ragan-Kelley (UC Berkeley) * Jesús Sánchez Cuadrado (Autonomous University of Madrid) * Vincent St-Amour (Northwestern University) * Philip Wadler (University of Edinburgh) -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at brisammon.fastmail.fm Wed Aug 9 02:19:45 2017 From: haskell-cafe at brisammon.fastmail.fm (Brian Sammon) Date: Tue, 8 Aug 2017 22:19:45 -0400 Subject: [Haskell-cafe] FFI and a struct containing a string and allocating memory space In-Reply-To: References: <20170808134550.0c79359f7945b5dd57ffc59c@brisammon.fastmail.fm> Message-ID: <20170808221945.e0d2f78158aa8946eac09fa6@brisammon.fastmail.fm> On Tue, 8 Aug 2017 20:03:16 +0200 Patrick Chilton wrote: > You could make your own `withEventInfo :: EventInfo -> (Ptr CEventInfo -> > IO a) -> IO a` that calls withCString internally, and gives the passed > function a pointer that is valid for the execution of the function. You This seems a little more complicated than the malloc method, so I think I'd save it for if using the malloc method makes my program too slow. Also, I was thinking of a solution similar to what you suggested, and it seems like it would require having the "poke" for the EventInfo Storable not actually put all the data in the C Struct (or not actually using "poke", but something lower-level, for the more-efficient marshalling system). I envisioned having the EventInfo poke only poking the int fields, and the withCString that populates the string field living elsewhere. It seems like this would work, but it seems not quite kosher in some way to have a poke that doesn't marshal the full set of fields. From jeffbrown.the at gmail.com Thu Aug 10 22:29:00 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 10 Aug 2017 15:29:00 -0700 Subject: [Haskell-cafe] Investigating single-letter type variables Message-ID: Haskellers tend to use uninformative single-letter type variables. A case in point: Megaparsec> :i ParsecT type role ParsecT nominal nominal representational representational newtype ParsecT e s (m :: * -> *) a ... I've gotten used to the conventions that "a" stands for anything and "m" stands for monad -- but without digging into the code it wasn't initially obvious to me whether "s" stood for stream or state. Single-letter type variables don't seem to always be the standard, though: Megaparsec> :i between between :: Applicative m => m open -> m close -> m a -> m a -- Defined in ‘Control.Applicative.Combinators’ My questions are: (1) Are the brevity gains worth the confusion costs? (2) If I'm looking at a new library for the first time and trying to figure out what a type variable stands for, is there a canonical way to do it? Flailing through documentation at random? Unifying types by hand? -- 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 cdsmith at gmail.com Thu Aug 10 22:39:04 2017 From: cdsmith at gmail.com (Chris Smith) Date: Thu, 10 Aug 2017 15:39:04 -0700 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: References: Message-ID: The following probably captures community practice: a) If the type is truly arbitrary, such that there is no meaningful info to add beyond the positions it occurs in the type, then give it an arbitrary name, like 'a', 'b', or 'c'. b) If there is a convention associated with a type or class that occurs in the type signature, to which the type variable is a parameter, then use that (usually one-letter) name. c) Otherwise, use a longer name. You seem to be making the case that (b) is confusing. You may be right, and I have no particular desire to defend the current practice. But if you're wondering where one would be expected to find the meaning, that's it: find the primary type (or class) to which it's a parameter, and there is usually a convention set forth there. On Thu, Aug 10, 2017 at 3:29 PM, Jeffrey Brown wrote: > Haskellers tend to use uninformative single-letter type variables. A case > in point: > > Megaparsec> :i ParsecT > > type role ParsecT nominal nominal representational representational > newtype ParsecT e s (m :: * -> *) a ... > > I've gotten used to the conventions that "a" stands for anything and "m" > stands for monad -- but without digging into the code it wasn't initially > obvious to me whether "s" stood for stream or state. > > Single-letter type variables don't seem to always be the standard, though: > > Megaparsec> :i between > between :: Applicative m => m open -> m close -> m a -> m a > -- Defined in ‘Control.Applicative.Combinators’ > > My questions are: (1) Are the brevity gains worth the confusion costs? (2) > If I'm looking at a new library for the first time and trying to figure out > what a type variable stands for, is there a canonical way to do it? > Flailing through documentation at random? Unifying types by hand? > > -- > 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 tikhon at jelv.is Thu Aug 10 22:43:54 2017 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 10 Aug 2017 15:43:54 -0700 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: References: Message-ID: I've tried using longer type variable names in some of my personal projects and found a surprising problem: it became harder to tell types from value-level expressions at a glance. In a lot of cases, I actually found the resulting code harder to read on net. There are still times when I use longer type variable names in my code, but I now think that single-letter names are actually a good default—I need a good reason to deviate from them. I think this happens because type signatures tend to be short, relatively self-contained and often repeated. I want to be able to parse type signatures quickly, at a glance. Longer type variables might be clearer the first time you encounter a library, but they often become a pain once you're familiar with it. (I follow the same reasoning for using short names for function arguments and local definitions that are used in a restricted scope.) :browse through Parsec and consider how many ParsecTs you see, often with multiple in a single type signature. With this much repetition, variables consistently named by connection become useful. Sure, you might need to learn the convention, but the up-front work pays off for itself in any non-trivial use of the library. Of course, there should also be clear documentation on the type definition defining what the variables mean. Gabriel Gonzalez's Pipes library is a perfect example of how this can be done. On Aug 10, 2017 6:32 PM, "Jeffrey Brown" wrote: > Haskellers tend to use uninformative single-letter type variables. A case > in point: > > Megaparsec> :i ParsecT > > type role ParsecT nominal nominal representational representational > newtype ParsecT e s (m :: * -> *) a ... > > I've gotten used to the conventions that "a" stands for anything and "m" > stands for monad -- but without digging into the code it wasn't initially > obvious to me whether "s" stood for stream or state. > > Single-letter type variables don't seem to always be the standard, though: > > Megaparsec> :i between > between :: Applicative m => m open -> m close -> m a -> m a > -- Defined in ‘Control.Applicative.Combinators’ > > My questions are: (1) Are the brevity gains worth the confusion costs? (2) > If I'm looking at a new library for the first time and trying to figure out > what a type variable stands for, is there a canonical way to do it? > Flailing through documentation at random? Unifying types by hand? > > -- > 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 trebla at vex.net Thu Aug 10 23:08:18 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 10 Aug 2017 19:08:18 -0400 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: References: Message-ID: <4269d6b5-b97b-702d-d761-c6ba53114878@vex.net> On 2017-08-10 06:29 PM, Jeffrey Brown wrote: > Haskellers tend to use uninformative single-letter type variables. A Do you prefer this? id :: domain ~ codomain => domain -> codomain id argument = return_value where return_value = argument From wolfgang-it at jeltsch.info Thu Aug 10 23:16:04 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 11 Aug 2017 02:16:04 +0300 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope Message-ID: <1502406964.17229.8.camel@jeltsch.info> Hi! GHC has some support for referring to existentially quantified type variables. For example, consider the following definition: > data SomeList = forall a . SomeList [a] With the ScopedTypeVariables extension, you can get hold of the concrete type a used in a SomeList value: > f :: SomeList -> SomeList > f (SomeList [x :: a]) = SomeList xs where > >     xs :: [a] >     xs = [x, x] However, this approach does not work if there are no fields whose type involves the existentially quantified type variable. Consider, for example, the following definition: > data IsListType a where > >     IsListType :: IsListType [b] For each type T, we can match a value of type IsListType T against the pattern IsListType. If this succeeds, we know that T is a list type, but we do not have access to the respective element type. Is there a way to determine existentially quantified type variables like the b in the above example? All the best, Wolfgang From michaelburge at pobox.com Thu Aug 10 23:35:02 2017 From: michaelburge at pobox.com (Michael Burge) Date: Thu, 10 Aug 2017 16:35:02 -0700 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: <1502406964.17229.8.camel@jeltsch.info> References: <1502406964.17229.8.camel@jeltsch.info> Message-ID: Could something like this work for you? Here, a ~ b and you have access to b: case (IsListType :: IsListType [a], Proxy :: Proxy a) of (_, proxy :: Proxy b) -> asProxyTypeOf undefined proxy :: b On Thu, Aug 10, 2017 at 4:16 PM, Wolfgang Jeltsch wrote: > Hi! > > GHC has some support for referring to existentially quantified type > variables. For example, consider the following definition: > > > data SomeList = forall a . SomeList [a] > > With the ScopedTypeVariables extension, you can get hold of the concrete > type a used in a SomeList value: > > > f :: SomeList -> SomeList > > f (SomeList [x :: a]) = SomeList xs where > > > > xs :: [a] > > xs = [x, x] > > However, this approach does not work if there are no fields whose type > involves the existentially quantified type variable. Consider, for > example, the following definition: > > > data IsListType a where > > > > IsListType :: IsListType [b] > > For each type T, we can match a value of type IsListType T against the > pattern IsListType. If this succeeds, we know that T is a list type, but > we do not have access to the respective element type. > > Is there a way to determine existentially quantified type variables like > the b in the above example? > > All the best, > Wolfgang > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 smart-cactus.org Thu Aug 10 23:39:54 2017 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 10 Aug 2017 19:39:54 -0400 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: <1502406964.17229.8.camel@jeltsch.info> References: <1502406964.17229.8.camel@jeltsch.info> Message-ID: <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> On August 10, 2017 7:16:04 PM EDT, Wolfgang Jeltsch wrote: >Hi! > >GHC has some support for referring to existentially quantified type >variables. For example, consider the following definition: > >> data SomeList = forall a . SomeList [a] > >With the ScopedTypeVariables extension, you can get hold of the >concrete >type a used in a SomeList value: > >> f :: SomeList -> SomeList >> f (SomeList [x :: a]) = SomeList xs where >> >>     xs :: [a] >>     xs = [x, x] > >However, this approach does not work if there are no fields whose type >involves the existentially quantified type variable. Consider, for >example, the following definition: > >> data IsListType a where >> >>     IsListType :: IsListType [b] > >For each type T, we can match a value of type IsListType T against the >pattern IsListType. If this succeeds, we know that T is a list type, >but >we do not have access to the respective element type. > >Is there a way to determine existentially quantified type variables >like >the b in the above example? > >All the best, >Wolfgang >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. Note that the feature described in #11350 will provide a quite direct way to accomplish this by allowing type applications in pattern matches. From wolfgang-it at jeltsch.info Thu Aug 10 23:48:53 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 11 Aug 2017 02:48:53 +0300 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: References: <1502406964.17229.8.camel@jeltsch.info> Message-ID: <1502408933.17229.14.camel@jeltsch.info> Hi! I must say that I do not really understand this, but I nevertheless doubt that it solves my problem. In your code, you are already starting with the value IsListType whose type you specify as [a]. In this case, there is nothing to find out about the element type; you already know that it is a. My situation is that I have some type l and a value p :: IsListType l. A successful match of p against the pattern IsListType tells me that there is an a with l ~ [a]. However, I cannot refer to this a. All the best, Wolfgang Am Donnerstag, den 10.08.2017, 16:35 -0700 schrieb Michael Burge: > Could something like this work for you? Here, a ~ b and you have > access to b: > > case (IsListType :: IsListType [a], Proxy :: Proxy a) of >     (_, proxy :: Proxy b) -> asProxyTypeOf undefined proxy :: b > > On Thu, Aug 10, 2017 at 4:16 PM, Wolfgang Jeltsch > .info> wrote: > > Hi! > > > > GHC has some support for referring to existentially quantified type > > variables. For example, consider the following definition: > > > > > data SomeList = forall a . SomeList [a] > > > > With the ScopedTypeVariables extension, you can get hold of the > > concrete > > type a used in a SomeList value: > > > > > f :: SomeList -> SomeList > > > f (SomeList [x :: a]) = SomeList xs where > > > > > >     xs :: [a] > > >     xs = [x, x] > > > > However, this approach does not work if there are no fields whose > > type > > involves the existentially quantified type variable. Consider, for > > example, the following definition: > > > > > data IsListType a where > > > > > >     IsListType :: IsListType [b] > > > > For each type T, we can match a value of type IsListType T against > > the > > pattern IsListType. If this succeeds, we know that T is a list type, > > but > > we do not have access to the respective element type. > > > > Is there a way to determine existentially quantified type variables > > like > > the b in the above example? > > > > All the best, > > Wolfgang > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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 wolfgang-it at jeltsch.info Fri Aug 11 00:08:03 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 11 Aug 2017 03:08:03 +0300 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> References: <1502406964.17229.8.camel@jeltsch.info> <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> Message-ID: <1502410083.17229.18.camel@jeltsch.info> Am Donnerstag, den 10.08.2017, 19:39 -0400 schrieb Ben Gamari: > On August 10, 2017 7:16:04 PM EDT, Wolfgang Jeltsch wrote: > > Consider, for example, the following definition: > > > > > data IsListType a where > > > > > >     IsListType :: IsListType [b] > > > > For each type T, we can match a value of type IsListType T against > > the pattern IsListType. If this succeeds, we know that T is a list > > type, but we do not have access to the respective element type. > > > > Is there a way to determine existentially quantified type variables > > like the b in the above example? > > Note that the feature described in #11350 will provide a quite direct > way to accomplish this by allowing type applications in pattern > matches. Yes, this feature seems to provide what I need. In my particular use case, it allows for pretty clear code. Is there also a solution that does not involve using this (unimplemented) feature? All the best, Wolfgang From lexi.lambda at gmail.com Fri Aug 11 00:29:09 2017 From: lexi.lambda at gmail.com (Alexis King) Date: Thu, 10 Aug 2017 17:29:09 -0700 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: <1502410083.17229.18.camel@jeltsch.info> References: <1502406964.17229.8.camel@jeltsch.info> <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> <1502410083.17229.18.camel@jeltsch.info> Message-ID: <952A7F11-5505-499D-9B57-8608AAFAADF0@gmail.com> > On Aug 10, 2017, at 5:08 PM, Wolfgang Jeltsch > wrote: > > Is there also a solution that does not involve using this > (unimplemented) feature? I get the feeling there is a better way to do this, but I found something of a hack that I think does what you want. Using Data.Type.Equality, you can match on Refl to bring the `b` into scope. import Data.Type.Equality f :: forall a. IsListType a -> () f IsListType = case Refl of (Refl :: (a :~: [b])) -> () This is sort of silly, though. Alexis From jeffbrown.the at gmail.com Fri Aug 11 00:47:14 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 10 Aug 2017 17:47:14 -0700 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: <4269d6b5-b97b-702d-d761-c6ba53114878@vex.net> References: <4269d6b5-b97b-702d-d761-c6ba53114878@vex.net> Message-ID: > it became harder to tell types from value-level expressions at a glance Font differences seem like a more natural way to distinguish those. > Do you prefer this? > > id :: domain ~ codomain => domain -> codomain ... Lol no. Maybe a good solution would be, rather than longer names, some automated way for a user to ask whether a type variable like 'a' carries any semantics, or is truly free to be anything. If I'm learning a library from the top down, it's not (as far as I can remember) a problem. But sometimes one library uses a single function buried deep in another library. In those situations, the current status-quo recipe, "just flail around (reading documentation or manually unifying types) until you get it," seems improvable. But if y'all gurus don't think it's a big deal, I'll take your word for it, and wait for those flailings to become instinctual. On Thu, Aug 10, 2017 at 4:08 PM, Albert Y. C. Lai wrote: > On 2017-08-10 06:29 PM, Jeffrey Brown wrote: > >> Haskellers tend to use uninformative single-letter type variables. A >> > > Do you prefer this? > > id :: domain ~ codomain => domain -> codomain > id argument = return_value > where > return_value = argument > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 will.yager at gmail.com Fri Aug 11 01:08:53 2017 From: will.yager at gmail.com (Will Yager) Date: Thu, 10 Aug 2017 19:08:53 -0600 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: References: Message-ID: Without actually addressing the question, here are some rules of thumb I use for identifying and choosing type variables: a - whatever. Usually return type, thing inside functor, etc. If you need more than one, you can use b/c. m - usually monad, sometimes just applicative. Can use n if you need more. s - state or state token f - usually functor or more. Can use t if you need more. e - error i - Index r/o - "Result" or "Output" with no real consistency on typeclass constraints. k/v - Key/Value w - result monoid These are by no means particularly hard and fast rules, but they're the first things I jump to when I see a type variable. I do try to use more descriptive names if I don't think it will be fairly obvious from context. --Will > On Aug 10, 2017, at 4:29 PM, Jeffrey Brown wrote: > > > newtype ParsecT e s (m :: * -> *) a ... > > I've gotten used to the conventions that "a" stands for anything and "m" stands for monad -- but without digging into the code it wasn't initially obvious to me whether "s" stood for stream or state. > From rf at rufflewind.com Fri Aug 11 02:10:29 2017 From: rf at rufflewind.com (Phil Ruffwind) Date: Thu, 10 Aug 2017 22:10:29 -0400 Subject: [Haskell-cafe] Investigating single-letter type variables In-Reply-To: References: Message-ID: <1502417429.3112042.1069906896.07C20161@webmail.messagingengine.com> > (2) If I'm looking at a new library for the first time and trying to figure > out what a type variable stands for, is there a canonical way to do it? Type variables inherently don't have any meaning – the meaning only comes from how they are used and how they are constrained. Therefore, you need to look for clues based on (1) the constraints on the type variable, if any, and (2) the types that use the variable. For parsec it's pretty easy because the type variables are often constrained by Stream and used by the ParsecT type. The documentation of parsec is really detailed: both Stream and ParsecT tell you precisely what 's' and 'm' are, and the library is very consistent with this convention. IMO, good documentation should always explain every type variable in every `data` or `newtype` declaration. I would say part of the reason Haskell uses single-letter variables a lot is that a lot of the code are very general and the authors did not want to impose their domain-specific interpretation on it. In some situations (e.g. application code, domain-specific libraries), writing out the variables in full can be meaningful, but in library code this is rare. From zemyla at gmail.com Fri Aug 11 05:20:12 2017 From: zemyla at gmail.com (Zemyla) Date: Fri, 11 Aug 2017 00:20:12 -0500 Subject: [Haskell-cafe] FFI and a struct containing a string and allocating memory space In-Reply-To: <20170808221945.e0d2f78158aa8946eac09fa6@brisammon.fastmail.fm> References: <20170808134550.0c79359f7945b5dd57ffc59c@brisammon.fastmail.fm> <20170808221945.e0d2f78158aa8946eac09fa6@brisammon.fastmail.fm> Message-ID: Then have a separate struct and datatype for the last three fields, and make that Storable. Alternatively, look into using ForeignPtrs, so you can have the finalizer free the memory for the EventInfo. Another thing you might try instead, if you have control of the code, is to change EventInfo to struct EventInfo { int year; int month; int day; char event_name[1]; }; and use the variable-sized-struct-array trick whose actual name I don't know. On Tue, Aug 8, 2017 at 9:19 PM, Brian Sammon wrote: > On Tue, 8 Aug 2017 20:03:16 +0200 > Patrick Chilton wrote: > >> You could make your own `withEventInfo :: EventInfo -> (Ptr CEventInfo -> >> IO a) -> IO a` that calls withCString internally, and gives the passed >> function a pointer that is valid for the execution of the function. You > > This seems a little more complicated than the malloc method, so I think I'd save it for if using the malloc method makes my program too slow. > > Also, I was thinking of a solution similar to what you suggested, and it seems like it would require having the "poke" for the EventInfo Storable not actually put all the data in the C Struct (or not actually using "poke", but something lower-level, for the more-efficient marshalling system). I envisioned having the EventInfo poke only poking the int fields, and the withCString that populates the string field living elsewhere. It seems like this would work, but it seems not quite kosher in some way to have a poke that doesn't marshal the full set of fields. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 kai at kzhang.org Fri Aug 11 07:04:24 2017 From: kai at kzhang.org (Kai Zhang) Date: Fri, 11 Aug 2017 07:04:24 +0000 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: <952A7F11-5505-499D-9B57-8608AAFAADF0@gmail.com> References: <1502406964.17229.8.camel@jeltsch.info> <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> <1502410083.17229.18.camel@jeltsch.info> <952A7F11-5505-499D-9B57-8608AAFAADF0@gmail.com> Message-ID: How about this: {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE GADTs #-} import Data.Proxy data IsListType a where IsListType :: IsListType [b] type family Elem a where Elem [a] = a elemType :: forall a b . Elem a ~ b => IsListType a -> Proxy b elemType _ = Proxy :: Proxy (Elem a) On Thu, Aug 10, 2017 at 5:29 PM Alexis King wrote: > > On Aug 10, 2017, at 5:08 PM, Wolfgang Jeltsch > > wrote: > > > > Is there also a solution that does not involve using this > > (unimplemented) feature? > > I get the feeling there is a better way to do this, but I found > something of a hack that I think does what you want. Using > Data.Type.Equality, you can match on Refl to bring the `b` into scope. > > import Data.Type.Equality > > f :: forall a. IsListType a -> () > f IsListType = case Refl of > (Refl :: (a :~: [b])) -> () > > This is sort of silly, though. > > Alexis > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 takenobu.hs at gmail.com Fri Aug 11 08:15:05 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 11 Aug 2017 17:15:05 +0900 Subject: [Haskell-cafe] command-line Haskell with 'ghc -e' Message-ID: Hi cafe, I wrote a simple note: command-line Haskell with 'ghc -e' https://github.com/takenobu-hs/commandline-haskell May Haskell with you :) Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Fri Aug 11 09:02:38 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 11 Aug 2017 11:02:38 +0200 Subject: [Haskell-cafe] command-line Haskell with 'ghc -e' In-Reply-To: References: Message-ID: <20170811090238.o2uqtuzy6uendkhf@x60s.casa> On Fri, Aug 11, 2017 at 05:15:05PM +0900, Takenobu Tani wrote: > Hi cafe, > > I wrote a simple note: > > command-line Haskell with 'ghc -e' > https://github.com/takenobu-hs/commandline-haskell Handy, thanks! From takenobu.hs at gmail.com Fri Aug 11 10:06:00 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 11 Aug 2017 19:06:00 +0900 Subject: [Haskell-cafe] command-line Haskell with 'ghc -e' In-Reply-To: <20170811090238.o2uqtuzy6uendkhf@x60s.casa> References: <20170811090238.o2uqtuzy6uendkhf@x60s.casa> Message-ID: Hi Francesco, Thank you :) Cheers, Takenobu 2017-08-11 18:02 GMT+09:00 Francesco Ariis : > On Fri, Aug 11, 2017 at 05:15:05PM +0900, Takenobu Tani wrote: > > Hi cafe, > > > > I wrote a simple note: > > > > command-line Haskell with 'ghc -e' > > https://github.com/takenobu-hs/commandline-haskell > > Handy, 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 wolfgang-it at jeltsch.info Fri Aug 11 15:23:22 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 11 Aug 2017 18:23:22 +0300 Subject: [Haskell-cafe] How to bring existentially quantified type variables into scope In-Reply-To: References: <1502406964.17229.8.camel@jeltsch.info> <6F7C844C-07EB-4FA0-AA52-ECFC42BF30C8@smart-cactus.org> <1502410083.17229.18.camel@jeltsch.info> <952A7F11-5505-499D-9B57-8608AAFAADF0@gmail.com> Message-ID: <1502465002.17229.49.camel@jeltsch.info> Hi! I think this is too complicated. I am developing a library and this access to existentially quantified type variables is something that cannot be part of the library, but must be done by users using the library. So it should be doable in an easy-to-understand and lightweight way. All the best, Wolfgang Am Freitag, den 11.08.2017, 07:04 +0000 schrieb Kai Zhang: > How about this: > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE ScopedTypeVariables #-} > {-# LANGUAGE GADTs #-} > > import Data.Proxy > > data IsListType a where >     IsListType :: IsListType [b] > > type family Elem a where >     Elem [a] = a > > elemType :: forall a b . Elem a ~ b => IsListType a -> Proxy b > elemType _ = Proxy :: Proxy (Elem a) > > On Thu, Aug 10, 2017 at 5:29 PM Alexis King > wrote: > > > On Aug 10, 2017, at 5:08 PM, Wolfgang Jeltsch > > > wrote: > > > > > > Is there also a solution that does not involve using this > > > (unimplemented) feature? > > > > I get the feeling there is a better way to do this, but I found > > something of a hack that I think does what you want. Using > > Data.Type.Equality, you can match on Refl to bring the `b` into > > scope. > > > >   import Data.Type.Equality > > > >   f :: forall a. IsListType a -> () > >   f IsListType = case Refl of > >     (Refl :: (a :~: [b])) -> () > > > > This is sort of silly, though. > > > > Alexis > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquagnu at gmail.com Fri Aug 11 15:25:11 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 11 Aug 2017 18:25:11 +0300 Subject: [Haskell-cafe] Where is the hole? Message-ID: <20170811182511.4cc1c43b@Pavel> Hello, Dear List! I have code (this is the fragment only): {-# LANGUAGE CPP #-} ... ... let user' = ... ... else defect $ logger # ("authentication failure (user: " ++ user' ++ ")") #: __LINE__ ... ... and I get compilation error: • Found hole: __LINE__ :: Int Or perhaps ‘__LINE__’ is mis-spelled, or not in scope • In the second argument of ‘(#:)’, namely ‘__LINE__’ In the second argument of ‘($)’, namely ‘logger # ("authentication failure (user: " ++ user' ++ ")") #: __LINE__’ In the expression: defect $ logger # ("authentication failure (user: " ++ user' ++ ")") #: __LINE__ • Relevant bindings include... ... etc ... But if I change variable name to `userx` (from user'), all is compiled succesflully, no any holes. Where is the hole? --- Best regards, Paul From mail at joachim-breitner.de Fri Aug 11 15:38:12 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 11 Aug 2017 17:38:12 +0200 Subject: [Haskell-cafe] Where is the hole? In-Reply-To: <20170811182511.4cc1c43b@Pavel> References: <20170811182511.4cc1c43b@Pavel> Message-ID: <1502465892.3284.4.camel@joachim-breitner.de> Hi, cpp easily gets confused by single primes in variables names, which do not exist in C. You can use a better suited cpp implementation, such as http://projects.haskell.org/cpphs/ Greetings, Joachim Am Freitag, den 11.08.2017, 18:25 +0300 schrieb Baa: > Hello, Dear List! > > I have code (this is the fragment only): > >   {-# LANGUAGE CPP                 #-} >   ... >   ... >     let user' = ... >     ... >     else defect $ logger # ("authentication failure (user: " ++ user' > ++ ")") #: __LINE__ >     ... >   ... > > and I get compilation error: > >         • Found hole: __LINE__ :: Int >           Or perhaps ‘__LINE__’ is mis-spelled, or not in scope >         • In the second argument of ‘(#:)’, namely ‘__LINE__’ >           In the second argument of ‘($)’, namely >             ‘logger # ("authentication failure (user: " ++ user' ++ > ")") >              #: __LINE__’ >           In the expression: >             defect >             $ logger # ("authentication failure (user: " ++ user' ++ > ")") >               #: __LINE__ >         • Relevant bindings include... >         ... etc ... > > But if I change variable name to `userx` (from user'), all is > compiled > succesflully, no any holes. Where is the hole? > > --- > Best regards, 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. -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From allbery.b at gmail.com Fri Aug 11 15:39:43 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 11 Aug 2017 11:39:43 -0400 Subject: [Haskell-cafe] Where is the hole? In-Reply-To: <20170811182511.4cc1c43b@Pavel> References: <20170811182511.4cc1c43b@Pavel> Message-ID: On Fri, Aug 11, 2017 at 11:25 AM, Baa wrote: > I have code (this is the fragment only): > > {-# LANGUAGE CPP #-} > ... > ... > let user' = ... > ... > else defect $ logger # ("authentication failure (user: " ++ user' ++ > ")") #: __LINE__ > ... > ... > > and I get compilation error: > > • Found hole: __LINE__ :: Int > Or perhaps ‘__LINE__’ is mis-spelled, or not in scope > You do understand that CPP refers to the C preprocessor, correct? Or perhaps it is C syntax that you are unaware of. Haskell does not get to tell a C preprocessor to follow Haskell rules instead of C rules. In the referenced chunk, there are two things that can cause problems: the single quote, which in the C preprocessor begins a string-like entity (character literal.. for historical reasons, C (char) literals can have multiple characters!), and the # which in mid-line indicates a token pasting operation of some kind. And in this particular case, the #s probably just got eaten, and the ' means the following __LINE__ was in what the C preprocessor thought was a long (char) constant and therefore did not get expanded. Since it has a leading underscore in its name, and is not known to be bound *at the Haskell level*, it is interpreted as a hole. If you are using LANGUAGE CPP, you must avoid Haskell syntax that is not also valid C tokens. This is the downside of using a tool intended for a different language with different syntax rules. -- 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 carette at mcmaster.ca Sat Aug 12 13:57:05 2017 From: carette at mcmaster.ca (Jacques Carette) Date: Sat, 12 Aug 2017 09:57:05 -0400 Subject: [Haskell-cafe] type (++) = (<>) In-Reply-To: References: <201707031729.v63HTHu5001972@coolidge.cs.Dartmouth.EDU> Message-ID: This piece of reasoning, if endorsed by the libraries team, should be recorded somewhere else than just email. Although I am not a fan of language-design-by-history, the chain of events is at least extremely clear and rather defensible. Jacques On 2017-08-08 12:30 PM, Edward Kmett wrote: > There was a great deal of monomorphization that went into the Haskell > 98 standard under the nominal goal of trying to help newcomers to the > language with simpler error messages. For more you can read old > mailing list posts from that timeframe. > > As a technical aside, (<>) is used for Monoid (and soon will upgrade > to Semigroup) not MonadPlus, so the symbols have diverged in > sentiment. Not only that, but (++) and (<>) get mixed in existing > pretty printing code a good deal, and have different fixities, and > must, lest a bunch of code silently change semantics. This was one > reason why (<>) was added (to match existing practice in the pretty > printing libraries) rather than generalizing (++). > > Once we've added (<>), generalizing (++) becomes less urgent and > actually has some cons. Notably, there is a subset of the community > that finds the current form of map and (++) potentially useful for > teaching about lists. If they generalized to become fmap and (<|>) or > (<>) then we create a redundant notation for an existing thing, with > no roadmap for replacing one with the other, and lose the teaching tool. > > As a general guideline, the core libraries committee has been trying > to avoid introducing redundant names that have the exact same type > signature, with possibly different fixity, but where one is exported > from the class and the other isn't, because it makes it yet another > detail you have to memorize to know which one is the one in the class > and can be refined: the types simply don't tell you. > > Having one version that is strictly more general enables one subset of > the community to simply forget about the other one and move on, and > another subset that aren't fans of rampant abstraction to use the one > with more specific type when they want to clearly signal intent. > > I'd be slightly more open to discussions about eventual removal or > exile of the redundant members to an appropriate module than > generalization under that guideline, but that isn't a hill I'd want to > die on. (++) is pretty well embedded in Haskell's DNA. > > *tl;dr* It happened at first because of a great wave of > monomorphization, and there is at least a defensible reason why it > hasn't generalized back in the presence of other changes that have > happened in the meantime. > > -Edward > > On Mon, Jul 3, 2017 at 1:29 PM, Doug McIlroy > wrote: > > > What do you think of making (++) the same as (<>) > > This seems to be a call for returning to the old situation in > which (++) was an operator of class MonadPlus. Why was that > abolished in Haskell 98? > > Doug > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lucas.dicioccio at gmail.com Sun Aug 13 16:09:57 2017 From: lucas.dicioccio at gmail.com (lucas di cioccio) Date: Sun, 13 Aug 2017 18:09:57 +0200 Subject: [Haskell-cafe] [ANN] first release of http2-client Message-ID: Hello, I'm pleased to announce the first release of the http2-client [0] library on Hackage. This version is fresh and has limitations (see README.md) but I can successfully query pages with simple queries on a number of popular websites. I could validate server pushes against GoLang's HTTP2 server demo. I could also hammer Warp with dozens of concurrent requests just fine. I would not recommend using the package for more than evaluation at this point. If you are eyeing towards having a solid HTTP2 client soon, please consider trying http2-client and reporting bugs on the GitHub page [1]. I'm welcoming contribution to the code but I'm also looking forward to build some automation to validate against implementations found "in the wild". Starting this work also allowed me to report/fix a few bugs on Warp's HTTP2 implementation. Hence, even if you are not looking forward to be a http2-client user you may find interest in such work as we all benefit from this. [0] http://hackage.haskell.org/package/http2-client [1] https://github.com/lucasdicioccio/http2-client Best, -- Lucas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudy at matela.com.br Mon Aug 14 09:59:32 2017 From: rudy at matela.com.br (Rudy Matela) Date: Mon, 14 Aug 2017 10:59:32 +0100 Subject: [Haskell-cafe] [ANN] LeanCheck & Extrapolate: enumerative property-based testing & generalization of counter-examples Message-ID: <20170814095809.GA22373@zero.localdomain> Hello Haskell-café, I am happy to announce LeanCheck and Extrapolate, two enumerative property-based testing libraries (a.k.a. QuickCheck-style testing). https://hackage.haskell.org/package/leancheck https://hackage.haskell.org/package/extrapolate LeanCheck is a list-based enumerative property-based testing library with a very small core of only 180 lines of code. LeanCheck is somewhat stable and has actually been around for a while, but this is its first announcement on haskell-café. It works like so: $ ghci > import Test.LeanCheck > check $ \x y -> x + y == y + (x :: Int) +++ OK, passed 200 tests. Extrapolate works on top of LeanCheck, and its able to produce generalized counter-examples in addition to fully defined ones. Like so: $ ghci > import Test.Extrapolate > import Data.List (nub) > check $ \xs -> nub xs == (xs :: [Int]) *** Failed! Falsifiable (after 3 tests): [0,0] Generalization: x:x:_ Conditional Generalization: x:xs when elem x xs Extrapolate is under active development at the moment. To install both libraries, just: $ cabal update $ cabal install leancheck $ cabal install extrapolate They are also available on Stackage, installable via 'stack install': https://www.stackage.org/package/leancheck (lts-9 and nightly) https://www.stackage.org/package/extrapolate (just nightly) -- Rudy From wolfgang-it at jeltsch.info Mon Aug 14 22:05:54 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Tue, 15 Aug 2017 01:05:54 +0300 Subject: [Haskell-cafe] Haskell in Leipzig 2017: last call for papers Message-ID: <1502748354.14159.30.camel@jeltsch.info> Hi! I want to kindly remind you that the submission deadline of Haskell in Leipzig 2017 is on Friday this week. Looking forward to your contributions. ☺ Event:    Haskell in Leipzig 2017 Time:     October 26–28, 2017 Place:    HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions ============= Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of   * talks (about 30 minutes),   * tutorials (about 90 minutes),   * demonstrations, artistic performances, or other extraordinary     things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at     https://easychair.org/conferences/?conf=hal2017 until Friday, August 18, 2017. You will be notified by Friday, September 8, 2017. Hacking Projects ================ Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Invited Speaker ===============   * Ivan Perez, University of Nottingham, UK Invited Performer =================   * Lennart Melzer, Robert-Schumann-Hochschule Düsseldorf, Germany Program Committee =================   * Edward Amsden, Plow Technologies, USA   * Heinrich Apfelmus, Germany   * Jurriaan Hage, Utrecht University, The Netherlands   * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany   * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair)   * Andres Löh, Well-Typed LLP, Germany   * Keiko Nakata, SAP SE, Germany   * Henrik Nilsson, University of Nottingham, UK   * Ertuğrul Söylemez, Intelego GmbH, Germany   * Henning Thielemann, Germany   * Niki Vazou, University of Maryland, USA   * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it at jeltsch.info. From sumitraja at gmail.com Tue Aug 15 02:25:24 2017 From: sumitraja at gmail.com (Sumit Raja) Date: Tue, 15 Aug 2017 12:25:24 +1000 Subject: [Haskell-cafe] GHC 8.2.1 + lld on FreeBSD Message-ID: Hi, I've been playing with ghc 8.2.1 and clang + lld on FreeBSD 11. I wasn't able to get the installation as per release notes to select lld instead of gold (will spend more time exploring why when I get a chance) so I modified the settings file after install. I have builds running okay but I keep seeing the following: [1 of 1] Compiling Main ( hs.hs, hs.o ) Linking hs ... : error: Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. I've set up ld.lld39 as the shipped lld is 4.0. Although not affecting the actual build ("Hello World") but was interested to know why this was happening. Settings file is below: [("GCC extra via C opts", " -fwrapv -fno-builtin"), ("C compiler command", "clang"), ("C compiler flags", " -fno-stack-protector"), ("C compiler link flags", "-L/usr/local/lib -fuse-ld=lld39"), ("C compiler supports -no-pie", "NO"), ("Haskell CPP command","clang"), ("Haskell CPP flags","-E -undef -traditional"), ("ld command", "ld.lld"), ("ld flags", "-L/usr/local/lib"), ("ld supports compact unwind", "YES"), ("ld supports build-id", "YES"), ("ld supports filelist", "NO"), ("ld is GNU ld", "YES"), ("ar command", "/usr/bin/ar"), ("ar flags", "clqs"), ("ar supports at file", "NO"), ("touch command", "touch"), ("dllwrap command", "/bin/false"), ("windres command", "/bin/false"), ("libtool command", "libtool"), ("perl command", "/usr/local/bin/perl"), ("cross compiling", "NO"), ("target os", "OSFreeBSD"), ("target arch", "ArchX86_64"), ("target word size", "8"), ("target has GNU nonexec stack", "True"), ("target has .ident directive", "True"), ("target has subsections via symbols", "False"), ("target has RTS linker", "@HaskellHaveRTSLinker@"), ("Unregisterised", "NO"), ("LLVM llc command", "llc39"), ("LLVM opt command", "opt39") ] Thanks Sumit From 6yearold at gmail.com Tue Aug 15 08:29:48 2017 From: 6yearold at gmail.com (Gleb Popov) Date: Tue, 15 Aug 2017 11:29:48 +0300 Subject: [Haskell-cafe] GHC 8.2.1 + lld on FreeBSD In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 5:25 AM, Sumit Raja wrote: > Hi, > > I've been playing with ghc 8.2.1 and clang + lld on FreeBSD 11. I > wasn't able to get the installation as per release notes to select lld > instead of gold (will spend more time exploring why when I get a > chance) so I modified the settings file after install. I have builds > running okay but I keep seeing the following: > > [1 of 1] Compiling Main ( hs.hs, hs.o ) > Linking hs ... > > : error: > Warning: Couldn't figure out linker information! > Make sure you're using GNU ld, GNU gold or the built in > OS X linker, etc. > > I've set up ld.lld39 as the shipped lld is 4.0. Although not > affecting the actual build ("Hello World") but was interested to know > why this was happening. Settings file is below: > > [("GCC extra via C opts", " -fwrapv -fno-builtin"), > ("C compiler command", "clang"), > ("C compiler flags", " -fno-stack-protector"), > ("C compiler link flags", "-L/usr/local/lib -fuse-ld=lld39"), > ("C compiler supports -no-pie", "NO"), > ("Haskell CPP command","clang"), > ("Haskell CPP flags","-E -undef -traditional"), > ("ld command", "ld.lld"), > ("ld flags", "-L/usr/local/lib"), > ("ld supports compact unwind", "YES"), > ("ld supports build-id", "YES"), > ("ld supports filelist", "NO"), > ("ld is GNU ld", "YES"), > ("ar command", "/usr/bin/ar"), > ("ar flags", "clqs"), > ("ar supports at file", "NO"), > ("touch command", "touch"), > ("dllwrap command", "/bin/false"), > ("windres command", "/bin/false"), > ("libtool command", "libtool"), > ("perl command", "/usr/local/bin/perl"), > ("cross compiling", "NO"), > ("target os", "OSFreeBSD"), > ("target arch", "ArchX86_64"), > ("target word size", "8"), > ("target has GNU nonexec stack", "True"), > ("target has .ident directive", "True"), > ("target has subsections via symbols", "False"), > ("target has RTS linker", "@HaskellHaveRTSLinker@"), > ("Unregisterised", "NO"), > ("LLVM llc command", "llc39"), > ("LLVM opt command", "opt39") > ] > > > Thanks > > Sumit > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. On a quest for building GHC with clang, I've fixed almost identical warning, see https://phabricator.haskell.org/D3840 There should be a similar case expression for a linker tool too, I presume. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkokl at gmail.com Wed Aug 16 00:07:44 2017 From: erkokl at gmail.com (Levent Erkok) Date: Tue, 15 Aug 2017 17:07:44 -0700 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and Message-ID: I was surprised today to find that C and Haskell differ on the precedence of addition and bit-wise and. In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way around. While I like Haskell's precedence better, this was a gotcha; and I wondered if this behavior is documented somewhere. I looked through the Haskell wiki, but couldn't find anything pertinent. Discrepancies are always problematic. Without bike-shedding a lot, does anyone know if this was a conscious decision or merely a more natural one to take? Cheers, -Levent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 16 02:03:57 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 15 Aug 2017 22:03:57 -0400 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 8:07 PM, Levent Erkok wrote: > While I like Haskell's precedence better, this was a gotcha; and I > wondered if this behavior is documented somewhere. I looked through the > Haskell wiki, but couldn't find anything pertinent. > Documented in the Language Report, just as C's precedence is documented in the ANSI C standard (and, before that, the Language Report in the back of K&R). https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-820061 -- 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 clintonmead at gmail.com Wed Aug 16 02:06:32 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Wed, 16 Aug 2017 02:06:32 +0000 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and In-Reply-To: References: Message-ID: I wasn't involve in the decision but personally I would expect "&" (and) to have precedence like "*" and "|" (or) to have precedence like "+", whether bitwise or logical. It seems from what you're saying that's how Haskell works. Flipping it would be more of a gotcha to me. On Wed, 16 Aug 2017 at 10:08 am, Levent Erkok wrote: > I was surprised today to find that C and Haskell differ on the precedence > of addition and bit-wise and. > > In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way > around. > > While I like Haskell's precedence better, this was a gotcha; and I > wondered if this behavior is documented somewhere. I looked through the > Haskell wiki, but couldn't find anything pertinent. > > Discrepancies are always problematic. Without bike-shedding a lot, does > anyone know if this was a conscious decision or merely a more natural one > to take? > > Cheers, > > -Levent. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 16 02:11:49 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 15 Aug 2017 22:11:49 -0400 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and In-Reply-To: References: Message-ID: On Tue, Aug 15, 2017 at 10:06 PM, Clinton Mead wrote: > I wasn't involve in the decision but personally I would expect "&" (and) > to have precedence like "*" and "|" (or) to have precedence like "+", > whether bitwise or logical. > > It seems from what you're saying that's how Haskell works. Flipping it > would be more of a gotcha to me. > C's precedence for bitwise ops is an infamous gotcha. -- 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 Wed Aug 16 05:54:47 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 16 Aug 2017 17:54:47 +1200 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and In-Reply-To: References: Message-ID: On 16/08/17 12:07 PM, Levent Erkok wrote: > I was surprised today to find that C and Haskell differ on the > precedence of addition and bit-wise and. > > In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way > around. It is worth noting that Haskell uses a different symbol (.&.) than C (&), so it's not altogether surprising. There is no generally accepted convention. In Erlang, bitwise and has the same precedence as * and bitwise or has the same precedence as + . In Standard ML, andb and orb are not operators at all. In Fortran, iand and ior are not operators at all. The & and | operators in PL/I are wider scope than the arithmetic and comparison operators, but they do double duty for bitwise operations and conditional operations, just as BCPL did. In Prolog, bitwise and and or have the same precedence as as + and thus as each other. In Ada, 'and' and 'or' have the same precedence as each other, wider scope than comparisons, and the language does not allow you to mix 'and' and 'or' without parentheses. In Pascal, the bitwise operators are actually called * and +. In Smalltalk, "bitAnd:" and "bitOr:" have the same precedence as each other, wider scope than "+" and "*" (which have the same precedence as all binary selectors). Not that Smalltalk technically _has_ operator precedence... SETL2 doesn't appear to have bitwise operations at all. I could go on, but I think I've made the point that expecting everything to be just like C is rather risky. For that matter, common advice for C programmers is "never mix arithmetic and bitwise operators without parentheses". > > While I like Haskell's precedence better, this was a gotcha; and I > wondered if this behavior is documented somewhere. I looked through the > Haskell wiki, but couldn't find anything pertinent. > > Discrepancies are always problematic. The only language in which you will not find discrepancies with C is C itself, and I'm afraid you will find (semantic) discrepancies there. If I went around complaining that C doesn't look enough like APL, what good would that do me? From zocca.marco at gmail.com Wed Aug 16 11:37:53 2017 From: zocca.marco at gmail.com (Marco Zocca) Date: Wed, 16 Aug 2017 13:37:53 +0200 Subject: [Haskell-cafe] DataHaskell impromptu workshop at ICFP'17 ? Message-ID: Dear all, among those that will attend the last three days of ICFP (i.e. the Haskell symposium and CUFP), are there people who would be interested in meeting to discuss possible future directions for the DataHaskell project? Looking forward to your feedback; Best, Marco From doug at cs.dartmouth.edu Wed Aug 16 12:51:49 2017 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Wed, 16 Aug 2017 08:51:49 -0400 Subject: [Haskell-cafe] Precedence of plus and bit-wise-and Message-ID: <201708161251.v7GCpn1U027706@coolidge.cs.Dartmouth.EDU> The reason for the low precedence of & and | in PL/I and C is that those were used as Boolean operators in conditions. For example lessequal(a,b) { return(a Sorry for hitting return prematurely. The final sentence below tells the tale. The reason for the low precedence of & and | in PL/I and C is that those were used as Boolean operators in conditions. For example lessequal(a,b) { return(a Hi. Is there a way to avoid `UndecidableInstances` in following code: data A f = A {_a1 :: f String} instance Show (f String) => Show (A f) where it does not compile with 1.hs:4:10: error: • The constraint ‘Show (f String)’ is no smaller than the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Show (A f)’ Though, initially, this was {-# LANGUAGE RankNTypes #-} data A f = A {_a1 :: f String} instance forall f a. Show (f a) => Show (A f) where which also does not compile with 1.hs:5:10: error: • Variable ‘a’ occurs more often in the constraint ‘Show (f a)’ than in the instance head (Use UndecidableInstances to permit this) • In the instance declaration for ‘Show (A f)’ The error is different and i don't sure, that this two cases are related. I want these instances to make a type with many records parametrized by `Alternative` type, e.g. data Volume t = Volume { _volName :: t Name , _volSize :: t Size , _volPath :: t Path , _pool :: t Pool } When i try to make instances, which require `*` type, i will end with above cases. -- Dmitriy From jhenahan at me.com Wed Aug 16 18:01:50 2017 From: jhenahan at me.com (Jack Henahan) Date: Wed, 16 Aug 2017 14:01:50 -0400 Subject: [Haskell-cafe] 123 In-Reply-To: References: Message-ID: Some mostly unrelated thoughts: An instance head has the form `T a_1 ... a_n`, and the constraint can only apply to the `a_i`s. Consider the Show instance for pairs. instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) The constraints only act on the parameters of the type. It looks like you're taking the constraint to mean "whenever I have a Showable `f String`, this is how to define a Show instance", but a constraint actually means "use this rule to make a Show instance for any `A f`, and it is an error if a Show instance for `f String` is not in scope". In the second error, you are making the strong claim that your Show instance for `A f` holds for any `f` and `a`. Even if you could trick the compiler into allowing that, I don't think it would actually express the constraint that you want it to. Is there something a Show instance gets you that a pretty-print function wouldn't? Dmitriy Matrosov writes: > Hi. > > Is there a way to avoid `UndecidableInstances` in following code: > > data A f = A {_a1 :: f String} > > instance Show (f String) => Show (A f) where > > it does not compile with > > 1.hs:4:10: error: > • The constraint ‘Show (f String)’ > is no smaller than the instance head > (Use UndecidableInstances to permit this) > • In the instance declaration for ‘Show (A f)’ > > Though, initially, this was > > {-# LANGUAGE RankNTypes #-} > > data A f = A {_a1 :: f String} > > instance forall f a. Show (f a) => Show (A f) where > > which also does not compile with > > 1.hs:5:10: error: > • Variable ‘a’ occurs more often > in the constraint ‘Show (f a)’ than in the instance head > (Use UndecidableInstances to permit this) > • In the instance declaration for ‘Show (A f)’ > > The error is different and i don't sure, that this two cases are related. > > I want these instances to make a type with many records parametrized by > `Alternative` type, e.g. > > data Volume t = Volume > { _volName :: t Name > , _volSize :: t Size > , _volPath :: t Path > , _pool :: t Pool > } > > When i try to make instances, which require `*` type, i will end with > above cases. -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From isaace71295 at gmail.com Wed Aug 16 20:53:19 2017 From: isaace71295 at gmail.com (Isaac Elliott) Date: Wed, 16 Aug 2017 20:53:19 +0000 Subject: [Haskell-cafe] 123 In-Reply-To: References: Message-ID: Hey Dmitry, The 'Show1' class accomplishes this for types :: * -> *. https://hackage.haskell.org/package/transformers-0.5.1.0/docs/Data-Functor-Classes.html Then you can write: instance Show1 f => Volume f where... On Thu, 17 Aug. 2017, 4:02 am Jack Henahan, wrote: > > Some mostly unrelated thoughts: > > An instance head has the form `T a_1 ... a_n`, and the constraint can only > apply to the `a_i`s. Consider the Show instance for > pairs. > > instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) > > The constraints only act on the parameters of the type. > > It looks like you're taking the constraint to mean "whenever I have a > Showable > `f String`, this is how to define a Show instance", but a constraint > actually means "use this rule to make a Show instance for any `A f`, and > it is an error if a Show instance for `f String` is not in scope". > > In the second error, you are making the strong claim that your Show > instance for `A f` holds for any `f` and `a`. Even if you could trick > the compiler into allowing that, I don't think it would actually express > the constraint that you want it to. > > Is there something a Show instance gets you that a pretty-print function > wouldn't? > > Dmitriy Matrosov writes: > > > Hi. > > > > Is there a way to avoid `UndecidableInstances` in following code: > > > > data A f = A {_a1 :: f String} > > > > instance Show (f String) => Show (A f) where > > > > it does not compile with > > > > 1.hs:4:10: error: > > • The constraint ‘Show (f String)’ > > is no smaller than the instance head > > (Use UndecidableInstances to permit this) > > • In the instance declaration for ‘Show (A f)’ > > > > Though, initially, this was > > > > {-# LANGUAGE RankNTypes #-} > > > > data A f = A {_a1 :: f String} > > > > instance forall f a. Show (f a) => Show (A f) where > > > > which also does not compile with > > > > 1.hs:5:10: error: > > • Variable ‘a’ occurs more often > > in the constraint ‘Show (f a)’ than in the instance head > > (Use UndecidableInstances to permit this) > > • In the instance declaration for ‘Show (A f)’ > > > > The error is different and i don't sure, that this two cases are related. > > > > I want these instances to make a type with many records parametrized by > > `Alternative` type, e.g. > > > > data Volume t = Volume > > { _volName :: t Name > > , _volSize :: t Size > > , _volPath :: t Path > > , _pool :: t Pool > > } > > > > When i try to make instances, which require `*` type, i will end with > > above cases. > > > -- > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgf.dma at gmail.com Wed Aug 16 20:54:29 2017 From: sgf.dma at gmail.com (Dmitriy Matrosov) Date: Wed, 16 Aug 2017 23:54:29 +0300 Subject: [Haskell-cafe] Fwd: Re: 123 In-Reply-To: <6afdb5a6-ff30-f84c-24a1-8a85c50e395d@gmail.com> References: <6afdb5a6-ff30-f84c-24a1-8a85c50e395d@gmail.com> Message-ID: <46f6ccda-653f-47d5-9854-4e3d7f951edd@gmail.com> And even sent the answer not to the list.. Huh. -------- Forwarded Message -------- Oops, i forgot to change the subject. Sorry! On 08/16/2017 09:01 PM, Jack Henahan wrote: > > Some mostly unrelated thoughts: > > An instance head has the form `T a_1 ... a_n`, and the constraint can only > apply to the `a_i`s. Consider the Show instance for > pairs. > > instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) > > The constraints only act on the parameters of the type. > > It looks like you're taking the constraint to mean "whenever I have a Showable > `f String`, this is how to define a Show instance", but a constraint > actually means "use this rule to make a Show instance for any `A f`, and > it is an error if a Show instance for `f String` is not in scope". > > In the second error, you are making the strong claim that your Show > instance for `A f` holds for any `f` and `a`. Even if you could trick > the compiler into allowing that, I don't think it would actually express > the constraint that you want it to. > > Is there something a Show instance gets you that a pretty-print function wouldn't? Well, the `Show` was just an example. And examples with `A` was just a simplified versions, but perhaps oversimplified and hiding original intention. > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE StandaloneDeriving #-} > > import Control.Applicative > import Data.Monoid > import Data.Typeable I want to have a type with many records: > data Volume t = Volume > { _volName :: t String > , _volSize :: t Int > } > > showVolume :: (Show (t String), Show (t Int)) => Volume t -> String > showVolume x = "Volume " ++ show (_volName x) ++ ", " ++ show (_volSize x) with instances parametrized by some other type. E.g. i want to define a `Monoid` based on that other type properties: > instance Alternative t => Monoid (Volume t) where > mempty = Volume {_volName = empty, _volSize = empty} > x `mappend` y = Volume > { _volName = _volName x <|> _volName y > , _volSize = _volSize x <|> _volSize y > } and i may use this like > v1 :: Alternative t => Volume t > v1 = Volume {_volName = pure "vol1", _volSize = empty} > v2 :: Alternative t => Volume t > v2 = Volume {_volName = pure "vol2", _volSize = pure 200} *Main> showVolume (v1 <> v2 :: Volume Maybe) "Volume Just \"vol1\", Just 200" *Main> showVolume (v1 <> v2 :: Volume []) "Volume [\"vol1\",\"vol2\"], [200]" But then i want to define a GADT, which has different behaviors depending on argument type. So different records, depending on their type, will behave differently. > data Config a where > Empty :: Config a > Name :: Last String -> Config String > Size :: Num a => Sum a -> Config a > deriving instance Show a => Show (Config a) > instance Monoid (Config a) where > mempty = Empty > (Name x) `mappend` (Name y) = Name (x `mappend` y) > (Size x) `mappend` (Size y) = Size (x `mappend` y) > x `mappend` Empty = x > Empty `mappend` y = y but i can't even define a `Functor` instance for this type, because `case` branches have different type and `Functor` laws won't hold.. Hm.. instance Functor Config where fmap f Empty = Empty --fmap f (Name s) = case cast f of -- Just g -> case (g s) of -- Just s' -> Name s' -- _ -> Empty -- Nothing -> Empty The other problem is with instances for classes requiring type of kind `*`. I'll end up with what i've asked before: instance (Show a, Show (t a)) => Show (Volume t) where Well, i didn't write that before asking, so i realize all these problems only now (i even forgot to change the subject, what else to say?). And now i don't even sure what the proper subject should be. So thanks and never mind, i need to try more to figure out what to ask. > > Dmitriy Matrosov writes: > >> Hi. >> >> Is there a way to avoid `UndecidableInstances` in following code: >> >> data A f = A {_a1 :: f String} >> >> instance Show (f String) => Show (A f) where >> >> it does not compile with >> >> 1.hs:4:10: error: >> • The constraint ‘Show (f String)’ >> is no smaller than the instance head >> (Use UndecidableInstances to permit this) >> • In the instance declaration for ‘Show (A f)’ >> >> Though, initially, this was >> >> {-# LANGUAGE RankNTypes #-} >> >> data A f = A {_a1 :: f String} >> >> instance forall f a. Show (f a) => Show (A f) where >> >> which also does not compile with >> >> 1.hs:5:10: error: >> • Variable ‘a’ occurs more often >> in the constraint ‘Show (f a)’ than in the instance head >> (Use UndecidableInstances to permit this) >> • In the instance declaration for ‘Show (A f)’ >> >> The error is different and i don't sure, that this two cases are related. >> >> I want these instances to make a type with many records parametrized by >> `Alternative` type, e.g. >> >> data Volume t = Volume >> { _volName :: t Name >> , _volSize :: t Size >> , _volPath :: t Path >> , _pool :: t Pool >> } >> >> When i try to make instances, which require `*` type, i will end with >> above cases. > > > -- > Jack > From olshanskydr at gmail.com Wed Aug 16 21:07:49 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Thu, 17 Aug 2017 00:07:49 +0300 Subject: [Haskell-cafe] 123 In-Reply-To: References: Message-ID: It seems that another option could be: instance Foldable f => Show (A f) where ... 2017-08-16 23:53 GMT+03:00 Isaac Elliott : > Hey Dmitry, > > The 'Show1' class accomplishes this for types :: * -> *. > > https://hackage.haskell.org/package/transformers-0.5.1.0/ > docs/Data-Functor-Classes.html > > Then you can write: instance Show1 f => Volume f where... > > On Thu, 17 Aug. 2017, 4:02 am Jack Henahan, wrote: > >> >> Some mostly unrelated thoughts: >> >> An instance head has the form `T a_1 ... a_n`, and the constraint can only >> apply to the `a_i`s. Consider the Show instance for >> pairs. >> >> instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) >> >> The constraints only act on the parameters of the type. >> >> It looks like you're taking the constraint to mean "whenever I have a >> Showable >> `f String`, this is how to define a Show instance", but a constraint >> actually means "use this rule to make a Show instance for any `A f`, and >> it is an error if a Show instance for `f String` is not in scope". >> >> In the second error, you are making the strong claim that your Show >> instance for `A f` holds for any `f` and `a`. Even if you could trick >> the compiler into allowing that, I don't think it would actually express >> the constraint that you want it to. >> >> Is there something a Show instance gets you that a pretty-print function >> wouldn't? >> >> Dmitriy Matrosov writes: >> >> > Hi. >> > >> > Is there a way to avoid `UndecidableInstances` in following code: >> > >> > data A f = A {_a1 :: f String} >> > >> > instance Show (f String) => Show (A f) where >> > >> > it does not compile with >> > >> > 1.hs:4:10: error: >> > • The constraint ‘Show (f String)’ >> > is no smaller than the instance head >> > (Use UndecidableInstances to permit this) >> > • In the instance declaration for ‘Show (A f)’ >> > >> > Though, initially, this was >> > >> > {-# LANGUAGE RankNTypes #-} >> > >> > data A f = A {_a1 :: f String} >> > >> > instance forall f a. Show (f a) => Show (A f) where >> > >> > which also does not compile with >> > >> > 1.hs:5:10: error: >> > • Variable ‘a’ occurs more often >> > in the constraint ‘Show (f a)’ than in the instance head >> > (Use UndecidableInstances to permit this) >> > • In the instance declaration for ‘Show (A f)’ >> > >> > The error is different and i don't sure, that this two cases are >> related. >> > >> > I want these instances to make a type with many records parametrized by >> > `Alternative` type, e.g. >> > >> > data Volume t = Volume >> > { _volName :: t Name >> > , _volSize :: t Size >> > , _volPath :: t Path >> > , _pool :: t Pool >> > } >> > >> > When i try to make instances, which require `*` type, i will end with >> > above cases. >> >> >> -- >> 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. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olshanskydr at gmail.com Wed Aug 16 21:18:51 2017 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Thu, 17 Aug 2017 00:18:51 +0300 Subject: [Haskell-cafe] 123 In-Reply-To: References: Message-ID: Sorry, I meant instance (Functor f, Foldable f) => Show (A f) where ... 2017-08-17 0:07 GMT+03:00 Dmitry Olshansky : > It seems that another option could be: > > instance Foldable f => Show (A f) where > ... > > > > > > 2017-08-16 23:53 GMT+03:00 Isaac Elliott : > >> Hey Dmitry, >> >> The 'Show1' class accomplishes this for types :: * -> *. >> >> https://hackage.haskell.org/package/transformers-0.5.1.0/doc >> s/Data-Functor-Classes.html >> >> Then you can write: instance Show1 f => Volume f where... >> >> On Thu, 17 Aug. 2017, 4:02 am Jack Henahan, wrote: >> >>> >>> Some mostly unrelated thoughts: >>> >>> An instance head has the form `T a_1 ... a_n`, and the constraint can >>> only >>> apply to the `a_i`s. Consider the Show instance for >>> pairs. >>> >>> instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) >>> >>> The constraints only act on the parameters of the type. >>> >>> It looks like you're taking the constraint to mean "whenever I have a >>> Showable >>> `f String`, this is how to define a Show instance", but a constraint >>> actually means "use this rule to make a Show instance for any `A f`, and >>> it is an error if a Show instance for `f String` is not in scope". >>> >>> In the second error, you are making the strong claim that your Show >>> instance for `A f` holds for any `f` and `a`. Even if you could trick >>> the compiler into allowing that, I don't think it would actually express >>> the constraint that you want it to. >>> >>> Is there something a Show instance gets you that a pretty-print function >>> wouldn't? >>> >>> Dmitriy Matrosov writes: >>> >>> > Hi. >>> > >>> > Is there a way to avoid `UndecidableInstances` in following code: >>> > >>> > data A f = A {_a1 :: f String} >>> > >>> > instance Show (f String) => Show (A f) where >>> > >>> > it does not compile with >>> > >>> > 1.hs:4:10: error: >>> > • The constraint ‘Show (f String)’ >>> > is no smaller than the instance head >>> > (Use UndecidableInstances to permit this) >>> > • In the instance declaration for ‘Show (A f)’ >>> > >>> > Though, initially, this was >>> > >>> > {-# LANGUAGE RankNTypes #-} >>> > >>> > data A f = A {_a1 :: f String} >>> > >>> > instance forall f a. Show (f a) => Show (A f) where >>> > >>> > which also does not compile with >>> > >>> > 1.hs:5:10: error: >>> > • Variable ‘a’ occurs more often >>> > in the constraint ‘Show (f a)’ than in the instance head >>> > (Use UndecidableInstances to permit this) >>> > • In the instance declaration for ‘Show (A f)’ >>> > >>> > The error is different and i don't sure, that this two cases are >>> related. >>> > >>> > I want these instances to make a type with many records parametrized by >>> > `Alternative` type, e.g. >>> > >>> > data Volume t = Volume >>> > { _volName :: t Name >>> > , _volSize :: t Size >>> > , _volPath :: t Path >>> > , _pool :: t Pool >>> > } >>> > >>> > When i try to make instances, which require `*` type, i will end with >>> > above cases. >>> >>> >>> -- >>> 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. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 zhiwudazhanjiangshi at gmail.com Wed Aug 16 22:01:48 2017 From: zhiwudazhanjiangshi at gmail.com (yi lu) Date: Thu, 17 Aug 2017 06:01:48 +0800 Subject: [Haskell-cafe] cabal update problem? Message-ID: Hi all, I find cabal 2.0.0.0 brings new change both in downloading package list and the hackage mirror. 1) 00-index.tar.gz has be replaced by 01-index.tar.gz 2) If timestamp.json exists and it is new enough, 01-index.tar.gz won't download, even though I don't have the latest copy of 01-index.tar.gz. So my questions are 1) What else has been changed to hackage.haskell.org mirror? I found four more files: mirrors.json root.json snapshot.json timestamp.json 2) Is it a feature or a bug? Yours, Yi -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddhanathan+eml at gmail.com Wed Aug 16 22:20:03 2017 From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam) Date: Wed, 16 Aug 2017 18:20:03 -0400 Subject: [Haskell-cafe] DataHaskell impromptu workshop at ICFP'17 ? In-Reply-To: References: Message-ID: I would be interested. Best, Sid On Wed, Aug 16, 2017 at 7:37 AM, Marco Zocca wrote: > Dear all, > > among those that will attend the last three days of ICFP (i.e. the > Haskell symposium and CUFP), are there people who would be interested > in meeting to discuss possible future directions for the DataHaskell > project? > > Looking forward to your feedback; > > Best, > Marco > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 voldermort at hotmail.com Thu Aug 17 07:35:40 2017 From: voldermort at hotmail.com (Jonathon Delgado) Date: Thu, 17 Aug 2017 07:35:40 +0000 Subject: [Haskell-cafe] cabal update problem? Message-ID: 01-index.tar.gz is also 4 times the size of 00-index.tar.gz From michael at snoyman.com Thu Aug 17 09:01:33 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 17 Aug 2017 12:01:33 +0300 Subject: [Haskell-cafe] cabal update problem? In-Reply-To: References: Message-ID: This is the expected new behavior in cabal 2.0, due to usage of Hackage Security. The new tarball is much larger since it keeps all revisions of a cabal file from all time (though I'm honestly surprised to hear it's 4 times the size). The additional files have to do with new features in Hackage Security, like mirroring and incremental updates. On Thu, Aug 17, 2017 at 10:35 AM, Jonathon Delgado wrote: > 01-index.tar.gz is also 4 times the size of 00-index.tar.gz > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 voldermort at hotmail.com Thu Aug 17 10:02:12 2017 From: voldermort at hotmail.com (Jonathon Delgado) Date: Thu, 17 Aug 2017 10:02:12 +0000 Subject: [Haskell-cafe] cabal update problem? In-Reply-To: References: , Message-ID: >From ~15Mb to ~60Mb. The old format also has multiple revisions, it seems to be just the package.jsons (with their uncompressible hashes) that's bloating it. From: Michael Snoyman Sent: 17 August 2017 09:01 To: Jonathon Delgado Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] cabal update problem?   This is the expected new behavior in cabal 2.0, due to usage of Hackage Security. The new tarball is much larger since it keeps all revisions of a cabal file from all time (though I'm honestly surprised to hear it's 4 times the size). The additional files have to do with new features in Hackage Security, like mirroring and incremental updates. From rudy at matela.com.br Thu Aug 17 12:35:46 2017 From: rudy at matela.com.br (Rudy Matela) Date: Thu, 17 Aug 2017 13:35:46 +0100 Subject: [Haskell-cafe] [ANN] Speculate: automatically discover properties about Haskell functions generalization of counter-examples Message-ID: <20170817123546.GA6200@zero.localdomain> Hello, I am happy to announce Speculate. A library to automatically discover properties about Haskell functions. https://hackage.haskell.org/package/speculate Quick example -- discovering properties about addition and multiplication: $ cabal update $ cabal install speculate $ ghci > import Test.Speculate > speculate args{constants = [constant "+" (+), constant "*" (*)]} _ :: Integer (+) :: Integer -> Integer -> Integer (*) :: Integer -> Integer -> Integer x + y == y + x x * y == y * x (x + y) + z == x + (y + z) (x * y) * z == x * (y * z) (x + x) * y == x * (y + y) x <= x * x Speculate is similar to QuickSpec, but uses a different algorithm to produce inequalities and coditional equations -- see README for details. Speculate is available on both Stackage (nightly) and Hackage. -- Rudy From matthewtpickering at gmail.com Fri Aug 18 09:37:06 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 18 Aug 2017 11:37:06 +0200 Subject: [Haskell-cafe] haskell-src-exts 8.2 compatible release Message-ID: Hi all, I realise that people will be starting to use haskell-src-exts libaries with the new GHC 8.2 release. However, I do not have time in the foreseeable future (~ 1-2 months) to be able to implement the necessary parts to support the new language features. The way to make an 8.2 compatible release happen sooner is to send me some patches! There are some pull requests which I would like to merge but require minor changes or rebasing and also a few language features which need implementing. https://github.com/haskell-suite/haskell-src-exts/milestones/1.18 None of them look very difficult to implement unlike other language changes in past releases. I started to work on what was necessary a few months ago but didn't make a large amount of progress. https://github.com/haskell-suite/haskell-src-exts/tree/ghc-8.2 Anyone's help contributing to this important but menial library would be greatly appreciated. Thanks, Matt From sh.najd at gmail.com Fri Aug 18 13:27:36 2017 From: sh.najd at gmail.com (Shayan Najd) Date: Fri, 18 Aug 2017 15:27:36 +0200 Subject: [Haskell-cafe] haskell-src-exts 8.2 compatible release In-Reply-To: References: Message-ID: Just a quick note that we are *slowly* approaching the point that we can merge HSE's annotated AST with the new growable[1] AST[2] in GHC. One major change would be requiring a more recent version of GHC to support pattern synonyms. At this stage, we don't expect to reuse GHC's parser to replace HSE's parser: HSE's parser supports some extra features like Haskell Server Pages, or regular expression patterns. Interested volunteers may even try to post a proposal (referring to Niklas Broberg's papers on the topic) to GHC Proposals[3] for adding them directly to GHC, hence enabling the integration. I'm afraid this problem of HSE (and also Template Haskell's AST and the related utilities) lagging behind GHC will get worse in time. Cheers, Shayan [1] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow [2] https://github.com/shayan-najd/GrowableGHC/blob/master/compiler/hsSyn/AST.hs [3] https://github.com/ghc-proposals/ghc-proposals On Fri, Aug 18, 2017 at 11:37 AM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > Hi all, > > I realise that people will be starting to use haskell-src-exts > libaries with the new GHC 8.2 release. However, I do not have time in > the foreseeable future (~ 1-2 months) to be able to implement the > necessary parts to support the new language features. > > The way to make an 8.2 compatible release happen sooner is to send me > some patches! > > There are some pull requests which I would like to merge but require > minor changes or rebasing and also a few language features which need > implementing. > > https://github.com/haskell-suite/haskell-src-exts/milestones/1.18 > > None of them look very difficult to implement unlike other language > changes in past releases. > > I started to work on what was necessary a few months ago but didn't > make a large amount of progress. > > https://github.com/haskell-suite/haskell-src-exts/tree/ghc-8.2 > > Anyone's help contributing to this important but menial library would > be greatly appreciated. > > Thanks, > > Matt > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Sat Aug 19 03:56:49 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 18 Aug 2017 20:56:49 -0700 Subject: [Haskell-cafe] Ternary infix expression parser Message-ID: I want to write a parser that lets someone write "(a #uses b) #because (c #needs d)" and read it into a tree: data Tree = Tree String Tree Tree | Leaf String magic "(a #uses b) #because (c #needs d)" = Tree "because" (Tree "uses" (Leaf "a") (Leaf "b")) (Tree "needs" (Leaf "c") (Leaf "d")) I thought I could use Text.Megaparsec.Expr for it, but now I realize it hadnles binary operations, and this is a ternary one. Suggestions? -- 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 jon.fairbairn at cl.cam.ac.uk Sat Aug 19 08:37:52 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sat, 19 Aug 2017 09:37:52 +0100 Subject: [Haskell-cafe] Ternary infix expression parser References: Message-ID: Jeffrey Brown writes: > I want to write a parser that lets someone write "(a #uses b) #because (c > #needs d)" and read it into a tree: > > data Tree = Tree String Tree Tree | Leaf String > magic "(a #uses b) #because (c #needs d)" > = Tree "because" (Tree "uses" (Leaf "a") (Leaf "b")) > (Tree "needs" (Leaf "c") (Leaf "d")) > > I thought I could use Text.Megaparsec.Expr for it, but now I realize it > hadnles binary operations, and this is a ternary one. > > Suggestions? Parse it as three binary ones and check the tree afterwards? -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk From doaitse.swierstra at gmail.com Sat Aug 19 10:13:26 2017 From: doaitse.swierstra at gmail.com (S D Swierstra) Date: Sat, 19 Aug 2017 12:13:26 +0200 Subject: [Haskell-cafe] Ternary infix expression parser In-Reply-To: References: Message-ID: <2944F811-110E-4E4B-AA36-320C42F85445@gmail.com> Make the #uses expr #because expr #needs part act like an operator? Doaitse > Op 19 aug. 2017 om 05:56 heeft Jeffrey Brown het volgende geschreven: > > I want to write a parser that lets someone write "(a #uses b) #because (c #needs d)" and read it into a tree: > > data Tree = Tree String Tree Tree | Leaf String > magic "(a #uses b) #because (c #needs d)" > = Tree "because" (Tree "uses" (Leaf "a") (Leaf "b")) > (Tree "needs" (Leaf "c") (Leaf "d")) > > I thought I could use Text.Megaparsec.Expr for it, but now I realize it hadnles binary operations, and this is a ternary one. > > Suggestions? > > > -- > 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 jeffbrown.the at gmail.com Sat Aug 19 19:14:48 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sat, 19 Aug 2017 12:14:48 -0700 Subject: [Haskell-cafe] Ternary infix expression parser In-Reply-To: <2944F811-110E-4E4B-AA36-320C42F85445@gmail.com> References: <2944F811-110E-4E4B-AA36-320C42F85445@gmail.com> Message-ID: I appear to be able to read Text.Megaparsec.Expr! This is a breakthrough for me. I think I refactor it. Thanks, and sorry for the noise. On Sat, Aug 19, 2017 at 3:13 AM, S D Swierstra wrote: > Make the #uses expr #because expr #needs part act like an operator? > > Doaitse > > Op 19 aug. 2017 om 05:56 heeft Jeffrey Brown > het volgende geschreven: > > I want to write a parser that lets someone write "(a #uses b) #because (c > #needs d)" and read it into a tree: > > data Tree = Tree String Tree Tree | Leaf String > magic "(a #uses b) #because (c #needs d)" > = Tree "because" (Tree "uses" (Leaf "a") (Leaf "b")) > (Tree "needs" (Leaf "c") (Leaf "d")) > > I thought I could use Text.Megaparsec.Expr for it, but now I realize it > hadnles binary operations, and this is a ternary one. > > Suggestions? > > > -- > 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. > > -- 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 tomandltimotej at gmail.com Mon Aug 21 04:52:21 2017 From: tomandltimotej at gmail.com (Timotej Tomandl) Date: Mon, 21 Aug 2017 05:52:21 +0100 Subject: [Haskell-cafe] Prevent a type parameter from sharing some of its parameters with another parameter Message-ID: As the title says. Motivation: in a mutable code I want to keep some parameters strictly immutable, i.e. not sharing s with the whole mutable type I think this is best illustrated by 2 examples: 1. abstract example: imagine I have a type X a b c and another type Y a b and I want to prevent any case where the first parameter of X "a" is shared with it's third parameter "c" i.e. X a b (Y a a), X a b (Y a b), X a b (Y b a), X a b (Y a d) etc., any nestings in Y referencing a etc. but allow X a b (Y b b), X a b (Y b c) and any other combination not ruled out above 2. concrete example: imagine I have a type: Item s element key where s is used in the same way as in STRef s a, i.e. it cannot leak outside of a certain context, but I want the key to be immutable i.e. independent of s under any circumstences, so I can't write a type like: Item s element (STRef s refType) this is equivalent to disallowing X a b (Y a d) in 1. Is there any way to write a restriction like this in Haskell? -- Timo -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Mon Aug 21 05:08:43 2017 From: kane at kane.cx (David Kraeutmann) Date: Mon, 21 Aug 2017 07:08:43 +0200 Subject: [Haskell-cafe] Prevent a type parameter from sharing some of its parameters with another parameter In-Reply-To: References: Message-ID: Check out TypeError from GHC.TypeLits, then make a type family or class that resolves to TypeError when both params are identical. e.g. {-# LANGUAGE TypeInType, MultiParamTypeClasses, FlexibleInstances, FlexibleContexts #-} class CheckDistinct a b instance {-# OVERLAPS #-} TypeError (Text "Parameters must be distinct") => CheckDistinct a a instance CheckDistinct a b > :t undefined :: CheckDistinct Int Double => Int undefined :: CheckDistinct Int Double => Int :: Int > :t undefined :: CheckDistinct Int Int => Int :1:1: error: Parameters must be distinct On 2017-08-21 06:52, Timotej Tomandl wrote: > As the title says. > > Motivation: > in a mutable code I want to keep some parameters strictly immutable, > i.e. not sharing s with the whole mutable type > > I think this is best illustrated by 2 examples: > 1. abstract example: > imagine I have a type > X a b c > and another type > Y a b > and I want to prevent any case where the first parameter of X "a" is > shared with it's third parameter "c" i.e. X a b (Y a a), X a b (Y a b), > X a b (Y b a), X a b (Y a d) etc., any nestings in Y referencing a etc. > but allow > X a b (Y b b), X a b (Y b c) > and any other combination not ruled out above > 2. concrete example: > imagine I have a type: > Item s element key > where s is used in the same way as in STRef s a, i.e. it cannot leak > outside of a certain context, but I want the key to be immutable i.e. > independent of s under any circumstences, so I can't write a type like: > Item s element (STRef s refType) > this is equivalent to disallowing X a b (Y a d) in 1. > > Is there any way to write a restriction like this in Haskell? > > -- >   Timo > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lysxia at gmail.com Mon Aug 21 05:45:35 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 21 Aug 2017 07:45:35 +0200 Subject: [Haskell-cafe] Prevent a type parameter from sharing some of its parameters with another parameter In-Reply-To: References: Message-ID: <9648023c-738a-3ec1-9e68-358bcfeb4998@gmail.com> Hi Timotej, What should happen if you capture the variable with an existential type: data E a = forall s. E (STRef s a) I guess there's not much we can do with this type anyway... Taking a complementary approach, you can write a typeclass of types that are allowed as keys. Since s is used like in ST, it must not unify with any concrete type, and there will be no instance of Allowed to be found. class Allowed a instance Allowed a => Allowed [a] instance (Allowed a, Allowed b) => Allowed (Either a b) If you can use PolyKinds and UndecidableInstances, some boilerplate can be avoided. -- Instance to traverse composite types. instance (Allowed f, Allowed a) => Allowed (f a) -- Every type constructor you can think of. instance Allowed Int instance Allowed [] instance Allowed Maybe instance Allowed Either -- etc Li-yao On 08/21/2017 06:52 AM, Timotej Tomandl wrote: > As the title says. > > Motivation: > in a mutable code I want to keep some parameters strictly immutable, i.e. > not sharing s with the whole mutable type > > I think this is best illustrated by 2 examples: > 1. abstract example: > imagine I have a type > X a b c > and another type > Y a b > and I want to prevent any case where the first parameter of X "a" is shared > with it's third parameter "c" i.e. X a b (Y a a), X a b (Y a b), X a b (Y b > a), X a b (Y a d) etc., any nestings in Y referencing a etc. > but allow > X a b (Y b b), X a b (Y b c) > and any other combination not ruled out above > 2. concrete example: > imagine I have a type: > Item s element key > where s is used in the same way as in STRef s a, i.e. it cannot leak > outside of a certain context, but I want the key to be immutable i.e. > independent of s under any circumstences, so I can't write a type like: > Item s element (STRef s refType) > this is equivalent to disallowing X a b (Y a d) in 1. > > Is there any way to write a restriction like this in Haskell? > > -- > Timo > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 tomandltimotej at gmail.com Mon Aug 21 14:27:50 2017 From: tomandltimotej at gmail.com (Timotej Tomandl) Date: Mon, 21 Aug 2017 15:27:50 +0100 Subject: [Haskell-cafe] Prevent a type parameter from sharing some of its parameters with another parameter In-Reply-To: References: Message-ID: Hi, after thinking about it a bit, I think it might be necessary to provide more context, so I opened an issue in my toy project this relates to: https://github.com/formrre/soft-heap-haskell/issues/5 -- Timo On Mon, Aug 21, 2017 at 5:52 AM, Timotej Tomandl wrote: > As the title says. > > Motivation: > in a mutable code I want to keep some parameters strictly immutable, i.e. > not sharing s with the whole mutable type > > I think this is best illustrated by 2 examples: > 1. abstract example: > imagine I have a type > X a b c > and another type > Y a b > and I want to prevent any case where the first parameter of X "a" is > shared with it's third parameter "c" i.e. X a b (Y a a), X a b (Y a b), X a > b (Y b a), X a b (Y a d) etc., any nestings in Y referencing a etc. > but allow > X a b (Y b b), X a b (Y b c) > and any other combination not ruled out above > 2. concrete example: > imagine I have a type: > Item s element key > where s is used in the same way as in STRef s a, i.e. it cannot leak > outside of a certain context, but I want the key to be immutable i.e. > independent of s under any circumstences, so I can't write a type like: > Item s element (STRef s refType) > this is equivalent to disallowing X a b (Y a d) in 1. > > Is there any way to write a restriction like this in Haskell? > > -- > Timo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pepeiborra at gmail.com Mon Aug 21 16:05:24 2017 From: pepeiborra at gmail.com (=?utf-8?Q?Jose_Iborra_L=C3=B3pez?=) Date: Mon, 21 Aug 2017 18:05:24 +0200 Subject: [Haskell-cafe] [ANN] arrowp-qq: an arrowp refresh Message-ID: Dear all, In case anyone finds it useful, there is a new version of arrowp in Hackage that improves the original with a much needed coat of fresh paint. Notable features include a new parser based on haskell-src-exts, a quasi quoter for arrow syntax, and improved desugaring for static choices. https://github.com/pepeiborra/arrowp The package is in Hackage as **arrowp-qq** due to the impossibility to contact with Ross Paterson (Ross, if you are reading this, please send email!). https://hackage.haskell.org/package/arrowp-qq For those of you reading this and wondering why would you want to use a preprocessor for something that GHC can already do, the short answer is that you probably don’t. Using the `proc` quasi quoter --------------------------- ``` addA :: Arrow a => a b Int -> a b Int -> a b Int addA f g = [proc| x -> do y <- f -< x z <- g -< x returnA -< y + z |] ``` Comparison with **arrowp** ----------------------- **arrowp-qq** extends the original **arrowp** in three dimensions: 1. It replaces the `haskell-src` based parser with one based on `haskell-src-exts`, which handles most of GHC 8.0.2 Haskell syntax. 2. It provides not only a preprocessor but also a quasiquoter, which is a better option in certain cases. 3. It extends the desugaring to handle static conditional expressions (currently only if-then-else). Example: ``` proc inputs -> do results <- processor -< inputs if outputResultsArg then outputSink -< results else returnA -< () returnA -< results ``` The standard **arrowp** (and GHC) desugaring for this code is: ``` = ((processor >>> arr (\ results -> (results, results))) >>> (first (arr (\ results -> if outputResultsArg then Left results else Right ()) >>> (outputSink ||| returnA)) >>> arr (\ (_, results) -> results))) ``` This requires an `ArrowChoice`, but there is a more efficient desugaring which performs the choice at compile time and thus an `Arrow` suffices: ``` ((processor >>> arr (\ results -> (results, results))) >>> (first (if outputResultsArg then outputSink else arr (\ results -> ())) >>> arr (\ (_, results) -> results))) ``` Comparison with **GHC** ----------------------- The GHC desugarer does not do a very good job of minimizing the number of `first` calls inserted. In certain `Arrow` instances, this can have a material effect on performance. Example: ``` trivial = proc inputs -> do chunked <- chunk -< inputs results <- process -< chunked returnA -< results ``` This code ought to desugar to a chain of arrows, and indeed, both arrowp and arrowp-qq desugar this to: ``` trivial = chunk >>> process ``` However GHC will produce (approximately) the following code: ``` arr(\inputs -> (inputs,inputs)) >>> first chunk >>> first process >>> arr fst ``` Thanks, Jose Iborra -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.studna2 at gmail.com Mon Aug 21 16:10:26 2017 From: martin.studna2 at gmail.com (Martin Studna) Date: Mon, 21 Aug 2017 18:10:26 +0200 Subject: [Haskell-cafe] Haskell - convert postfix expression to binary tree Message-ID: Hello, I am trying to convert postfix expression to binary tree. My function takes as argument a list of tokens (strings). Everytime I give the function any input, debugger writes a message: Non-exhaustive patterns in function "add". My idea was: read a token after token and determine, if it is an operator or an operand. If it is operand, don't save any node to the tree and store the number to the stack. Otherwise I create a node with an operator, pop symbols from stack, set them as children of new node and push the operator to stack. If the list of strings is empty, functions print the binary tree. Would someone explain to me, why the function gives non-exhaustive patterns error and how can I fix the function? data Tree = Leaf String | Empty | Node Tree String Tree deriving (Show) add :: Tree -> [String] -> [Tree] -> Tree add (Node l v p) [] stack = (Node l v p) add Empty (x:xs) [] | x `elem` ["*","-","+"] = add (Leaf x) xs [Leaf x] | otherwise = add Empty xs [Leaf x] add Empty (x:xs) (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:a:b:bs) | otherwise = add Empty xs (Leaf x:a:b:bs) add (Leaf x) token (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) token (Leaf x:bs) | otherwise = Leaf x add (Node l v p) (x:xs) (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:bs) | otherwise = add (Node l v p) xs (Leaf x:a:b:bs) parse :: String -> Tree parse input = add Empty (words (toPostfix input)) [] -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Aug 21 16:43:38 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 21 Aug 2017 12:43:38 -0400 Subject: [Haskell-cafe] Haskell - convert postfix expression to binary tree In-Reply-To: References: Message-ID: It would help if you included the full error, which shows which pattern it thinks is missing. Just looking at the code, one pattern I don't see is (add Empty [] _). And I think I see two other missing patterns which are more complex. On Mon, Aug 21, 2017 at 12:10 PM, Martin Studna wrote: > Hello, > > I am trying to convert postfix expression to binary tree. My function > takes as argument a list of tokens (strings). > > Everytime I give the function any input, debugger writes a message: > Non-exhaustive patterns in function "add". > > My idea was: read a token after token and determine, if it is an operator > or an operand. If it is operand, don't save any node to the tree and store > the number to the stack. Otherwise I create a node with an operator, pop > symbols from stack, set them as children of new node and push the operator > to stack. > > If the list of strings is empty, functions print the binary tree. > > Would someone explain to me, why the function gives non-exhaustive > patterns error and how can I fix the function? > > data Tree = Leaf String | Empty | Node Tree String Tree deriving (Show) > > add :: Tree -> [String] -> [Tree] -> Tree > add (Node l v p) [] stack = (Node l v p) > add Empty (x:xs) [] > | x `elem` ["*","-","+"] = add (Leaf x) xs [Leaf x] > | otherwise = add Empty xs [Leaf x] > add Empty (x:xs) (a:b:bs) > | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:a:b:bs) > | otherwise = add Empty xs (Leaf x:a:b:bs) > add (Leaf x) token (a:b:bs) > | x `elem` ["*","-","+"] = add (Node b x a) token (Leaf x:bs) > | otherwise = Leaf x > add (Node l v p) (x:xs) (a:b:bs) > | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:bs) > | otherwise = add (Node l v p) xs (Leaf x:a:b:bs) > > parse :: String -> Tree > parse input = add Empty (words (toPostfix input)) [] > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 mblazevic at stilo.com Tue Aug 22 21:50:01 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Tue, 22 Aug 2017 17:50:01 -0400 Subject: [Haskell-cafe] Fwd: Re: 123 In-Reply-To: <46f6ccda-653f-47d5-9854-4e3d7f951edd@gmail.com> References: <6afdb5a6-ff30-f84c-24a1-8a85c50e395d@gmail.com> <46f6ccda-653f-47d5-9854-4e3d7f951edd@gmail.com> Message-ID: <38c2cdc4-a237-2411-b244-2d435966fae9@stilo.com> On 2017-08-16 04:54 PM, Dmitriy Matrosov wrote: > And even sent the answer not to the list.. Huh. I'm not sure I fully undestand your use case, but your examples can be handled by the rank2classes package (http://hackage.haskell.org/package/rank2classes). > I want to have a type with many records: > >> data Volume t = Volume >> { _volName :: t String >> , _volSize :: t Int >> } >> >> showVolume :: (Show (t String), Show (t Int)) => Volume t -> String >> showVolume x = "Volume " ++ show (_volName x) ++ ", " ++ show > (_volSize x) > > with instances parametrized by some other type. E.g. i want to define a > `Monoid` based on that other type properties: > >> instance Alternative t => Monoid (Volume t) where >> mempty = Volume {_volName = empty, _volSize = empty} >> x `mappend` y = Volume >> { _volName = _volName x <|> _volName y >> , _volSize = _volSize x <|> _volSize y >> } instance Rank2.Apply Volume where x <*> y = Volume { _volName = _volName x `Rank2.apply` _volName y , _volSize = _volSize x `Rank2.apply` _volSize y } instance Rank2.Applicative Volume where pure x = Volume {_volName = x, _volSize = x} instance Alternative t => Monoid (Volume t) where mempty = Rank2.pure empty x `mappend` y = Rank2.liftA2 (<|>) x y From dct25-561bs at mythic-beasts.com Wed Aug 23 10:22:10 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Wed, 23 Aug 2017 11:22:10 +0100 Subject: [Haskell-cafe] Experience Report (and [Hiring]) Message-ID: Hi all, In answer to @snoyberg's call to action a few months back ( https://www.snoyman.com/blog/2017/04/haskell-success-stories) I have written up an experience report and survey results from Tracsis where I currently work: https://davecturner.github.io/2017/08/21/haskell-experience.html Also if you are interested in developer jobs in sunny Leeds and fancy joining our growing team of Haskell developers then there are links in the post with contact information and more details. We're hiring at all levels from fresh graduates up to a new Principal Developer. Please get in touch with me and/or Andrew Handley (CCd) if you'd like to ask any questions. Cheers, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Wed Aug 23 13:00:37 2017 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 23 Aug 2017 14:00:37 +0100 Subject: [Haskell-cafe] GHC fails to fuse [1 .. 30000000 :: Double] but fuses fromIntegral <$> [1 :: Int .. 30000000]? Message-ID: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> Hi, I had few minutes timeout waiting for CI today and I stumbled upon [1]. This is a many years old question and the optimal solution given there was using Vector. I thought that for such a problem it should not be necessary at all. Indeed I wrote `mean :: [Int] -> Int` and got a much faster solution. However the original signature was `mean :: [Double] -> Int`. After trivial changes (change couple of places to Double and add a single fromIntegral) I expected the same result: after all, code is nearly exactly the same. However to my disappointment, the code in question was much slower than the vector solution: how could this be? Looking in Core, I saw that GHC was not getting rid of [Double] like it was with [Int]. I was able to convince GHC to go back to fusing the list into the worker with a `map fromIntegral` but I am unhappy: why is this needed? I don't understand why GHC would not decide to fuse the initial attempt. Honestly it seems like a bug to me. What are your thoughts? For reference here is the core with fromIntegral: as expected, GHC fuses the list and inserts int2Double# as it's generating it: ``` Main.$wgo = \ (w_s5xT :: GHC.Prim.Int#) (ww_s5xX :: GHC.Prim.Int#) (ww1_s5xY :: GHC.Prim.Double#) -> case w_s5xT of wild_Xz { __DEFAULT -> Main.$wgo (GHC.Prim.+# wild_Xz 1#) (GHC.Prim.+# ww_s5xX 1#) (GHC.Prim.+## ww1_s5xY (GHC.Prim.int2Double# wild_Xz)); 30000000# -> (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) } ``` Contrast this with version that's commented out in [2]: ``` Main.$wgo = \ (w_s5vE :: [Double]) (ww_s5vI :: GHC.Prim.Int#) (ww1_s5vJ :: GHC.Prim.Double#) -> case w_s5vE of _ [Occ=Dead] { [] -> (# ww_s5vI, ww1_s5vJ #); : y_a3dU ys_a3dV -> case y_a3dU of _ [Occ=Dead] { GHC.Types.D# y1_a3dG -> Main.$wgo ys_a3dV (GHC.Prim.+# ww_s5vI 1#) (GHC.Prim.+## ww1_s5vJ y1_a3dG) } } … case Main.$wgo Main.main3 0# 0.0## … Main.main3 = GHC.Real.numericEnumFromTo @ Double GHC.Classes.$fOrdDouble GHC.Float.$fFractionalDouble Main.main5 Main.main4 … Main.main4 = GHC.Types.D# 3.0e7## … Main.main5 = GHC.Types.D# 1.0## ``` Why? There should be nothing stopping it from doing ``` Main.$wgo = \ (w_s5xT :: GHC.Prim.Double#) (ww_s5xX :: GHC.Prim.Int#) (ww1_s5xY :: GHC.Prim.Double#) -> case w_s5xT of wild_Xz { __DEFAULT -> Main.$wgo (GHC.Prim.+# wild_Xz 1#) (GHC.Prim.+# ww_s5xX 1#) (GHC.Prim.+## ww1_s5xY wild_Xz); 3.0e7## -> (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) ``` Perhaps it's afraid to make the pattern match on a floating point number? Insights welcome. [1]: https://stackoverflow.com/questions/3300995/computing-the-mean-of-a-list-efficiently-in-haskell/45840148 [2]: https://stackoverflow.com/a/45840148/1432740 -- Mateusz K. From fuuzetsu at fuuzetsu.co.uk Wed Aug 23 14:54:15 2017 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Wed, 23 Aug 2017 15:54:15 +0100 Subject: [Haskell-cafe] GHC fails to fuse [1 .. 30000000 :: Double] but fuses fromIntegral <$> [1 :: Int .. 30000000]? In-Reply-To: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> References: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> Message-ID: On 08/23/2017 02:00 PM, Mateusz Kowalczyk wrote: > Hi, > > I had few minutes timeout waiting for CI today and I stumbled upon [1]. > This is a many years old question and the optimal solution given there > was using Vector. I thought that for such a problem it should not be > necessary at all. > > Indeed I wrote `mean :: [Int] -> Int` and got a much faster solution. > However the original signature was `mean :: [Double] -> Int`. After > trivial changes (change couple of places to Double and add a single > fromIntegral) I expected the same result: after all, code is nearly > exactly the same. > > However to my disappointment, the code in question was much slower than > the vector solution: how could this be? Looking in Core, I saw that GHC > was not getting rid of [Double] like it was with [Int]. I was able to > convince GHC to go back to fusing the list into the worker with a `map > fromIntegral` but I am unhappy: why is this needed? I don't understand > why GHC would not decide to fuse the initial attempt. Honestly it seems > like a bug to me. > > What are your thoughts? For reference here is the core with > fromIntegral: as expected, GHC fuses the list and inserts int2Double# as > it's generating it: > > ``` > Main.$wgo = > \ (w_s5xT :: GHC.Prim.Int#) > (ww_s5xX :: GHC.Prim.Int#) > (ww1_s5xY :: GHC.Prim.Double#) -> > case w_s5xT of wild_Xz { > __DEFAULT -> > Main.$wgo > (GHC.Prim.+# wild_Xz 1#) > (GHC.Prim.+# ww_s5xX 1#) > (GHC.Prim.+## ww1_s5xY (GHC.Prim.int2Double# wild_Xz)); > 30000000# -> > (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) > } > ``` > > Contrast this with version that's commented out in [2]: > > ``` > Main.$wgo = > \ (w_s5vE :: [Double]) > (ww_s5vI :: GHC.Prim.Int#) > (ww1_s5vJ :: GHC.Prim.Double#) -> > case w_s5vE of _ [Occ=Dead] { > [] -> (# ww_s5vI, ww1_s5vJ #); > : y_a3dU ys_a3dV -> > case y_a3dU of _ [Occ=Dead] { GHC.Types.D# y1_a3dG -> > Main.$wgo > ys_a3dV (GHC.Prim.+# ww_s5vI 1#) (GHC.Prim.+## ww1_s5vJ y1_a3dG) > } > } > > … > > case Main.$wgo Main.main3 0# 0.0## > … > Main.main3 = > GHC.Real.numericEnumFromTo > @ Double > GHC.Classes.$fOrdDouble > GHC.Float.$fFractionalDouble > Main.main5 > Main.main4 > … > Main.main4 = GHC.Types.D# 3.0e7## > … > Main.main5 = GHC.Types.D# 1.0## > ``` > > Why? There should be nothing stopping it from doing > > ``` > > Main.$wgo = > \ (w_s5xT :: GHC.Prim.Double#) > (ww_s5xX :: GHC.Prim.Int#) > (ww1_s5xY :: GHC.Prim.Double#) -> > case w_s5xT of wild_Xz { > __DEFAULT -> > Main.$wgo > (GHC.Prim.+# wild_Xz 1#) > (GHC.Prim.+# ww_s5xX 1#) > (GHC.Prim.+## ww1_s5xY wild_Xz); > 3.0e7## -> > (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) > ``` > > Perhaps it's afraid to make the pattern match on a floating point number? > > Insights welcome. > > > [1]: > https://stackoverflow.com/questions/3300995/computing-the-mean-of-a-list-efficiently-in-haskell/45840148 > [2]: https://stackoverflow.com/a/45840148/1432740 > Correction: The signatures of mean I was referring to were supposed to be ‘[Int] -> Double’ and then ‘[Double] -> Double’. Somewhat obviously. -- Mateusz K. From sgf.dma at gmail.com Wed Aug 23 19:14:19 2017 From: sgf.dma at gmail.com (Dmitriy Matrosov) Date: Wed, 23 Aug 2017 22:14:19 +0300 Subject: [Haskell-cafe] Functor instance for GADT (was: 123) In-Reply-To: <38c2cdc4-a237-2411-b244-2d435966fae9@stilo.com> References: <6afdb5a6-ff30-f84c-24a1-8a85c50e395d@gmail.com> <46f6ccda-653f-47d5-9854-4e3d7f951edd@gmail.com> <38c2cdc4-a237-2411-b244-2d435966fae9@stilo.com> Message-ID: <030f900f-3060-018f-1d32-695dd3aadfc1@gmail.com> On 08/23/2017 12:50 AM, Mario Blažević wrote: > On 2017-08-16 04:54 PM, Dmitriy Matrosov wrote: >> And even sent the answer not to the list.. Huh. > > I'm not sure I fully undestand your use case, but your examples can be > handled by the rank2classes package > (http://hackage.haskell.org/package/rank2classes). > > >> I want to have a type with many records: >> >>> data Volume t = Volume >>> { _volName :: t String >>> , _volSize :: t Int >>> } >>> >>> showVolume :: (Show (t String), Show (t Int)) => Volume t -> String >>> showVolume x = "Volume " ++ show (_volName x) ++ ", " ++ show >> (_volSize x) >> >> with instances parametrized by some other type. E.g. i want to define a >> `Monoid` based on that other type properties: >> >>> instance Alternative t => Monoid (Volume t) where >>> mempty = Volume {_volName = empty, _volSize = empty} >>> x `mappend` y = Volume >>> { _volName = _volName x <|> _volName y >>> , _volSize = _volSize x <|> _volSize y >>> } > > > instance Rank2.Apply Volume where > x <*> y = Volume > { _volName = _volName x `Rank2.apply` _volName y > , _volSize = _volSize x `Rank2.apply` _volSize y > } > > instance Rank2.Applicative Volume where > pure x = Volume {_volName = x, _volSize = x} > > instance Alternative t => Monoid (Volume t) where > mempty = Rank2.pure empty > x `mappend` y = Rank2.liftA2 (<|>) x y > Yes, that's almost exactly what i want! I said "almost", because i want to use it with GADT, which `mappend`-s different types differently. So, when i `mappend` `Volume`-s, different fields are summed differently. Here is the code i have so far: > {-# LANGUAGE GADTs #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE RecordWildCards #-} > {-# LANGUAGE ScopedTypeVariables #-} > > import Control.Applicative > import Data.Monoid > import Data.Functor.Classes > > data Volume t = Volume > { _volName :: t String > , _volSize :: t Int > } > > > instance Alternative t => Monoid (Volume t) where > mempty = Volume {_volName = empty, _volSize = empty} > x `mappend` y = Volume > { _volName = _volName x <|> _volName y > , _volSize = _volSize x <|> _volSize y > } Then 'Show' defined with the help of 'Show1' as suggested by Isaac Elliott: > instance Show1 t => Show (Volume t) where > showsPrec n Volume {..} = showString "Volume " > . showsPrec1 n _volName > . showsPrec1 n _volSize or alternative approach suggested by Dmitry Olshansky: > --instance forall t. (Functor t, Foldable t) => Show (Volume t) where > -- showsPrec n Volume {..} = showString "Volume " > -- . showsPrec1' n _volName > -- . showsPrec1' n _volSize > -- where > -- liftShowsPrec' :: (Int -> a -> ShowS) -> Int -> t a -> ShowS > -- liftShowsPrec' sp m = appEndo . foldMap id . fmap (Endo . sp m) > -- showsPrec1' :: Show a => Int -> t a -> ShowS > -- showsPrec1' m = liftShowsPrec' showsPrec m That's the part, which was in the original question, and it works fine now. Thanks to all! But there is also the other part, which i was unaware of. > data Config a where > Empty :: Config a > Name :: Last String -> Config String > Size :: Num a => Sum a -> Config a > deriving instance Show a => Show (Config a) First, i need some convenient way (don't think about it yet) to construct a values like: > vconf1 :: Volume Config > vconf1 = Volume > { _volName = Name (Last (Just "abc")) > , _volSize = Size (Sum 12) > } > vconf2 :: Volume Config > vconf2 = Volume > { _volName = Name (Last (Just "def")) > , _volSize = Size (Sum 100) > } Second, probably more importantly, i need to `mappend` them. Essentially, i want `Config` to behave like > instance Monoid (Config a) where > mempty = Empty > (Name x) `mappend` (Name y) = Name (x `mappend` y) > (Size x) `mappend` (Size y) = Size (x `mappend` y) > x `mappend` Empty = x > Empty `mappend` y = y but i need it to be an `Alternative`. And i can't define a `Functor` instance for it. From stuart at cs.uchicago.edu Wed Aug 23 16:46:22 2017 From: stuart at cs.uchicago.edu (Stuart A. Kurtz) Date: Wed, 23 Aug 2017 11:46:22 -0500 Subject: [Haskell-cafe] Haskell Platform Message-ID: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Dear Colleagues, What's the status of the Haskell Platform? Is it still the/a preferred way to install a working Haskell system? What is the update status of the Platform? [I note that the platform is at 8.0.2, whereas GHC is at 8.2.1, so I'm really asking if there's a roadmap/timeline for updates.] I write because I teach an introductory class in Haskell, and we've long used the Platform as a way to get the system up and running on the student's systems. I'm at a quarter school, but I have to think this is a sharp question for anyone trying to teach a Haskell course at a semester school. Is the Platform still the best way to do this? Will cabal continue to be a reasonable choice as default package manager? Thank you for your consideration. Peace, Stu From vieira.ufpi at gmail.com Wed Aug 23 21:43:06 2017 From: vieira.ufpi at gmail.com (Francisco Vieira de Souza) Date: Wed, 23 Aug 2017 18:43:06 -0300 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: I have the same question. I'm teaching an introductory course about "Functional Programming in Haskell" and I'm having the same problem in my course. Thanks in advance, F. Vieira 2017-08-23 13:46 GMT-03:00 Stuart A. Kurtz : > Dear Colleagues, > > What's the status of the Haskell Platform? Is it still the/a preferred way > to install a working Haskell system? What is the update status of the > Platform? [I note that the platform is at 8.0.2, whereas GHC is at 8.2.1, > so I'm really asking if there's a roadmap/timeline for updates.] > > I write because I teach an introductory class in Haskell, and we've long > used the Platform as a way to get the system up and running on the > student's systems. I'm at a quarter school, but I have to think this is a > sharp question for anyone trying to teach a Haskell course at a semester > school. > > Is the Platform still the best way to do this? Will cabal continue to be a > reasonable choice as default package manager? > > Thank you for your consideration. > > Peace, > > Stu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- "Embora ninguém possa voltar atrás e fazer um novo começo, qualquer um pode começar agora e fazer um novo fim". (Chico Xavier) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Wed Aug 23 21:46:59 2017 From: gershomb at gmail.com (Gershom B) Date: Wed, 23 Aug 2017 17:46:59 -0400 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: I’m hoping to release a new platform either tonight or tomorrow. We delayed the release of the platform more than usual after the GHC release for two reasons. First: we wanted to wait for a new cabal-install release, which is now out, and provides integration with the experimental “backpack” module system in the new GHC. Second: We ran into what seems to be a serious bug in GHC 8.2.1 on win32 platforms, and wanted to see if it could be resolved quickly. [1] The current plan is to just only provide a 64 bit windows release for 8.2.1 as we don’t believe the 32 bit release is stable at this time. In general, we continue to support the platform, and aim for releases within a few weeks of GHC releases, or sooner. And from download statistics, while I can’t judge them comparitively, it still seems to be widely downloaded and installed, especially on windows systems. There are certainly other choices, and I don’t think there is any “communitywide” consensus across different userbases (be they commercial, of various sorts, educational, etc.), but we on the platform team definitely are continuing to support it, and hopefully improve its quality over time. As for cabal — the team can speak to that better than I. But there’s certainly a great deal of support and active development going on at the moment (witness the new backpack support in cabal-install 2.0 for example), and the team working on it seems to have acquired some steady momentum. It also remains widely used by all accounts. Best, Gershom [1]: https://ghc.haskell.org/trac/ghc/ticket/14081  On August 23, 2017 at 5:34:41 PM, Stuart A. Kurtz (stuart at cs.uchicago.edu) wrote: > Dear Colleagues, > > What's the status of the Haskell Platform? Is it still the/a preferred way to install > a working Haskell system? What is the update status of the Platform? [I note that the platform > is at 8.0.2, whereas GHC is at 8.2.1, so I'm really asking if there's a roadmap/timeline > for updates.] > > I write because I teach an introductory class in Haskell, and we've long used the Platform > as a way to get the system up and running on the student's systems. I'm at a quarter school, > but I have to think this is a sharp question for anyone trying to teach a Haskell course > at a semester school. > > Is the Platform still the best way to do this? Will cabal continue to be a reasonable choice > as default package manager? > > Thank you for your consideration. > > Peace, > > Stu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 harendra.kumar at gmail.com Thu Aug 24 01:25:01 2017 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 24 Aug 2017 06:55:01 +0530 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: Hi Stuart, I am not sure if there is a unanimous preferred way of installing Haskell. I guess the answer depends on who you ask. My preferred choice is "stack". I am no university prof or a school teacher but I do teach Haskell to my 6th grader and 2nd grader kids. I gave them a laptop (Mac OS) and told them how to install "stack" and they did it in a jiffy. They have been using it for several months with no complaints whatsoever. If little kids can do it I guess it should not be a problem for univ students. I have also been using stack myself for my professional work and it resonates well with my own thinking of how a package (and language tools) manager should behave. Additionally the stack team is very responsive if you want to get something fixed. When I started learning Haskell a few years ago I really enjoyed contributing to stack thanks to Michael Sloan's quick responses and encouraging feedback on the PRs. -harendra On 23 August 2017 at 22:16, Stuart A. Kurtz wrote: > Dear Colleagues, > > What's the status of the Haskell Platform? Is it still the/a preferred way > to install a working Haskell system? What is the update status of the > Platform? [I note that the platform is at 8.0.2, whereas GHC is at 8.2.1, > so I'm really asking if there's a roadmap/timeline for updates.] > > I write because I teach an introductory class in Haskell, and we've long > used the Platform as a way to get the system up and running on the > student's systems. I'm at a quarter school, but I have to think this is a > sharp question for anyone trying to teach a Haskell course at a semester > school. > > Is the Platform still the best way to do this? Will cabal continue to be a > reasonable choice as default package manager? > > Thank you for your consideration. > > Peace, > > Stu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 adam at adamflott.com Thu Aug 24 01:29:35 2017 From: adam at adamflott.com (Adam Flott) Date: Wed, 23 Aug 2017 21:29:35 -0400 Subject: [Haskell-cafe] Managing a sum type with a lot of constructors Message-ID: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> I have a sum type with a lot of constructors and I'm not sure how to represent the type with maintainability in mind. For example, data A = A1 | A2 Int | A3 Text Int32 Bool | ... | A100 Bool Every inner type is concrete. There are 100+ constructors with no sign of ever getting reduced. What technique would you recommend to keep the sum type approach but not having to define them all in one spot? I'm thinking 1 inner type + 1 function to construct per file (if that's possible). From michaelburge at pobox.com Thu Aug 24 01:45:13 2017 From: michaelburge at pobox.com (Michael Burge) Date: Wed, 23 Aug 2017 18:45:13 -0700 Subject: [Haskell-cafe] Managing a sum type with a lot of constructors In-Reply-To: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> References: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> Message-ID: If you have that many constructors, you probably aren't pattern-matching against the whole thing everywhere. So you could extract the few functions that use the entire type for case analysis into a typeclass, make each constructor its own type, and implement the typeclass: Instead of: something :: A -> IO () something A1 = putStrLn "hello" something (A2 _) = putStrLn "world" Use: data A1 data A2 = A2 Int class RelatedConst a of something :: a -> IO () instance RelatedConst A1 where something _ = putStrLn "hello" instance RelatedConst A2 where something _ = putStrLn "world" Then, each declaration and instance could go in its own file. If on the other hand, you are using lots of partial case matches everywhere, see if there are commonalities and extract a typeclass for each group On Wed, Aug 23, 2017 at 6:29 PM, Adam Flott wrote: > I have a sum type with a lot of constructors and I'm not sure how to > represent > the type with maintainability in mind. For example, > > data A = A1 > | A2 Int > | A3 Text Int32 Bool > | ... > | A100 Bool > > Every inner type is concrete. There are 100+ constructors with no sign of > ever > getting reduced. > > What technique would you recommend to keep the sum type approach but not > having > to define them all in one spot? I'm thinking 1 inner type + 1 function to > construct per file (if that's possible). > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 clintonmead at gmail.com Thu Aug 24 02:00:18 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Thu, 24 Aug 2017 02:00:18 +0000 Subject: [Haskell-cafe] How to split (or not split) modules Message-ID: Given that one can write modules that just do reexports to control namespaces, it seems to me you've got a lot of flexibility about how you organise your actual code into modules. As long as mutually recursive functions are in the same module and instances are not orphan, you can go from the one extreme of placing all the code on one module to the other extreme of placing each function in a separate module. I believe any performance concerns regarding inlining can be addressed with explicit inline annotations. I can see the point of not having non exported functions in their own module, because to do so would mean producing extra interface code which is never directly used by clients. But other than the concerns mentioned above, I can't really work out whether to have all my code for a package in one module and split it with re-export modules, or have it in lots of little modules and combine it with re-export modules. Any guidance with the pros/cons of both approaches would be appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart at cs.uchicago.edu Thu Aug 24 03:17:16 2017 From: stuart at cs.uchicago.edu (Stuart A. Kurtz) Date: Wed, 23 Aug 2017 22:17:16 -0500 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: <9DAB7D5A-8C09-4E02-B0F1-FAF370C178ED@cs.uchicago.edu> Dear Gershom, > I’m hoping to release a new platform either tonight or tomorrow. Excellent news! And thank you very much for your hard work getting this done. It is extraordinarily valuable to folks like me. Peace, Stu From dave.laing.80 at gmail.com Thu Aug 24 04:45:44 2017 From: dave.laing.80 at gmail.com (David Laing) Date: Thu, 24 Aug 2017 14:45:44 +1000 Subject: [Haskell-cafe] [ANN] tasty-hedgehog: Adds support for the hedgehog property-based testing library to the tasty testing framework Message-ID: Hi, I'm happy to announce tasty-hedgehog: https://hackage.haskell.org/package/tasty-hedgehog They are two great flavours that (now) work together, so I hope it's useful to many of you. There's an example of usage in the README on the GitHub page: https://github.com/qfpl/tasty-hedgehog Cheers, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddhanathan+eml at gmail.com Thu Aug 24 05:52:11 2017 From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam) Date: Thu, 24 Aug 2017 01:52:11 -0400 Subject: [Haskell-cafe] GHC fails to fuse [1 .. 30000000 :: Double] but fuses fromIntegral <$> [1 :: Int .. 30000000]? In-Reply-To: References: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> Message-ID: I believe it is because of numericEnumFromTo which forces the elements of the list. On Wed, Aug 23, 2017 at 10:54 AM, Mateusz Kowalczyk wrote: > On 08/23/2017 02:00 PM, Mateusz Kowalczyk wrote: > > Hi, > > > > I had few minutes timeout waiting for CI today and I stumbled upon [1]. > > This is a many years old question and the optimal solution given there > > was using Vector. I thought that for such a problem it should not be > > necessary at all. > > > > Indeed I wrote `mean :: [Int] -> Int` and got a much faster solution. > > However the original signature was `mean :: [Double] -> Int`. After > > trivial changes (change couple of places to Double and add a single > > fromIntegral) I expected the same result: after all, code is nearly > > exactly the same. > > > > However to my disappointment, the code in question was much slower than > > the vector solution: how could this be? Looking in Core, I saw that GHC > > was not getting rid of [Double] like it was with [Int]. I was able to > > convince GHC to go back to fusing the list into the worker with a `map > > fromIntegral` but I am unhappy: why is this needed? I don't understand > > why GHC would not decide to fuse the initial attempt. Honestly it seems > > like a bug to me. > > > > What are your thoughts? For reference here is the core with > > fromIntegral: as expected, GHC fuses the list and inserts int2Double# as > > it's generating it: > > > > ``` > > Main.$wgo = > > \ (w_s5xT :: GHC.Prim.Int#) > > (ww_s5xX :: GHC.Prim.Int#) > > (ww1_s5xY :: GHC.Prim.Double#) -> > > case w_s5xT of wild_Xz { > > __DEFAULT -> > > Main.$wgo > > (GHC.Prim.+# wild_Xz 1#) > > (GHC.Prim.+# ww_s5xX 1#) > > (GHC.Prim.+## ww1_s5xY (GHC.Prim.int2Double# wild_Xz)); > > 30000000# -> > > (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) > > } > > ``` > > > > Contrast this with version that's commented out in [2]: > > > > ``` > > Main.$wgo = > > \ (w_s5vE :: [Double]) > > (ww_s5vI :: GHC.Prim.Int#) > > (ww1_s5vJ :: GHC.Prim.Double#) -> > > case w_s5vE of _ [Occ=Dead] { > > [] -> (# ww_s5vI, ww1_s5vJ #); > > : y_a3dU ys_a3dV -> > > case y_a3dU of _ [Occ=Dead] { GHC.Types.D# y1_a3dG -> > > Main.$wgo > > ys_a3dV (GHC.Prim.+# ww_s5vI 1#) (GHC.Prim.+## ww1_s5vJ > y1_a3dG) > > } > > } > > > > … > > > > case Main.$wgo Main.main3 0# 0.0## > > … > > Main.main3 = > > GHC.Real.numericEnumFromTo > > @ Double > > GHC.Classes.$fOrdDouble > > GHC.Float.$fFractionalDouble > > Main.main5 > > Main.main4 > > … > > Main.main4 = GHC.Types.D# 3.0e7## > > … > > Main.main5 = GHC.Types.D# 1.0## > > ``` > > > > Why? There should be nothing stopping it from doing > > > > ``` > > > > Main.$wgo = > > \ (w_s5xT :: GHC.Prim.Double#) > > (ww_s5xX :: GHC.Prim.Int#) > > (ww1_s5xY :: GHC.Prim.Double#) -> > > case w_s5xT of wild_Xz { > > __DEFAULT -> > > Main.$wgo > > (GHC.Prim.+# wild_Xz 1#) > > (GHC.Prim.+# ww_s5xX 1#) > > (GHC.Prim.+## ww1_s5xY wild_Xz); > > 3.0e7## -> > > (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) > > ``` > > > > Perhaps it's afraid to make the pattern match on a floating point number? > > > > Insights welcome. > > > > > > [1]: > > https://stackoverflow.com/questions/3300995/computing- > the-mean-of-a-list-efficiently-in-haskell/45840148 > > [2]: https://stackoverflow.com/a/45840148/1432740 > > > > Correction: The signatures of mean I was referring to were supposed to > be ‘[Int] -> Double’ and then ‘[Double] -> Double’. Somewhat obviously. > > -- > 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 maydwell at gmail.com Thu Aug 24 06:18:48 2017 From: maydwell at gmail.com (Lyndon Maydwell) Date: Thu, 24 Aug 2017 16:18:48 +1000 Subject: [Haskell-cafe] ANN: Compose :: Melbourne Conference and Unconference [Melbourne, Australia - August 28 & 29] Message-ID: Since I don't believe I've updated Haskell Cafe since this year's CFP, on behalf of the Melbourne Committee I'm sending a last-minute reminder that Compose :: Conference Melbourne is running this Monday and Tuesday the 28th and 29th! All information is available online at http://www.composeconference.org/ Tickets are on sale for Day-One on Eventbrite: https://www. eventbrite.com/e/compose-melbourne-2017-tickets-34612742645 Programme: http://www.composeconference.org/2017-melbourne/day-one-program/ The second day (unconference) is free for all and will feature workshops, talks, and many other organised and disorganised activities! Unconference Information: http://www.composeconference.org/2017- melbourne/unconference/ Follow the Melbourne event on Twitter: https://twitter.com/ComposeMelb About Compose and Compose :: Melbourne Compose is a conference for functional programmers, focused on technologies such as Haskell, Scala, Clojure, OCaml, F#, SML and others. Functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. Our experiences have shown that the theoretical can be put into practice with great success, and that topics once considered “advanced” can be made understandable and spread widely. For example, type systems, often considered complex, can simplify our lives by teaching compilers to do some of our reasoning for us. Compose Conference began in New York in 2015. Warm Regards, - Lyndon -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Thu Aug 24 07:45:18 2017 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Thu, 24 Aug 2017 08:45:18 +0100 Subject: [Haskell-cafe] Managing a sum type with a lot of constructors In-Reply-To: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> References: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> Message-ID: Hi, We have a sum type of 151 constructors (and growing) in one project. There is a somewhat natural grouping of the constructors into 24 groups (with between 1 and 32 constructors in each group) so we used that to break it down into the two levels: data Group1 = Ctor1 Int | Ctor2 Bool | ... data Group2 = Ctor5 String | Ctor6 Double | ... ... data A = Group1 Group1 | Group2 Group2 | ... This wasn't enough, so then we cheated and wrote some code-gen. The datatype is described as data (think YAML or JSON) and then there's a short program which generates the declarations, including Haddock comments, and various useful functions such as somewhat-custom JSON serialisation. Each group gets its own module, which gives faster recompilation on changes. We could have used TemplateHaskell, except we wouldn't have got such nice Haddock docs (and, ew, TemplateHaskell) and it would all have had to have been in one module. Hope that helps, David On 24 August 2017 at 02:29, Adam Flott wrote: > I have a sum type with a lot of constructors and I'm not sure how to > represent > the type with maintainability in mind. For example, > > data A = A1 > | A2 Int > | A3 Text Int32 Bool > | ... > | A100 Bool > > Every inner type is concrete. There are 100+ constructors with no sign of > ever > getting reduced. > > What technique would you recommend to keep the sum type approach but not > having > to define them all in one spot? I'm thinking 1 inner type + 1 function to > construct per file (if that's possible). > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 pavel.ryzhov at gmail.com Thu Aug 24 08:26:36 2017 From: pavel.ryzhov at gmail.com (Pavel Ryzhov) Date: Thu, 24 Aug 2017 10:26:36 +0200 Subject: [Haskell-cafe] [ANN] HSvm: Haskell bindings to libsvm library Message-ID: Hi all, I am happy to announce the new version of HSvm package: http://hackage.haskell.org/package/HSvm The changelog is: 1. Upgraded to libsvm 3.22. 2. Compatibility with GHC 8.0.2 and GHC 8.2.1. 3. Fixed few bugs in marshaling of C structures. 4. Code cleanup. 5. Documentation is improved. HSvm sources are now available on GitHub: https://github.com/paulrzcz/HSvm The package is also available at Stackage Nightly from 2017-08-17: https://www.stackage.org/nightly-2017-08-17/package/HSvm-0.1.0.3.22 Thanks to Paolo Losi for package and cooperation! Cheers, Pavel -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Thu Aug 24 09:48:04 2017 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Thu, 24 Aug 2017 10:48:04 +0100 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: <5E744683-E238-4CF6-9EBB-23AD1784E1B1@scss.tcd.ie> Hi Stuart, I'll give a strong vote for "stack" as well - it also has the very nice property where it identfifies errors in the associated project cabal file and gives correct suggestions for fixing them - it has made my life infinitely easier of late PS - I teach Haskell at university level... Cheers, Andrew > On 24 Aug 2017, at 02:25, Harendra Kumar wrote: > > Hi Stuart, > > I am not sure if there is a unanimous preferred way of installing Haskell. I guess the answer depends on who you ask. My preferred choice is "stack". I am no university prof or a school teacher but I do teach Haskell to my 6th grader and 2nd grader kids. I gave them a laptop (Mac OS) and told them how to install "stack" and they did it in a jiffy. They have been using it for several months with no complaints whatsoever. If little kids can do it I guess it should not be a problem for univ students. > > I have also been using stack myself for my professional work and it resonates well with my own thinking of how a package (and language tools) manager should behave. Additionally the stack team is very responsive if you want to get something fixed. When I started learning Haskell a few years ago I really enjoyed contributing to stack thanks to Michael Sloan's quick responses and encouraging feedback on the PRs. > > -harendra > > On 23 August 2017 at 22:16, Stuart A. Kurtz > wrote: > Dear Colleagues, > > What's the status of the Haskell Platform? Is it still the/a preferred way to install a working Haskell system? What is the update status of the Platform? [I note that the platform is at 8.0.2, whereas GHC is at 8.2.1, so I'm really asking if there's a roadmap/timeline for updates.] > > I write because I teach an introductory class in Haskell, and we've long used the Platform as a way to get the system up and running on the student's systems. I'm at a quarter school, but I have to think this is a sharp question for anyone trying to teach a Haskell course at a semester school. > > Is the Platform still the best way to do this? Will cabal continue to be a reasonable choice as default package manager? > > Thank you for your consideration. > > Peace, > > Stu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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. Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at adamflott.com Thu Aug 24 15:09:23 2017 From: adam at adamflott.com (Adam Flott) Date: Thu, 24 Aug 2017 11:09:23 -0400 Subject: [Haskell-cafe] Managing a sum type with a lot of constructors In-Reply-To: References: <20170823212935.22276466eb1b807c5ecdb8ef@adamflott.com> Message-ID: <20170824110923.7f8e66aeee9a2d7a468609e1@adamflott.com> My input I'm parsing into a data structure is URL query string like = and separated by a delimiter. Ultimately what I want back is of type `Data.Set.Set Text (v :: *)`. However I don't know how to represent that and don't want to build an HList like interface for it. On Wed, 23 Aug 2017 18:45:13 -0700 Michael Burge wrote: > If you have that many constructors, you probably aren't pattern-matching > against the whole thing everywhere. So you could extract the few functions > that use the entire type for case analysis into a typeclass, make each > constructor its own type, and implement the typeclass: > > Instead of: > > something :: A -> IO () > something A1 = putStrLn "hello" > something (A2 _) = putStrLn "world" > > Use: > > data A1 > data A2 = A2 Int > > class RelatedConst a of > something :: a -> IO () > > instance RelatedConst A1 where > something _ = putStrLn "hello" > > instance RelatedConst A2 where > something _ = putStrLn "world" > > Then, each declaration and instance could go in its own file. > > If on the other hand, you are using lots of partial case matches > everywhere, see if there are commonalities and extract a typeclass for each > group > > > On Wed, Aug 23, 2017 at 6:29 PM, Adam Flott wrote: > > > I have a sum type with a lot of constructors and I'm not sure how to > > represent > > the type with maintainability in mind. For example, > > > > data A = A1 > > | A2 Int > > | A3 Text Int32 Bool > > | ... > > | A100 Bool > > > > Every inner type is concrete. There are 100+ constructors with no sign of > > ever > > getting reduced. > > > > What technique would you recommend to keep the sum type approach but not > > having > > to define them all in one spot? I'm thinking 1 inner type + 1 function to > > construct per file (if that's possible). > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. -- From mail at joachim-breitner.de Thu Aug 24 16:03:08 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 24 Aug 2017 18:03:08 +0200 Subject: [Haskell-cafe] GHC fails to fuse [1 .. 30000000 :: Double] but fuses fromIntegral <$> [1 :: Int .. 30000000]? In-Reply-To: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> References: <82e829a0-0d7c-e0b0-b6fd-04eca0506d20@fuuzetsu.co.uk> Message-ID: <1503590588.10213.1.camel@joachim-breitner.de> Hi, fusion can only happen when the appropriate rewrite rules have been defined in the library. For Int, that is the case: http://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Enum.html#line-457 But the enumeration for general numeric types, defined here: http://hackage.haskell.org/package/base-4.10.0.0/docs/src/GHC.Real.html#numericEnumFrom does not have such a setup. Presumably it could be added, but enumerating doubles is bad style anyways; see https://ghc.haskell.org/trac/ghc/ticket/8012 Greetings, Joachim Am Mittwoch, den 23.08.2017, 14:00 +0100 schrieb Mateusz Kowalczyk: > Hi, > > I had few minutes timeout waiting for CI today and I stumbled upon [1]. > This is a many years old question and the optimal solution given there > was using Vector. I thought that for such a problem it should not be > necessary at all. > > Indeed I wrote `mean :: [Int] -> Int` and got a much faster solution. > However the original signature was `mean :: [Double] -> Int`. After > trivial changes (change couple of places to Double and add a single > fromIntegral) I expected the same result: after all, code is nearly > exactly the same. > > However to my disappointment, the code in question was much slower than > the vector solution: how could this be? Looking in Core, I saw that GHC > was not getting rid of [Double] like it was with [Int]. I was able to > convince GHC to go back to fusing the list into the worker with a `map > fromIntegral` but I am unhappy: why is this needed? I don't understand > why GHC would not decide to fuse the initial attempt. Honestly it seems > like a bug to me. > > What are your thoughts? For reference here is the core with > fromIntegral: as expected, GHC fuses the list and inserts int2Double# as > it's generating it: > > ``` > Main.$wgo = >   \ (w_s5xT :: GHC.Prim.Int#) >     (ww_s5xX :: GHC.Prim.Int#) >     (ww1_s5xY :: GHC.Prim.Double#) -> >     case w_s5xT of wild_Xz { >       __DEFAULT -> >         Main.$wgo >           (GHC.Prim.+# wild_Xz 1#) >           (GHC.Prim.+# ww_s5xX 1#) >           (GHC.Prim.+## ww1_s5xY (GHC.Prim.int2Double# wild_Xz)); >       30000000# -> >         (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) >     } > ``` > > Contrast this with version that's commented out in [2]: > > ``` > Main.$wgo = >   \ (w_s5vE :: [Double]) >     (ww_s5vI :: GHC.Prim.Int#) >     (ww1_s5vJ :: GHC.Prim.Double#) -> >     case w_s5vE of _ [Occ=Dead] { >       [] -> (# ww_s5vI, ww1_s5vJ #); >       : y_a3dU ys_a3dV -> >         case y_a3dU of _ [Occ=Dead] { GHC.Types.D# y1_a3dG -> >         Main.$wgo >           ys_a3dV (GHC.Prim.+# ww_s5vI 1#) (GHC.Prim.+## ww1_s5vJ y1_a3dG) >         } >     } > > … > >     case Main.$wgo Main.main3 0# 0.0## > … > Main.main3 = >   GHC.Real.numericEnumFromTo >     @ Double >     GHC.Classes.$fOrdDouble >     GHC.Float.$fFractionalDouble >     Main.main5 >     Main.main4 > … > Main.main4 = GHC.Types.D# 3.0e7## > … > Main.main5 = GHC.Types.D# 1.0## > ``` > > Why? There should be nothing stopping it from doing > > ``` > > Main.$wgo = >   \ (w_s5xT :: GHC.Prim.Double#) >     (ww_s5xX :: GHC.Prim.Int#) >     (ww1_s5xY :: GHC.Prim.Double#) -> >     case w_s5xT of wild_Xz { >       __DEFAULT -> >         Main.$wgo >           (GHC.Prim.+# wild_Xz 1#) >           (GHC.Prim.+# ww_s5xX 1#) >           (GHC.Prim.+## ww1_s5xY wild_Xz); >       3.0e7## -> >         (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) > ``` > > Perhaps it's afraid to make the pattern match on a floating point number? > > Insights welcome. > > > [1]: > https://stackoverflow.com/questions/3300995/computing-the-mean-of-a-list-efficiently-in-haskell/45840148 > [2]: https://stackoverflow.com/a/45840148/1432740 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -- Joachim “nomeata” Breitner mail at joachim-breitner.de https://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mjt464 at gmail.com Thu Aug 24 21:12:10 2017 From: mjt464 at gmail.com (mike thomas) Date: Fri, 25 Aug 2017 07:12:10 +1000 Subject: [Haskell-cafe] Haskell Platform In-Reply-To: References: <6CE2BA06-D43F-4907-BF65-C7FBC7202BCC@cs.uchicago.edu> Message-ID: Re the primary school kids using Haskell, that is amazing Harendra. Well done. I wonder what Alan Kay and his team would think - Haskell is the new Smalltalk! On 24 Aug 2017 11:27 am, "Harendra Kumar" wrote: Hi Stuart, I am not sure if there is a unanimous preferred way of installing Haskell. I guess the answer depends on who you ask. My preferred choice is "stack". I am no university prof or a school teacher but I do teach Haskell to my 6th grader and 2nd grader kids. I gave them a laptop (Mac OS) and told them how to install "stack" and they did it in a jiffy. They have been using it for several months with no complaints whatsoever. If little kids can do it I guess it should not be a problem for univ students. I have also been using stack myself for my professional work and it resonates well with my own thinking of how a package (and language tools) manager should behave. Additionally the stack team is very responsive if you want to get something fixed. When I started learning Haskell a few years ago I really enjoyed contributing to stack thanks to Michael Sloan's quick responses and encouraging feedback on the PRs. -harendra On 23 August 2017 at 22:16, Stuart A. Kurtz wrote: > Dear Colleagues, > > What's the status of the Haskell Platform? Is it still the/a preferred way > to install a working Haskell system? What is the update status of the > Platform? [I note that the platform is at 8.0.2, whereas GHC is at 8.2.1, > so I'm really asking if there's a roadmap/timeline for updates.] > > I write because I teach an introductory class in Haskell, and we've long > used the Platform as a way to get the system up and running on the > student's systems. I'm at a quarter school, but I have to think this is a > sharp question for anyone trying to teach a Haskell course at a semester > school. > > Is the Platform still the best way to do this? Will cabal continue to be a > reasonable choice as default package manager? > > Thank you for your consideration. > > Peace, > > Stu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Thu Aug 24 22:19:16 2017 From: gershomb at gmail.com (Gershom B) Date: Thu, 24 Aug 2017 17:19:16 -0500 Subject: [Haskell-cafe] Announce: Haskell Platform 8.2.1 Message-ID: On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.2.1 Now available at https://www.haskell.org/platform/ This includes GHC 8.2.1, cabal-install 2.0.0.0, and stack 1.5.1, all with many bugfixes and improvements since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. Due to GHC bug #14081 (https://ghc.haskell.org/trac/ghc/ticket/14081), we do not have Win32 builds in this release. We anticipate resuming support for Win32 once the current issues with GHC on Win32 are fixed in the next release. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.0.0.0/changelog (note the support for the Backpack module system, as described at: https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst) The cabal documentation page is at: https://cabal.readthedocs.io/en/latest/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/ The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom (Note -- one feature we still have not implemented yet for the platform but would like to is a generic linux installer that allows one to set a custom location and does not require root. Anyone who would like to volunteer to help with this, please get in touch!) From hyangfji at gmail.com Fri Aug 25 02:35:35 2017 From: hyangfji at gmail.com (Hong Yang) Date: Thu, 24 Aug 2017 21:35:35 -0500 Subject: [Haskell-cafe] Announce: Haskell Platform 8.2.1 In-Reply-To: References: Message-ID: Putting it at the top so people do not miss it. Wish it goes like a dream! (Note -- one feature we still have not implemented yet for the platform but would like to is a generic linux installer that allows one to set a custom location and does not require root. Anyone who would like to volunteer to help with this, please get in touch!) On Thu, Aug 24, 2017 at 5:19 PM, Gershom B wrote: > On behalf of the Haskell Platform team, I'm happy to announce the release > of > > Haskell Platform 8.2.1 > > Now available at > > https://www.haskell.org/platform/ > > This includes GHC 8.2.1, cabal-install 2.0.0.0, and stack 1.5.1, all > with many bugfixes and improvements since the last platform release. > > A full list of contents is available at > https://www.haskell.org/platform/contents.html > > Thanks to all the contributors to this release, thanks to all the > package and tool maintainers and authors, and a big thanks to the GHC > team for all their hard work. > > Due to GHC bug #14081 (https://ghc.haskell.org/trac/ghc/ticket/14081), > we do not have Win32 builds in this release. We anticipate resuming > support for Win32 once the current issues with GHC on Win32 are fixed > in the next release. > > A list of new GHC changes is available at: > https://ghc.haskell.org/trac/ghc/blog/ghc-8.2.11-released > > A list of cabal changes is available at: > https://hackage.haskell.org/package/cabal-install-2.0.0.0/changelog > > (note the support for the Backpack module system, as described at: > https://github.com/ezyang/ghc-proposals/blob/backpack/ > proposals/0000-backpack.rst) > > The cabal documentation page is at: > https://cabal.readthedocs.io/en/latest/ > > A list of stack changes is at: > https://docs.haskellstack.org/en/stable/ChangeLog/ > > The stack documentation page is at: > https://docs.haskellstack.org/en/stable/README/ > > Happy Haskell Hacking all, > Gershom > > (Note -- one feature we still have not implemented yet for the platform but > would like to is a generic linux installer that allows one to set a > custom location and does not require root. Anyone who would like to > volunteer to help with this, please get in touch!) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Fri Aug 25 03:26:22 2017 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Fri, 25 Aug 2017 11:26:22 +0800 Subject: [Haskell-cafe] megaparsec 6 migration Message-ID: I'm trying to migrate my codebase from megaparsec 5 to megaparsec 6. There appears to be major changes. For example, Text.Megaparsec.String.Parser & Text.Megaparsec.Error.Dec have both disappeared. I'm sure I could slowly plod through the new documentation, figure out the types and figure out how to migrate the code on my own, but examples & tutorials would be more time-efficient. Are there examples or tutorials compatible with megaparsec 6? For a start, what should I do with the above two things that have 'disappeared'? What do I replace them with? Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Fri Aug 25 03:48:47 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 24 Aug 2017 20:48:47 -0700 Subject: [Haskell-cafe] how would I do this properly in Haskell? Message-ID: I have a problem which I can solve with OO organization, but I want to know how to do it properly in Haskell. I have a search optimization problem in which there are a lot of individual fitness functions which combine scores to give an overall fitness level. Each fitness function will be associated with data, both initial data to configure it, and a cache that it maintains. So I could have something like this: data Fitness = Fit1 SomeData1 | Fit2 SomeData2 | Fit3 SomeData3 -- this function would evaluate the fitness of a particular -- result of type 'S' (in my case, a partially-constructed -- musical composition) evaluate :: Fitness -> S -> (Fitness,Double) -- something like this would have to be written for -- every sub-type of "Fitness" evaluate (Fit1 d) s = (Fit1 d',v) where (d',v) = evaluate1 d s evaluate1 :: SomeData1 -> S -> (SomeData1,Double) Is there a better way to do this? D -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnw at newartisans.com Fri Aug 25 04:13:21 2017 From: johnw at newartisans.com (John Wiegley) Date: Thu, 24 Aug 2017 21:13:21 -0700 Subject: [Haskell-cafe] how would I do this properly in Haskell? In-Reply-To: (Dennis Raddle's message of "Thu, 24 Aug 2017 20:48:47 -0700") References: Message-ID: >>>>> "DR" == Dennis Raddle writes: DR> I have a search optimization problem in which there are a lot of DR> individual fitness functions which combine scores to give an overall DR> fitness level. DR> Each fitness function will be associated with data, both initial data to DR> configure it, and a cache that it maintains. This sounds a lot like a network of Moore machines, which could be combined monoidally to arrive at the final fitness function. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From dennis.raddle at gmail.com Fri Aug 25 05:12:04 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 24 Aug 2017 22:12:04 -0700 Subject: [Haskell-cafe] how would I do this properly in Haskell? In-Reply-To: References: Message-ID: I'm an advanced beginner, and I'm finding it hard to comprehend Data.Machine.Moore. Is there a way to explain more to me how this would look in practice? Or is there another way to organize it that is less "computer-sciency" and I could work with more easily? D On Thu, Aug 24, 2017 at 9:13 PM, John Wiegley wrote: > >>>>> "DR" == Dennis Raddle writes: > > DR> I have a search optimization problem in which there are a lot of > DR> individual fitness functions which combine scores to give an overall > DR> fitness level. > > DR> Each fitness function will be associated with data, both initial data > to > DR> configure it, and a cache that it maintains. > > This sounds a lot like a network of Moore machines, which could be combined > monoidally to arrive at the final fitness function. > > -- > 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 johnw at newartisans.com Fri Aug 25 05:30:56 2017 From: johnw at newartisans.com (John Wiegley) Date: Thu, 24 Aug 2017 22:30:56 -0700 Subject: [Haskell-cafe] how would I do this properly in Haskell? In-Reply-To: (Dennis Raddle's message of "Thu, 24 Aug 2017 22:12:04 -0700") References: Message-ID: >>>>> "DR" == Dennis Raddle writes: DR> I'm an advanced beginner, and I'm finding it hard to comprehend DR> Data.Machine.Moore. Is there a way to explain more to me how this would DR> look in practice? Or is there another way to organize it that is less DR> "computer-sciency" and I could work with more easily? Thinks of a Moore machine as a packaged up State function, where you have an initial state, and the type of that state is hidden within the machine. For example: {-# LANGUAGE ExistentialQuantification #-} data Moore i m o = forall s. Moore { mooreInit :: s , mooreFunc :: i -> StateT s m o } This machine is really just a packaged function, yielding outputs from inputs, while dependent on an internal state that may vary at each call. Since the state is "existential" (or private to Moore), it can be changed freely when you combine machines: instance (Monad m, Monoid o) => Monoid (Moore i m o) where mempty = Moore () (const (return mempty)) Moore s1 f1 `mappend` Moore s2 f2 = Moore (s1, s2) go where go ev = StateT $ \(st1, st2) -> do (mres, st1') <- runStateT (f1 ev) st1 (mres', st2') <- runStateT (f2 ev) st2 return (mres <> mres', (st1', st2')) Something like this could serve your needs, without needing an external package like 'machines'. I've used it to do almost just what you described initially. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 From dennis.raddle at gmail.com Fri Aug 25 05:33:02 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 24 Aug 2017 22:33:02 -0700 Subject: [Haskell-cafe] how would I do this properly in Haskell? In-Reply-To: References: Message-ID: Thanks very much! I'll look at it in detail. D On Thu, Aug 24, 2017 at 10:30 PM, John Wiegley wrote: > >>>>> "DR" == Dennis Raddle writes: > > DR> I'm an advanced beginner, and I'm finding it hard to comprehend > DR> Data.Machine.Moore. Is there a way to explain more to me how this would > DR> look in practice? Or is there another way to organize it that is less > DR> "computer-sciency" and I could work with more easily? > > Thinks of a Moore machine as a packaged up State function, where you have > an > initial state, and the type of that state is hidden within the machine. > For > example: > > {-# LANGUAGE ExistentialQuantification #-} > > data Moore i m o = forall s. Moore > { mooreInit :: s > , mooreFunc :: i -> StateT s m o > } > > This machine is really just a packaged function, yielding outputs from > inputs, > while dependent on an internal state that may vary at each call. > > Since the state is "existential" (or private to Moore), it can be changed > freely when you combine machines: > > instance (Monad m, Monoid o) => Monoid (Moore i m o) where > mempty = Moore () (const (return mempty)) > Moore s1 f1 `mappend` Moore s2 f2 = Moore (s1, s2) go > where > go ev = StateT $ \(st1, st2) -> do > (mres, st1') <- runStateT (f1 ev) st1 > (mres', st2') <- runStateT (f2 ev) st2 > return (mres <> mres', (st1', st2')) > > Something like this could serve your needs, without needing an external > package like 'machines'. I've used it to do almost just what you described > initially. > > -- > 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 me at ara.io Fri Aug 25 08:19:35 2017 From: me at ara.io (Ara Adkins) Date: Fri, 25 Aug 2017 09:19:35 +0100 Subject: [Haskell-cafe] megaparsec 6 migration In-Reply-To: References: Message-ID: Hey Josh, I found it pretty useful to just have a read of the changelog [1] when migrating from Megaparsec 5 to 6. I don’t know of any in-depth updated tutorials, but if you’re familiar enough with Megaparsec the changelog should provide the detail you need. It took me around an hour to update a serious parser that I maintain, so the changes aren’t overly inconvenient. I hope that helps. _ara [1] https://github.com/mrkkrp/megaparsec/blob/master/CHANGELOG.md > On 25 Aug 2017, at 04:26, ☂Josh Chia (謝任中) wrote: > > I'm trying to migrate my codebase from megaparsec 5 to megaparsec 6. > > There appears to be major changes. For example, Text.Megaparsec.String.Parser & Text.Megaparsec.Error.Dec have both disappeared. > > I'm sure I could slowly plod through the new documentation, figure out the types and figure out how to migrate the code on my own, but examples & tutorials would be more time-efficient. > > Are there examples or tutorials compatible with megaparsec 6? For a start, what should I do with the above two things that have 'disappeared'? What do I replace them with? > > Josh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Sun Aug 27 20:48:26 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Sun, 27 Aug 2017 16:48:26 -0400 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! Message-ID: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> https://hackage.haskell.org/package/haddock now puts the whole cheatsheet up front. Well done! Bravo! Whoever thought up this is a genius! Thanks! From migmit at gmail.com Sun Aug 27 21:12:36 2017 From: migmit at gmail.com (MigMit) Date: Sun, 27 Aug 2017 23:12:36 +0200 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> Message-ID: <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> Bravo indeed. > On 27 Aug 2017, at 22:48, Albert Y. C. Lai wrote: > > https://hackage.haskell.org/package/haddock now puts the whole cheatsheet up front. Well done! Bravo! Whoever thought up this is a genius! 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-08-27 at 23.10.57.png Type: image/png Size: 362718 bytes Desc: not available URL: From timmelzer at gmail.com Sun Aug 27 21:20:10 2017 From: timmelzer at gmail.com (Norbert Melzer) Date: Sun, 27 Aug 2017 21:20:10 +0000 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> Message-ID: MigMit schrieb am So., 27. Aug. 2017 um 23:15 Uhr: > Bravo indeed. > > [image: Screen Shot 2017-08-27 at 23.10.57.png] > × > Not quite sure whats happening here for you, but for me it is a prerendered image… > On 27 Aug 2017, at 22:48, Albert Y. C. Lai wrote: > > https://hackage.haskell.org/package/haddock now puts the whole cheatsheet > up front. Well done! Bravo! Whoever thought up this is a genius! 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. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: Screen Shot 2017-08-27 at 23.10.57.png Type: image/png Size: 362718 bytes Desc: not available URL: From ivan.miljenovic at gmail.com Mon Aug 28 01:01:12 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 28 Aug 2017 11:01:12 +1000 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> Message-ID: On 28 August 2017 at 07:20, Norbert Melzer wrote: > > MigMit schrieb am So., 27. Aug. 2017 um 23:15 Uhr: > >> Bravo indeed. >> >> [image: Screen Shot 2017-08-27 at 23.10.57.png] >> × >> > > Not quite sure whats happening here for you, but for me it is a > prerendered image… > Whereas for me I've got the "broken image link" icon, but if I right-click it and say to view image it works. Possibly browser-specific? (I'm using Firefox) > On 27 Aug 2017, at 22:48, Albert Y. C. Lai wrote: >> >> https://hackage.haskell.org/package/haddock now puts the whole >> cheatsheet up front. Well done! Bravo! Whoever thought up this is a genius! >> 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. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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. > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-08-27 at 23.10.57.png Type: image/png Size: 362718 bytes Desc: not available URL: From sanghak at andychun.info Mon Aug 28 01:10:36 2017 From: sanghak at andychun.info (Sang Hak (Andy) Chun) Date: Sun, 27 Aug 2017 18:10:36 -0700 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> Message-ID: <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> The cheat sheet is an embedded SVG, it seems. Perhaps the browser isn't playing nice with vector graphics? - Andy On 08/27/2017 06:01 PM, Ivan Lazar Miljenovic wrote: > On 28 August 2017 at 07:20, Norbert Melzer > wrote: > > > MigMit > schrieb am > So., 27. Aug. 2017 um 23:15 Uhr: > > Bravo indeed. > > Screen Shot 2017-08-27 at 23.10.57.png > × > > > Not quite sure whats happening here for you, but for me it is a > prerendered image… > > > Whereas for me I've got the "broken image link" icon, but if I > right-click it and say to view image it works. > > Possibly browser-specific? (I'm using Firefox) > >> On 27 Aug 2017, at 22:48, Albert Y. C. Lai > > wrote: >> >> https://hackage.haskell.org/package/haddock >> now puts the >> whole cheatsheet up front. Well done! Bravo! Whoever thought >> up this is a genius! 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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. > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-08-27 at 23.10.57.png Type: image/png Size: 362718 bytes Desc: not available URL: From jo at durchholz.org Mon Aug 28 05:25:46 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 28 Aug 2017 07:25:46 +0200 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: Am 28.08.2017 um 03:10 schrieb Sang Hak (Andy) Chun: > The cheat sheet is an embedded SVG, it seems. It definitely is, I just checked the raw data. The first line has this to say: > Perhaps the browser isn't > playing nice with vector graphics? I see that XY positioning uses dimensionless numbers, while font sizes are given in pixels. If the browser interprets the XY values as something different than pixels, this would explain what migmit is seeing. I don't know whether the SVG or the browser is wrong. From tomas.carnecky at gmail.com Mon Aug 28 05:48:20 2017 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Mon, 28 Aug 2017 05:48:20 +0000 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: The SVG looks ok. Please include the browser version you're using. On Mon, Aug 28, 2017 at 7:27 AM Joachim Durchholz wrote: > Am 28.08.2017 um 03:10 schrieb Sang Hak (Andy) Chun: > > The cheat sheet is an embedded SVG, it seems. > > It definitely is, I just checked the raw data. > The first line has this to say: > > > > > Perhaps the browser isn't > > playing nice with vector graphics? > > I see that XY positioning uses dimensionless numbers, while font sizes > are given in pixels. If the browser interprets the XY values as > something different than pixels, this would explain what migmit is seeing. > I don't know whether the SVG or the browser is wrong. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lemming at henning-thielemann.de Mon Aug 28 06:31:51 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Aug 2017 08:31:51 +0200 (CEST) Subject: [Haskell-cafe] undefined reference to '__gxx_personality_v0' Message-ID: I have trouble to compile my llvm-ffi package containing C++ binding code. I am on Ubuntu 16.04 and I have created a custom llvm.pc file: $ cat /usr/local/lib/pkgconfig/llvm-3.8.pc Name: LLVM Description: Low-level Virtual Machine compiler framework Version: 3.8.0 URL: http://www.llvm.org/ Requires: Conflicts: Libs: -L/usr/lib/llvm-3.8/lib -lLLVM-3.8.0 Cflags: -I/usr/lib/llvm-3.8/include -std=c++0x -std=c++11 /tmp$ cabal unpack llvm-ffi Unpacking to llvm-ffi-3.8.1/ /tmp$ cd llvm-ffi-3.8.1/ /tmp/llvm-ffi-3.8.1$ cabal configure -fbuildExamples --with-ghc=ghc-8.2.1 Resolving dependencies... Configuring llvm-ffi-3.8.1... /tmp/llvm-ffi-3.8.1$ cabal build Preprocessing library for llvm-ffi-3.8.1.. cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C Building library for llvm-ffi-3.8.1.. [ 1 of 22] Compiling LLVM.FFI.Core ( dist/build/LLVM/FFI/Core.hs, dist/build/LLVM/FFI/Core.o ) [ 2 of 22] Compiling LLVM.FFI.BitWriter ( src/LLVM/FFI/BitWriter.hs, dist/build/LLVM/FFI/BitWriter.o ) [ 3 of 22] Compiling LLVM.FFI.BitReader ( src/LLVM/FFI/BitReader.hs, dist/build/LLVM/FFI/BitReader.o ) [ 4 of 22] Compiling LLVM.FFI.Analysis ( src/LLVM/FFI/Analysis.hs, dist/build/LLVM/FFI/Analysis.o ) ... Preprocessing executable 'llvm-ffi-example' for llvm-ffi-3.8.1.. Building executable 'llvm-ffi-example' for llvm-ffi-3.8.1.. [1 of 1] Compiling Main ( example/JIT.hs, dist/build/llvm-ffi-example/llvm-ffi-example-tmp/Main.o ) Linking dist/build/llvm-ffi-example/llvm-ffi-example ... /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMGetHostFeatures: error: undefined reference to 'operator new(unsigned long)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMGetHostFeatures: error: undefined reference to 'operator delete(void*)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMCheckFeature(llvm::StringMap*, llvm::StringMapConstIterator*): error: undefined reference to 'operator delete(void*)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMGetFirstFeature: error: undefined reference to 'operator new(unsigned long)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to 'operator delete(void*)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to 'std::__cxx11::basic_string, std::allocator >::_M_replace(unsigned long, unsigned long, char const*, unsigned long)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to 'operator delete(void*)' /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:DW.ref.__gxx_personality_v0: error: undefined reference to '__gxx_personality_v0' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) StackOverflow discussions on those linker errors suggest that it is important to link with g++, not gcc. Can I control how GHC links? How do other packages cope with C++ code? It seems that they most oftenly come with custom Setup modules that cause trouble with different Cabal versions. I hoped that I can prevent those difficulties using pkg-config. Unfortunately, pkg-config seems to be limited to C libraries. Thus the warnings about the -std=c++11 option in the beginning. Maybe it is cleaner to write a separate LLVM C package that interfaces to the C++ code and bind Haskell to C via pkg-config. However, it would mean that I have to maintain a C library for Linux, Mac and Windows with autoconf et.al. From migmit at gmail.com Mon Aug 28 07:38:23 2017 From: migmit at gmail.com (MigMit) Date: Mon, 28 Aug 2017 09:38:23 +0200 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: Latest Firefox on the latest Mac OS X. But using SVG for what is mostly text is not a good idea anyway. > On 28 Aug 2017, at 07:48, Tomas Carnecky wrote: > > The SVG looks ok. Please include the browser version you're using. > > On Mon, Aug 28, 2017 at 7:27 AM Joachim Durchholz wrote: > Am 28.08.2017 um 03:10 schrieb Sang Hak (Andy) Chun: > > The cheat sheet is an embedded SVG, it seems. > > It definitely is, I just checked the raw data. > The first line has this to say: > > > > > Perhaps the browser isn't > > playing nice with vector graphics? > > I see that XY positioning uses dimensionless numbers, while font sizes > are given in pixels. If the browser interprets the XY values as > something different than pixels, this would explain what migmit is seeing. > I don't know whether the SVG or the browser is wrong. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 tomas.carnecky at gmail.com Mon Aug 28 08:03:11 2017 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Mon, 28 Aug 2017 08:03:11 +0000 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: I can't reproduce it with Firefox 55.0.3 on Mac. Tried playing with zoom and font sizes in the Firefox settings but didn't make any difference. I disagree that SVG is not a good idea. It's as good as HTML for text. However if this problem you're seeing is a real issue for end users we could generate a raster image from the SVG (possibly at @2x/@3x resolution) and insert that into the webpage. On Mon, Aug 28, 2017 at 9:38 AM MigMit wrote: > Latest Firefox on the latest Mac OS X. > > But using SVG for what is mostly text is not a good idea anyway. > > > On 28 Aug 2017, at 07:48, Tomas Carnecky > wrote: > > > > The SVG looks ok. Please include the browser version you're using. > > > > On Mon, Aug 28, 2017 at 7:27 AM Joachim Durchholz > wrote: > > Am 28.08.2017 um 03:10 schrieb Sang Hak (Andy) Chun: > > > The cheat sheet is an embedded SVG, it seems. > > > > It definitely is, I just checked the raw data. > > The first line has this to say: > > > > > > > > > Perhaps the browser isn't > > > playing nice with vector graphics? > > > > I see that XY positioning uses dimensionless numbers, while font sizes > > are given in pixels. If the browser interprets the XY values as > > something different than pixels, this would explain what migmit is > seeing. > > I don't know whether the SVG or the browser is wrong. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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 lemming at henning-thielemann.de Mon Aug 28 10:11:15 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 28 Aug 2017 12:11:15 +0200 (CEST) Subject: [Haskell-cafe] undefined reference to '__gxx_personality_v0' In-Reply-To: References: Message-ID: On Mon, 28 Aug 2017, Henning Thielemann wrote: > StackOverflow discussions on those linker errors suggest that it is important > to link with g++, not gcc. Can I control how GHC links? Adding ghc-options: -pgmlg++ to the executable section seems to help. However, it means I will have to add this option to all executables that will use the llvm-ffi package. :-( From moritz.kiefer at purelyfunctional.org Mon Aug 28 10:23:09 2017 From: moritz.kiefer at purelyfunctional.org (Moritz Kiefer) Date: Mon, 28 Aug 2017 12:23:09 +0200 Subject: [Haskell-cafe] undefined reference to '__gxx_personality_v0' In-Reply-To: References: Message-ID: Hey Henning, Try linking against `libstdc++` by adding it to `extra-libraries`. If you care about cross-plattform compatiblity you will also need to make sure that you use the same C++ stdlib that LLVM was linked against (e.g. on macOS it’s libc++). `llvm-config --cxxflags` should help with that. Moritz On 08/28/2017 08:31 AM, Henning Thielemann wrote: > > I have trouble to compile my llvm-ffi package containing C++ binding > code. I am on Ubuntu 16.04 and I have created a custom llvm.pc file: > > $ cat /usr/local/lib/pkgconfig/llvm-3.8.pc > Name: LLVM > Description: Low-level Virtual Machine compiler framework > Version: 3.8.0 > URL: http://www.llvm.org/ > Requires: > Conflicts: > Libs: -L/usr/lib/llvm-3.8/lib -lLLVM-3.8.0 > Cflags: -I/usr/lib/llvm-3.8/include -std=c++0x -std=c++11 > > /tmp$ cabal unpack llvm-ffi > Unpacking to llvm-ffi-3.8.1/ > /tmp$ cd llvm-ffi-3.8.1/ > /tmp/llvm-ffi-3.8.1$ cabal configure -fbuildExamples --with-ghc=ghc-8.2.1 > Resolving dependencies... > Configuring llvm-ffi-3.8.1... > /tmp/llvm-ffi-3.8.1$ cabal build > Preprocessing library for llvm-ffi-3.8.1.. > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ > but not for C > Building library for llvm-ffi-3.8.1.. > [ 1 of 22] Compiling LLVM.FFI.Core ( dist/build/LLVM/FFI/Core.hs, > dist/build/LLVM/FFI/Core.o ) > [ 2 of 22] Compiling LLVM.FFI.BitWriter ( src/LLVM/FFI/BitWriter.hs, > dist/build/LLVM/FFI/BitWriter.o ) > [ 3 of 22] Compiling LLVM.FFI.BitReader ( src/LLVM/FFI/BitReader.hs, > dist/build/LLVM/FFI/BitReader.o ) > [ 4 of 22] Compiling LLVM.FFI.Analysis ( src/LLVM/FFI/Analysis.hs, > dist/build/LLVM/FFI/Analysis.o ) > ... > Preprocessing executable 'llvm-ffi-example' for llvm-ffi-3.8.1.. > Building executable 'llvm-ffi-example' for llvm-ffi-3.8.1.. > [1 of 1] Compiling Main ( example/JIT.hs, > dist/build/llvm-ffi-example/llvm-ffi-example-tmp/Main.o ) > Linking dist/build/llvm-ffi-example/llvm-ffi-example ... > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMGetHostFeatures: error: undefined reference to 'operator > new(unsigned long)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMGetHostFeatures: error: undefined reference to 'operator delete(void*)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMCheckFeature(llvm::StringMap*, > llvm::StringMapConstIterator*): error: undefined reference to > 'operator delete(void*)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMGetFirstFeature: error: undefined reference to 'operator > new(unsigned long)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to > 'operator delete(void*)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to > 'std::__cxx11::basic_string, > std::allocator >::_M_replace(unsigned long, unsigned long, char > const*, unsigned long)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:function > LLVMCreateExecutionEngineKindForModuleCPU: error: undefined reference to > 'operator delete(void*)' > /tmp/llvm-ffi-3.8.1/dist/build/libHSllvm-ffi-3.8.1-KKUvbYcVYVe5ZjJKumuzkS.a(support.o):support.cpp:DW.ref.__gxx_personality_v0: > error: undefined reference to '__gxx_personality_v0' > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > > > StackOverflow discussions on those linker errors suggest that it is > important to link with g++, not gcc. Can I control how GHC links? > > How do other packages cope with C++ code? It seems that they most > oftenly come with custom Setup modules that cause trouble with different > Cabal versions. I hoped that I can prevent those difficulties using > pkg-config. Unfortunately, pkg-config seems to be limited to C > libraries. Thus the warnings about the -std=c++11 option in the beginning. > > Maybe it is cleaner to write a separate LLVM C package that interfaces > to the C++ code and bind Haskell to C via pkg-config. However, it would > mean that I have to maintain a C library for Linux, Mac and Windows with > autoconf et.al. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 833 bytes Desc: OpenPGP digital signature URL: From takenobu.hs at gmail.com Mon Aug 28 13:25:27 2017 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 28 Aug 2017 22:25:27 +0900 Subject: [Haskell-cafe] GHC 8.2's new ghci commands: `:type +d` and `:type +v` Message-ID: Dear cafe, GHC 8.2 supports two new ghci commands. They are `:type +d` and `:type +v` [1]. 0. normal `:type` command: Prelude> :type length length :: Foldable t => t a -> Int Prelude> :type ($) ($) :: (a -> b) -> a -> b 1. new `:type +d` command for newcomers: Prelude> :type +d length length :: [a] -> Int 2. new `:type +v` command for detail information: Prelude> :type +v ($) ($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r). (a -> b) -> a -> b That's excellent :) [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html#ghci-cmd-:type Regards, Takenobu -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Mon Aug 28 16:36:40 2017 From: zocca.marco at gmail.com (Marco Zocca) Date: Mon, 28 Aug 2017 18:36:40 +0200 Subject: [Haskell-cafe] Numerical / Data Special Interest Group at ICFP'17 Message-ID: Dear all, thanks to the ICFP organisers and to D.Steinitz (https://idontgetoutmuch.wordpress.com/) we will have a late-minute workshop on the numerical and data-related Haskell at ICFP'17 (Oxford) on Saturday 9th September in the slot 12:30 - 14:00. Looking forward to meeting you all there; Best, Marco Zocca https://github.com/ocramz From david.feuer at gmail.com Mon Aug 28 17:32:51 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 28 Aug 2017 13:32:51 -0400 Subject: [Haskell-cafe] Does the streaming package need a new/additional maintainer? Message-ID: The streaming package has a couple old pull requests that have not been commented on. My recently reported issues and pull requests have also met with silence. It appears that the maintainer, Michael Thompson, was last active on GitHub and Reddit in April. I emailed him a few days ago, but have not yet received a response. I hope he is just on a short break, but if not, someone should probably take over the package. David From jo at durchholz.org Mon Aug 28 17:41:50 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 28 Aug 2017 19:41:50 +0200 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: <95142266-1989-1a80-b8bc-41bacb4698c5@durchholz.org> Am 28.08.2017 um 09:38 schrieb MigMit: > But using SVG for what is mostly text is not a good idea anyway. Actually, it's the non-text parts that define what rendering solution is most appropriate. Each potential solution that I am aware of has its problems; afaik SVG is one of the least evils in this area. YMMV but I wouldn't disquality SVG as "not a good idea anyway". From trebla at vex.net Tue Aug 29 01:21:56 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Mon, 28 Aug 2017 21:21:56 -0400 Subject: [Haskell-cafe] Haddock's Hackage page --- Bravo! In-Reply-To: References: <83a66874-3edb-a7cf-ac3d-27a5001215d2@vex.net> <2E08E96F-248B-4C3B-86DC-CD497A09CFD1@gmail.com> <5983a0d9-d258-f5ec-6910-6ec2047eb26c@andychun.info> Message-ID: <0f9f8de7-f967-3bee-0ed6-39b79fbe3906@vex.net> On 2017-08-28 01:25 AM, Joachim Durchholz wrote: > I see that XY positioning uses dimensionless numbers, while font sizes > are given in pixels. If the browser interprets the XY values as > something different than pixels, this would explain what migmit is seeing. > I don't know whether the SVG or the browser is wrong. In SVG, lack of unit is taken to mean the px unit. So means the same thing as . Next, the fun part is the beginning which means: 1px horizontal means 8.5in/170 = 0.05in 1px vertical means 11in/220 = 0.05in Lastly, to be sure, a web browser is going to have its own twisted idea of what 1in means, but empirically desktop web browsers use the simpifying assumption 96dpi (configurable by poorly documented ways IIRC) so they're going to use 96 physical pixels per "1in". (Indeed, I have used 3 desktop monitors, including 1 CRT, during the last 20 years and they all did/do approximately 96dpi, and today I just tested an SVG of a 5in-by-5in square and it does measure almost 5 inches. To be sure, Apple products that boast "retina display" and Microsoft Surface Pro are another story, 220-400dpi.) So I think this SVG code is pretty robust to scaling. And real web browsers are actually pretty close to theory in this regard. From chneukirchen at gmail.com Tue Aug 29 19:08:36 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Tue, 29 Aug 2017 21:08:36 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2017-08-31 @ 19:30 Message-ID: <87tw0qchu3.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 31 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-aug-2017/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From jkb at jkbsc.co.uk Tue Aug 29 21:06:27 2017 From: jkb at jkbsc.co.uk (John Beattie) Date: Tue, 29 Aug 2017 22:06:27 +0100 Subject: [Haskell-cafe] To merge package documentation with the platform doc tree Message-ID: <20170829210627.GA27852@pabbay.hignfy.demon.co.uk> Hi, Suppose I download a package and install it. I would like to be able to have the html documentation for that package and I would like it to be integrated with the local doc tree in the haskell platform. Is this a recognised usecase and is there a recommended way to do that? My first thought was to use haddock but I haven't managed to work out if there is a combination of haddock options which would get me there. As an alternative, I was wondering about cloning the GHC platform source and pasting the new library into the source tree alongside the other libraries and building the documentation. I might have to tweak a makefile or somesuch but would that work? Thanks, John Beattie From fa-ml at ariis.it Tue Aug 29 21:29:50 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 29 Aug 2017 23:29:50 +0200 Subject: [Haskell-cafe] To merge package documentation with the platform doc tree In-Reply-To: <20170829210627.GA27852@pabbay.hignfy.demon.co.uk> References: <20170829210627.GA27852@pabbay.hignfy.demon.co.uk> Message-ID: <20170829212950.jsvkfgzk6sfbncex@x60s.casa> On Tue, Aug 29, 2017 at 10:06:27PM +0100, John Beattie wrote: > Hi, > > Suppose I download a package and install it. I would like to be able to have > the html documentation for that package and I would like it to be integrated > with the local doc tree in the haskell platform. > > Is this a recognised usecase and is there a recommended way to do that? > > My first thought was to use haddock but I haven't managed to work out if there > is a combination of haddock options which would get me there. > > As an alternative, I was wondering about cloning the GHC platform source and > pasting the new library into the source tree alongside the other libraries and > building the documentation. I might have to tweak a makefile or somesuch but > would that work? > > Thanks, > John Beattie Hello John, ah, my time to spam! http://ariis.it/static/articles/no-docs-hackage/page.html I bootstrap cabal (HP minimal?) and it works as written. I did not test it with HP full but I don't think it should have problems with that. Let me know if it does the trick -F From jake.waksbaum at gmail.com Wed Aug 30 02:20:54 2017 From: jake.waksbaum at gmail.com (Jake) Date: Wed, 30 Aug 2017 02:20:54 +0000 Subject: [Haskell-cafe] To merge package documentation with the platform doc tree In-Reply-To: <20170829212950.jsvkfgzk6sfbncex@x60s.casa> References: <20170829210627.GA27852@pabbay.hignfy.demon.co.uk> <20170829212950.jsvkfgzk6sfbncex@x60s.casa> Message-ID: Another way of doing this is by using Nix package manager. This section of the manual explains how to create a shell environment with a set of specified packages installed that includes a unified haddock documentation directory. On Tue, Aug 29, 2017 at 5:32 PM Francesco Ariis wrote: > On Tue, Aug 29, 2017 at 10:06:27PM +0100, John Beattie wrote: > > Hi, > > > > Suppose I download a package and install it. I would like to be able to > have > > the html documentation for that package and I would like it to be > integrated > > with the local doc tree in the haskell platform. > > > > Is this a recognised usecase and is there a recommended way to do that? > > > > My first thought was to use haddock but I haven't managed to work out if > there > > is a combination of haddock options which would get me there. > > > > As an alternative, I was wondering about cloning the GHC platform source > and > > pasting the new library into the source tree alongside the other > libraries and > > building the documentation. I might have to tweak a makefile or > somesuch but > > would that work? > > > > Thanks, > > John Beattie > > Hello John, > > ah, my time to spam! > > http://ariis.it/static/articles/no-docs-hackage/page.html > > I bootstrap cabal (HP minimal?) and it works as written. I did not test > it with HP full but I don't think it should have problems with that. > > Let me know if it does the trick > -F > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lemming at henning-thielemann.de Wed Aug 30 11:18:41 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 30 Aug 2017 13:18:41 +0200 (CEST) Subject: [Haskell-cafe] profiling of functions generated by LLVM Message-ID: I use LLVM to create sub-routines for efficient inner loops. I like to profile them. However, it seems that GHC's profiler does not interact well with such generated functions. Say, I have a function that creates an efficient subroutine for filling a block of data. It looks like the following: generateFill :: IO (Word64 -> Ptr Float -> IO ()) generateFill = generateFunction (LLVM code for traversing block) main :: IO () main = do let n = 100*10^6 fill <- generateFill allocaArray n $ \ptr -> {-# SCC fill #-} fill (fromIntegral n) ptr I run this with profiling. The resulting .prof report says, that 'generateFunction' demands all the computation time and 'fill' inherits it. fill Main 1297 1 0.0 0.0 99.9 0.0 generateFill Main 1298 0 0.0 0.0 99.9 0.0 generateFunction Main 1299 0 99.9 0.0 99.9 0.0 I have a rough idea why GHC treats the generated functions the way it does. However, it is pretty counter-intuitive and difficult to understand in more complex programs. From olf at aatal-apotheke.de Wed Aug 30 13:41:45 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 30 Aug 2017 15:41:45 +0200 (CEST) Subject: [Haskell-cafe] cabal file build-depends list sensitive to ordering Message-ID: <96410738.214345.1504100505652@webmail.strato.de> Dear cafe, I discovered that stack/cabal is sensitive to permutations in the dependencies list. Is that desired behaviour and documented anywhere? #File stack.yaml resolver: lts-9.2 packages: - '.' extra-deps: [iCalendar-0.4.0.3,mime-0.4.0.2,wx-0.92.3.0,wxcore-0.92.3.0,wxc-0.92.3.0,wxdirect-0.92.3.0] flags: {} extra-package-dbs: [] system-ghc: false # In file myproject.cabal build-depends: base >= 4.7 && < 5 , HaXml >= 1.13.3 , iCalendar >= 0.3.7.3 , containers , time >= 1.6.0.1 , text , case-insensitive , xslx , xlsx-tabular , wx "stack build" generates the rather uninformative error message In the dependencies for myproject-0.2.1.0: xslx must match -any, but the stack configuration has no specified version # In file myproject.cabal build-depends: base >= 4.7 && < 5 , xlsx , xlsx-tabular , HaXml >= 1.13.3 , iCalendar >= 0.3.7.3 , containers , time >= 1.6.0.1 , text , case-insensitive , wx This version builds just fine. -- Olaf From michael at snoyman.com Wed Aug 30 13:52:20 2017 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 30 Aug 2017 16:52:20 +0300 Subject: [Haskell-cafe] cabal file build-depends list sensitive to ordering In-Reply-To: <96410738.214345.1504100505652@webmail.strato.de> References: <96410738.214345.1504100505652@webmail.strato.de> Message-ID: Looks like a bug in Stack, can you open an issue on the issue tracker? On Wed, Aug 30, 2017 at 4:41 PM, Olaf Klinke wrote: > Dear cafe, > > I discovered that stack/cabal is sensitive to permutations in the > dependencies list. Is that desired behaviour and documented anywhere? > > #File stack.yaml > resolver: lts-9.2 > packages: > - '.' > extra-deps: [iCalendar-0.4.0.3,mime-0.4.0.2,wx-0.92.3.0,wxcore-0.92.3.0, > wxc-0.92.3.0,wxdirect-0.92.3.0] > flags: {} > extra-package-dbs: [] > system-ghc: false > > # In file myproject.cabal > build-depends: base >= 4.7 && < 5 > , HaXml >= 1.13.3 > , iCalendar >= 0.3.7.3 > , containers > , time >= 1.6.0.1 > , text > , case-insensitive > , xslx > , xlsx-tabular > , wx > > "stack build" generates the rather uninformative error message > In the dependencies for myproject-0.2.1.0: > xslx must match -any, but the stack configuration has no specified > version > > # In file myproject.cabal > build-depends: base >= 4.7 && < 5 > , xlsx > , xlsx-tabular > , HaXml >= 1.13.3 > , iCalendar >= 0.3.7.3 > , containers > , time >= 1.6.0.1 > , text > , case-insensitive > , wx > > This version builds just fine. > -- Olaf > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Wed Aug 30 13:56:08 2017 From: michael at snoyman.com (Michael Snoyman) Date: Wed, 30 Aug 2017 16:56:08 +0300 Subject: [Haskell-cafe] cabal file build-depends list sensitive to ordering In-Reply-To: References: <96410738.214345.1504100505652@webmail.strato.de> Message-ID: Scratch that, I'm just dyslexic. It's the difference between: xslx and xlsx On Wed, Aug 30, 2017 at 4:52 PM, Michael Snoyman wrote: > Looks like a bug in Stack, can you open an issue on the issue tracker? > > On Wed, Aug 30, 2017 at 4:41 PM, Olaf Klinke > wrote: > >> Dear cafe, >> >> I discovered that stack/cabal is sensitive to permutations in the >> dependencies list. Is that desired behaviour and documented anywhere? >> >> #File stack.yaml >> resolver: lts-9.2 >> packages: >> - '.' >> extra-deps: [iCalendar-0.4.0.3,mime-0.4.0.2,wx-0.92.3.0,wxcore-0.92.3.0, >> wxc-0.92.3.0,wxdirect-0.92.3.0] >> flags: {} >> extra-package-dbs: [] >> system-ghc: false >> >> # In file myproject.cabal >> build-depends: base >= 4.7 && < 5 >> , HaXml >= 1.13.3 >> , iCalendar >= 0.3.7.3 >> , containers >> , time >= 1.6.0.1 >> , text >> , case-insensitive >> , xslx >> , xlsx-tabular >> , wx >> >> "stack build" generates the rather uninformative error message >> In the dependencies for myproject-0.2.1.0: >> xslx must match -any, but the stack configuration has no specified >> version >> >> # In file myproject.cabal >> build-depends: base >= 4.7 && < 5 >> , xlsx >> , xlsx-tabular >> , HaXml >= 1.13.3 >> , iCalendar >= 0.3.7.3 >> , containers >> , time >= 1.6.0.1 >> , text >> , case-insensitive >> , wx >> >> This version builds just fine. >> -- Olaf >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From palotai.robin at gmail.com Thu Aug 31 05:41:47 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 31 Aug 2017 07:41:47 +0200 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available Message-ID: To find out who else uses your favorite functions and how: http://stuff.codereview.me/lts/9.2 . For example, click 'async' at http://stuff.codereview.me/lts/9.2/#async-2.1.1.1/Control/Concurrent/Async.hs?corpus&signature&line=175 to get all the callsites of that method. There are additional files available at http://stuff.codereview.me/ if you want to serve the xrefs locally, or merge your own packages into the index (assuming you use the same stackage lts version). A request: the crossreferencing is pretty usable, but far from complete. If you find any issues (missing crossreferences or bad ones), please have a look at the buglist at https://github.com/google/haskell-indexer/issues, and thumbs-up any that you find hurting, or open new ones! Thank you & happy code browsing, Robin -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Aug 31 08:33:31 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 31 Aug 2017 11:33:31 +0300 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: Message-ID: I don't have anything useful to contribute, but just wanted to say: this is really cool, thank you! On Thu, Aug 31, 2017 at 8:41 AM, Robin Palotai wrote: > To find out who else uses your favorite functions and how: > http://stuff.codereview.me/lts/9.2 . > > For example, click 'async' at http://stuff.codereview.me/ > lts/9.2/#async-2.1.1.1/Control/Concurrent/Async.hs? > corpus&signature&line=175 to get all the callsites of that method. > > There are additional files available at http://stuff.codereview.me/ if > you want to serve the xrefs locally, or merge your own packages into the > index (assuming you use the same stackage lts version). > > A request: the crossreferencing is pretty usable, but far from complete. > If you find any issues (missing crossreferences or bad ones), please have a > look at the buglist at https://github.com/google/haskell-indexer/issues, > and thumbs-up any that you find hurting, or open new ones! > > Thank you & happy code browsing, > Robin > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 me at ara.io Thu Aug 31 10:16:56 2017 From: me at ara.io (Ara Adkins) Date: Thu, 31 Aug 2017 11:16:56 +0100 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: Message-ID: No useful contributions from me, but I just wanted to say that this is a really cool idea! _ara > On 31 Aug 2017, at 06:41, Robin Palotai wrote: > > To find out who else uses your favorite functions and how: http://stuff.codereview.me/lts/9.2 . > > For example, click 'async' at http://stuff.codereview.me/lts/9.2/#async-2.1.1.1/Control/Concurrent/Async.hs?corpus&signature&line=175 to get all the callsites of that method. > > There are additional files available at http://stuff.codereview.me/ if you want to serve the xrefs locally, or merge your own packages into the index (assuming you use the same stackage lts version). > > A request: the crossreferencing is pretty usable, but far from complete. If you find any issues (missing crossreferences or bad ones), please have a look at the buglist at https://github.com/google/haskell-indexer/issues, and thumbs-up any that you find hurting, or open new ones! > > Thank you & happy code browsing, > Robin > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at nh2.me Thu Aug 31 11:23:29 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Thu, 31 Aug 2017 12:23:29 +0100 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: Message-ID: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Hey Robin, This is really awesome and useful. I think it will help a lot to decide whether or not we can change/deprecate a certain function, as now we can really easily judge how many callers it has. How long does that take to generate? And how did you run it to do it for all of Stackage? Thanks! On 31/08/17 06:41, Robin Palotai wrote: > To find out who else uses your favorite functions and > how: http://stuff.codereview.me/lts/9.2 . From palotai.robin at gmail.com Thu Aug 31 11:34:36 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 31 Aug 2017 13:34:36 +0200 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: Hi Niklas - sounds like a nice usecase. Though we need to make sure no usages are missing to make that decision (there are some edge cases yet, for example around TH splice application, or type families). Also it's only valid on the set of indexed packages. I'll merge later, but https://github.com/robinp/haskell-indexer/commit/0592c3d934515c4661c69c5b998e26a543b93b52 has the changes necessary. Note: - It didn't index ~50 packages - For some it complained that C libs are missing (like SDL, though I was using the full stack-build Docker image) - I had to kill a few huge compilations that ate my RAM (Agda, language-python, and some yi packages) I would estimate 8-12 hours, but didn't follow closely (also it was idling quite some due to the huge compilations). By the way the per-package entries are available for download in a tarball, so if you just index your local packages and dump the entries along with those of your dependencies into the graphstore, you can get a ~full local index without reexecuting the whole indexing. In the future it would be nice to have tooling that magically fetches the pre-generated entries you need, and merges them locally. 2017-08-31 13:23 GMT+02:00 Niklas Hambüchen : > Hey Robin, > > This is really awesome and useful. > > I think it will help a lot to decide whether or not we can > change/deprecate a certain function, as now we can really easily judge > how many callers it has. > > How long does that take to generate? > And how did you run it to do it for all of Stackage? > > Thanks! > > On 31/08/17 06:41, Robin Palotai wrote: > > To find out who else uses your favorite functions and > > how: http://stuff.codereview.me/lts/9.2 . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Aug 31 12:18:37 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 31 Aug 2017 12:18:37 +0000 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: Which Docker image did you use for building? The (inappropriately named but hysterical raisins and all that) snoyberg/stackage Docker images are what we use for doing the actual Stackage builds. On Thu, Aug 31, 2017, 2:37 PM Robin Palotai wrote: > Hi Niklas - sounds like a nice usecase. > > Though we need to make sure no usages are missing to make that decision > (there are some edge cases yet, for example around TH splice application, > or type families). Also it's only valid on the set of indexed packages. > > I'll merge later, but > https://github.com/robinp/haskell-indexer/commit/0592c3d934515c4661c69c5b998e26a543b93b52 > has the changes necessary. Note: > - It didn't index ~50 packages > - For some it complained that C libs are missing (like SDL, though I was > using the full stack-build Docker image) > - I had to kill a few huge compilations that ate my RAM (Agda, > language-python, and some yi packages) > > I would estimate 8-12 hours, but didn't follow closely (also it was idling > quite some due to the huge compilations). > > By the way the per-package entries are available for download in a > tarball, so if you just index your local packages and dump the entries > along with those of your dependencies into the graphstore, you can get a > ~full local index without reexecuting the whole indexing. In the future it > would be nice to have tooling that magically fetches the pre-generated > entries you need, and merges them locally. > > 2017-08-31 13:23 GMT+02:00 Niklas Hambüchen : > >> Hey Robin, >> >> This is really awesome and useful. >> >> I think it will help a lot to decide whether or not we can >> change/deprecate a certain function, as now we can really easily judge >> how many callers it has. >> >> How long does that take to generate? >> And how did you run it to do it for all of Stackage? >> >> Thanks! >> >> On 31/08/17 06:41, Robin Palotai wrote: >> > To find out who else uses your favorite functions and >> > how: http://stuff.codereview.me/lts/9.2 . >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 palotai.robin at gmail.com Thu Aug 31 12:27:14 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 31 Aug 2017 14:27:14 +0200 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: I used fpco/stack-build:lts-9.2. Might explain, thank you! Is the GHC directory layout the same in snoyberg/stackage? Just asking since the derived container hijacks the GHC executable for the indexer. 2017-08-31 14:18 GMT+02:00 Michael Snoyman : > Which Docker image did you use for building? The (inappropriately named > but hysterical raisins and all that) snoyberg/stackage Docker images are > what we use for doing the actual Stackage builds. > > On Thu, Aug 31, 2017, 2:37 PM Robin Palotai > wrote: > >> Hi Niklas - sounds like a nice usecase. >> >> Though we need to make sure no usages are missing to make that decision >> (there are some edge cases yet, for example around TH splice application, >> or type families). Also it's only valid on the set of indexed packages. >> >> I'll merge later, but https://github.com/robinp/haskell-indexer/commit/ >> 0592c3d934515c4661c69c5b998e26a543b93b52 has the changes necessary. Note: >> - It didn't index ~50 packages >> - For some it complained that C libs are missing (like SDL, though I was >> using the full stack-build Docker image) >> - I had to kill a few huge compilations that ate my RAM (Agda, >> language-python, and some yi packages) >> >> I would estimate 8-12 hours, but didn't follow closely (also it was >> idling quite some due to the huge compilations). >> >> By the way the per-package entries are available for download in a >> tarball, so if you just index your local packages and dump the entries >> along with those of your dependencies into the graphstore, you can get a >> ~full local index without reexecuting the whole indexing. In the future it >> would be nice to have tooling that magically fetches the pre-generated >> entries you need, and merges them locally. >> >> 2017-08-31 13:23 GMT+02:00 Niklas Hambüchen : >> >>> Hey Robin, >>> >>> This is really awesome and useful. >>> >>> I think it will help a lot to decide whether or not we can >>> change/deprecate a certain function, as now we can really easily judge >>> how many callers it has. >>> >>> How long does that take to generate? >>> And how did you run it to do it for all of Stackage? >>> >>> Thanks! >>> >>> On 31/08/17 06:41, Robin Palotai wrote: >>> > To find out who else uses your favorite functions and >>> > how: http://stuff.codereview.me/lts/9.2 . >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu Aug 31 14:06:13 2017 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 31 Aug 2017 17:06:13 +0300 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: It looks like it should be using the same method of installing GHC (Herbert's PPA). I'm not sure what you mean by hijacking the GHC executable though. On Thu, Aug 31, 2017 at 3:27 PM, Robin Palotai wrote: > I used fpco/stack-build:lts-9.2. Might explain, thank you! > Is the GHC directory layout the same in snoyberg/stackage? Just asking > since the derived container hijacks the GHC executable for the indexer. > > 2017-08-31 14:18 GMT+02:00 Michael Snoyman : > >> Which Docker image did you use for building? The (inappropriately named >> but hysterical raisins and all that) snoyberg/stackage Docker images are >> what we use for doing the actual Stackage builds. >> >> On Thu, Aug 31, 2017, 2:37 PM Robin Palotai >> wrote: >> >>> Hi Niklas - sounds like a nice usecase. >>> >>> Though we need to make sure no usages are missing to make that decision >>> (there are some edge cases yet, for example around TH splice application, >>> or type families). Also it's only valid on the set of indexed packages. >>> >>> I'll merge later, but https://github.com/robinp/hask >>> ell-indexer/commit/0592c3d934515c4661c69c5b998e26a543b93b52 has the >>> changes necessary. Note: >>> - It didn't index ~50 packages >>> - For some it complained that C libs are missing (like SDL, though I was >>> using the full stack-build Docker image) >>> - I had to kill a few huge compilations that ate my RAM (Agda, >>> language-python, and some yi packages) >>> >>> I would estimate 8-12 hours, but didn't follow closely (also it was >>> idling quite some due to the huge compilations). >>> >>> By the way the per-package entries are available for download in a >>> tarball, so if you just index your local packages and dump the entries >>> along with those of your dependencies into the graphstore, you can get a >>> ~full local index without reexecuting the whole indexing. In the future it >>> would be nice to have tooling that magically fetches the pre-generated >>> entries you need, and merges them locally. >>> >>> 2017-08-31 13:23 GMT+02:00 Niklas Hambüchen : >>> >>>> Hey Robin, >>>> >>>> This is really awesome and useful. >>>> >>>> I think it will help a lot to decide whether or not we can >>>> change/deprecate a certain function, as now we can really easily judge >>>> how many callers it has. >>>> >>>> How long does that take to generate? >>>> And how did you run it to do it for all of Stackage? >>>> >>>> Thanks! >>>> >>>> On 31/08/17 06:41, Robin Palotai wrote: >>>> > To find out who else uses your favorite functions and >>>> > how: http://stuff.codereview.me/lts/9.2 . >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 palotai.robin at gmail.com Thu Aug 31 14:11:37 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 31 Aug 2017 16:11:37 +0200 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: I mean the build/indexing scripts takes the GHC in the container, and replaces it with the indexer wrapper (that will call both the original GHC, and the indexer). This is to capture the compiler arguments. If the paths are the same, it's easy to adopt to the other container. 2017-08-31 16:06 GMT+02:00 Michael Snoyman : > It looks like it should be using the same method of installing GHC > (Herbert's PPA). I'm not sure what you mean by hijacking the GHC executable > though. > > On Thu, Aug 31, 2017 at 3:27 PM, Robin Palotai > wrote: > >> I used fpco/stack-build:lts-9.2. Might explain, thank you! >> Is the GHC directory layout the same in snoyberg/stackage? Just asking >> since the derived container hijacks the GHC executable for the indexer. >> >> 2017-08-31 14:18 GMT+02:00 Michael Snoyman : >> >>> Which Docker image did you use for building? The (inappropriately named >>> but hysterical raisins and all that) snoyberg/stackage Docker images are >>> what we use for doing the actual Stackage builds. >>> >>> On Thu, Aug 31, 2017, 2:37 PM Robin Palotai >>> wrote: >>> >>>> Hi Niklas - sounds like a nice usecase. >>>> >>>> Though we need to make sure no usages are missing to make that decision >>>> (there are some edge cases yet, for example around TH splice application, >>>> or type families). Also it's only valid on the set of indexed packages. >>>> >>>> I'll merge later, but https://github.com/robinp/hask >>>> ell-indexer/commit/0592c3d934515c4661c69c5b998e26a543b93b52 has the >>>> changes necessary. Note: >>>> - It didn't index ~50 packages >>>> - For some it complained that C libs are missing (like SDL, though I >>>> was using the full stack-build Docker image) >>>> - I had to kill a few huge compilations that ate my RAM (Agda, >>>> language-python, and some yi packages) >>>> >>>> I would estimate 8-12 hours, but didn't follow closely (also it was >>>> idling quite some due to the huge compilations). >>>> >>>> By the way the per-package entries are available for download in a >>>> tarball, so if you just index your local packages and dump the entries >>>> along with those of your dependencies into the graphstore, you can get a >>>> ~full local index without reexecuting the whole indexing. In the future it >>>> would be nice to have tooling that magically fetches the pre-generated >>>> entries you need, and merges them locally. >>>> >>>> 2017-08-31 13:23 GMT+02:00 Niklas Hambüchen : >>>> >>>>> Hey Robin, >>>>> >>>>> This is really awesome and useful. >>>>> >>>>> I think it will help a lot to decide whether or not we can >>>>> change/deprecate a certain function, as now we can really easily judge >>>>> how many callers it has. >>>>> >>>>> How long does that take to generate? >>>>> And how did you run it to do it for all of Stackage? >>>>> >>>>> Thanks! >>>>> >>>>> On 31/08/17 06:41, Robin Palotai wrote: >>>>> > To find out who else uses your favorite functions and >>>>> > how: http://stuff.codereview.me/lts/9.2 . >>>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view 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 ricardo at sip.ucm.es Thu Aug 31 15:05:31 2017 From: ricardo at sip.ucm.es (=?UTF-8?Q?Ricardo_Pe=c3=b1a?=) Date: Thu, 31 Aug 2017 17:05:31 +0200 Subject: [Haskell-cafe] How to import hidden modules Message-ID: <31e52a0a-540b-7988-cebe-c13afbb144f0@sip.ucm.es> Hi, I need to define a class instance for the algebraic datatype Data.Map.Map in the Hierarchical GCH libraries, but I do not find the way to import Data.Map.Internal which it is assumed to be hidden. Is there any way to access to this definition? Thanks -Ricardo From brucker at spamfence.net Thu Aug 31 15:07:48 2017 From: brucker at spamfence.net (Achim D. Brucker) Date: Thu, 31 Aug 2017 16:07:48 +0100 Subject: [Haskell-cafe] ThEdu'17 Post-Proceedings: Call for Papers Message-ID: <20170831150748.nrzfk7oebpzghdln@fujikawa.home.brucker.ch> (Apologies for duplicates) Call for Papers - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Post-Proceedings --- ThEdu'17 - Electronic Proceedings in Theoretical Computer Science ThEdu'17 --- Theorem proving components for Educational software 6 August 2017, Gothenburg, Sweden, at CADE26 http://www.uc.pt/en/congressos/thedu/thedu17 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Post-Proceedings THedu'17 Scope: Computer Theorem Proving is becoming a paradigm as well as a technological base for a new generation of educational software in science, technology, engineering and mathematics. The workshop brought together experts in automated deduction with experts in education in order to further clarify the shape of the new software generation and to discuss existing systems. This call is open for everyone, also those who did not participate in the workshop. Important Dates (EPTCS Post-Proceedings) * Call for papers: 08 Sep 2017 * Submission (full papers): 17 Nov 2017 * Notification of acceptance: 15 Dec 2017 * Revised papers due: 19 Jan 2018 Topics of interest include: - methods of automated deduction applied to checking students' input; - methods of automated deduction applied to prove post-conditions for particular problem solutions; - combinations of deduction and computation enabling systems to propose next steps; - automated provers specific for dynamic geometry systems; - proof and proving in mathematics education. Submission We welcome submission of papers presenting original unpublished work which is not been submitted for publication elsewhere. The authors should comply with the "instructions for authors", LaTeX style files and accept the "Non-exclusive license to distribute" of EPTCS: Instructions for authors (http://info.eptcs.org/) LaTeX style file and formatting instructions (http://style.eptcs.org/) Copyright (http://copyright.eptcs.org/) Papers should be submitted via easychair, https://easychair.org/conferences/?conf=thedu17 . Program Committee Francisco Botana, University of Vigo at Pontevedra, Spain Achim Brucker, University of Sheffield, United Kingdom Roman Hašek, University of South Bohemia, Czech Republic Filip Maric, University of Belgrade, Serbia Walther Neuper, Graz University of Technology, Austria (co-chair) Pavel Pech, University of South Bohemia, Czech Republic Pedro Quaresma, University of Coimbra, Portugal (co-chair) Vanda Santos, CISUC, Portugal Wolfgang Schreiner, Johannes Kepler University, Austria Burkhart Wolff, University Paris-Sud, France -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From mihai.maruseac at gmail.com Thu Aug 31 15:17:17 2017 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Thu, 31 Aug 2017 08:17:17 -0700 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: References: Message-ID: Hi, This sounds great. Can you prepare an entry for HCAR (https://wiki.haskell.org/Haskell_Communities_and_Activities_Report) for this project? Seems like a good addition to the ecosystem. On Wed, Aug 30, 2017 at 10:41 PM, Robin Palotai wrote: > To find out who else uses your favorite functions and how: > http://stuff.codereview.me/lts/9.2 . > > For example, click 'async' at > http://stuff.codereview.me/lts/9.2/#async-2.1.1.1/Control/Concurrent/Async.hs?corpus&signature&line=175 > to get all the callsites of that method. > > There are additional files available at http://stuff.codereview.me/ if you > want to serve the xrefs locally, or merge your own packages into the index > (assuming you use the same stackage lts version). > > A request: the crossreferencing is pretty usable, but far from complete. If > you find any issues (missing crossreferences or bad ones), please have a > look at the buglist at https://github.com/google/haskell-indexer/issues, and > thumbs-up any that you find hurting, or open new ones! > > Thank you & happy code browsing, > Robin > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From gregmainland at gmail.com Thu Aug 31 16:17:44 2017 From: gregmainland at gmail.com (Greg Horn) Date: Thu, 31 Aug 2017 16:17:44 +0000 Subject: [Haskell-cafe] How to import hidden modules In-Reply-To: <31e52a0a-540b-7988-cebe-c13afbb144f0@sip.ucm.es> References: <31e52a0a-540b-7988-cebe-c13afbb144f0@sip.ucm.es> Message-ID: It might be possible with the http://hackage.haskell.org/package/true-name package. I've never used it but I remember the hilarious announcement https://mail.haskell.org/pipermail/haskell-cafe/2016-January/122707.html Best, Greg On Thu, Aug 31, 2017 at 8:07 AM Ricardo Peña wrote: > Hi, > > I need to define a class instance for the algebraic datatype > Data.Map.Map in the Hierarchical GCH libraries, but I do not find the > way to import Data.Map.Internal which it is assumed to be hidden. Is > there any way to access to this definition? > > Thanks > -Ricardo > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ricardo at sip.ucm.es Thu Aug 31 17:28:10 2017 From: ricardo at sip.ucm.es (=?UTF-8?Q?Ricardo_Pe=c3=b1a?=) Date: Thu, 31 Aug 2017 19:28:10 +0200 Subject: [Haskell-cafe] How to import hidden modules In-Reply-To: References: <31e52a0a-540b-7988-cebe-c13afbb144f0@sip.ucm.es> Message-ID: <23e9ebf3-dcee-abc9-392d-61abb6b4d9c5@sip.ucm.es> Thanks Greg, It works perfectly. I have used the hidden constructors both for building values and for doing pattern matching. Best -Ricardo El 31/08/17 a las 18:17, Greg Horn escribió: > It might be possible with the > http://hackage.haskell.org/package/true-name package. I've never used > it but I remember the hilarious announcement > https://mail.haskell.org/pipermail/haskell-cafe/2016-January/122707.html > > Best, > Greg > > On Thu, Aug 31, 2017 at 8:07 AM Ricardo Peña > wrote: > > Hi, > > I need to define a class instance for the algebraic datatype > Data.Map.Map in the Hierarchical GCH libraries, but I do not find the > way to import Data.Map.Internal which it is assumed to be hidden. Is > there any way to access to this definition? > > Thanks > -Ricardo > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Thu Aug 31 18:31:54 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 31 Aug 2017 20:31:54 +0200 Subject: [Haskell-cafe] Crossreferenced codebase for Stackage LTS 9.2 available In-Reply-To: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> References: <8c4634fe-d8a2-2506-8b71-e7c87ffed04c@nh2.me> Message-ID: Am 31.08.2017 um 13:23 schrieb Niklas Hambüchen: > I think it will help a lot to decide whether or not we can > change/deprecate a certain function, as now we can really easily judge > how many callers it has. It does not (and cannot) tell you about caller code that is not on Hackage. If you have a low-level library then that information is still better than nothing, but if your code is a public API this information is almost worse than nothing. Just saying, having seen some people deprecate stuff just to be caught in the backlash :-) HTH Jo