From frederic-emmanuel.picca at synchrotron-soleil.fr Sun Sep 1 07:26:36 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Sun, 1 Sep 2019 07:26:36 +0000 Subject: [Haskell-cafe] ghc and OpenMP Message-ID: Hello, I would like your help, in order to understand how to modify a cabal file in order to compile an Haskell modules with .c files (containing OpenMP pragma). I use FFI and a bunch of .c and .h files for the computation part. thanks for your help. I am runnng hc on Debian stable. Cheers Frederic From simon at joyful.com Sun Sep 1 16:59:19 2019 From: simon at joyful.com (Simon Michael) Date: Sun, 1 Sep 2019 09:59:19 -0700 Subject: [Haskell-cafe] ANN: hledger 1.15 Message-ID: <5546E58F-3175-416E-96EF-8889618C059E@joyful.com> I'm pleased to announce hledger 1.15 ! Thanks to release contributors Caleb Maclennan, Jakob Schöttl, Henning Thielemann, Dmitry Astapov, Ben Creasy, zieone, Boyd Kelly, Gabriel Ebner, Hans-Peter Deifel, and Andreas Pauley. hledger is a robust, cross-platform, multicurrency, plain text accounting tool, with command-line, console and web UIs. It is one of the leading implementations of plain text accounting, and is a modern and largely compatible reimplementation of Ledger. Use it for tracking money, time, stocks, cryptocurrencies or any other commodity, Learn more at http://hledger.org and http://plaintextaccounting.org . WHAT'S NEW: A new website, faster and more flexible valuation, more accurate close command, tags --values, new descriptions/payees/notes/diff commands, misc. fixes. For details, see https://hledger.org/release-notes#hledger-1-15 . GETTING STARTED: Many install methods are described at http://hledger.org/download . Some of these might take a few days to become up to date. You can build the latest by doing: stack install --resolver=lts-14.4 hledger-lib-1.15 hledger-1.15 hledger-web-1.15 hledger-ui-1.15 --verbosity=error or: cabal v2-update && cabal v2-install hledger-1.15 hledger-web-1.15 hledger-ui-1.15 To start recording transactions: "hledger add". To list more commands: "hledger". See http://hledger.org for tutorials and support, or join #hledger on Freenode (http://irc.hledger.org), or join via Matrix (http://riot.hledger.org). New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon From vamchale at gmail.com Sun Sep 1 18:03:38 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 1 Sep 2019 13:03:38 -0500 Subject: [Haskell-cafe] ghc and OpenMP In-Reply-To: References: Message-ID: How do you mean? I assume you aren't using hsc2hs or c2hs? Do you have something like hslua already? https://github.com/hslua/hslua/blob/master/hslua.cabal#L131 On 9/1/19 2:26 AM, PICCA Frederic-Emmanuel wrote: > Hello, > > I would like your help, in order to understand how to modify a cabal file in order to compile an Haskell modules with .c files (containing OpenMP pragma). > I use FFI and a bunch of .c and .h files for the computation part. > > thanks for your help. > > I am runnng hc on Debian stable. > > Cheers > > Frederic > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 659 bytes Desc: OpenPGP digital signature URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Sun Sep 1 18:14:00 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Sun, 1 Sep 2019 18:14:00 +0000 Subject: [Haskell-cafe] ghc and OpenMP In-Reply-To: References: , Message-ID: > How do you mean? I assume you aren't using hsc2hs or c2hs? I use hsc2hs, just to write the FFI bindings of my local c files. > Do you have something like hslua already? > https://github.com/hslua/hslua/blob/master/hslua.cabal#L131 Yes, but it seems to me that I need to gives gcc this [1]. So how can I says to ghc, to compile the .c files with OpenMP activated ? [1] https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html From vamchale at gmail.com Sun Sep 1 18:18:06 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 1 Sep 2019 13:18:06 -0500 Subject: [Haskell-cafe] ghc and OpenMP In-Reply-To: References: Message-ID: Ah, I see. In the cabal file you can make a flag with cc-options. It goes in the same place ghc-options would. That's probably the easiest way to do it :) Example: https://hackage.haskell.org/package/fast-arithmetic-0.6.4.2/fast-arithmetic.cabal On 9/1/19 1:14 PM, PICCA Frederic-Emmanuel wrote: >> How do you mean? I assume you aren't using hsc2hs or c2hs? > I use hsc2hs, just to write the FFI bindings of my local c files. > >> Do you have something like hslua already? >> https://github.com/hslua/hslua/blob/master/hslua.cabal#L131 > > Yes, but it seems to me that I need to gives gcc this [1]. > So how can I says to ghc, to compile the .c files with OpenMP activated ? > > > [1] https://gcc.gnu.org/onlinedocs/libgomp/Enabling-OpenMP.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Sun Sep 1 18:40:04 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Sun, 1 Sep 2019 18:40:04 +0000 Subject: [Haskell-cafe] ghc and OpenMP In-Reply-To: References: , Message-ID: Ok, I just added: cc-options: -fopenmp ld-options: -fopenmp and it worked. thanks a lot. Fred From adam at well-typed.com Mon Sep 2 12:16:42 2019 From: adam at well-typed.com (Adam Gundry) Date: Mon, 2 Sep 2019 13:16:42 +0100 Subject: [Haskell-cafe] ANN: optics-0.1 Message-ID: <280989a5-cc95-8bf9-da15-d8bcc2317932@well-typed.com> We are delighted to announce the first Hackage release of optics, a Haskell library for defining and using lenses, traversals, prisms and more. For further information: https://www.well-typed.com/blog/2019/09/announcing-the-optics-library/ https://hackage.haskell.org/package/optics The optics library is broadly similar in functionality to the well-established lens library, but uses an abstract interface rather than exposing the underlying implementation of each optic kind. It aims to be easier to understand than lens, with clearer interfaces, simpler types and better error messages, while retaining as much functionality as possible. It is being developed by Andrzej Rybczak and Adam Gundry, with significant contributions from Oleg Grenrus and Andres Löh, and much copy-pasting of code and selective copying of ideas from lens. -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England From frederic-emmanuel.picca at synchrotron-soleil.fr Mon Sep 2 19:20:10 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Mon, 2 Sep 2019 19:20:10 +0000 Subject: [Haskell-cafe] How to write a Monad instance for this type Message-ID: Hello, I try to write a monad instance for this type which represent the content of an hdf5 file. This file format is similar to a filesystem, where directories are Group and files Dataset. I end up with this type. data Hdf5M a = H5Root (Hdf5M a) | H5Group ByteString [Hdf5M a] -- A group can contain other groups and/or datasets | forall sh b. (NativeType b, Shape sh) => H5Dataset ByteString (Array F sh b) type Hdf5 = Hdf5M () hdf5 :: Hdf5 -> Hdf5 hdf5 = H5Root group :: ByteString -> [Hdf5] -> Hdf5 group g = H5Group g dataset :: (NativeType b, Shape sh) => ByteString -> (Array F sh b) -> Hdf5 dataset = H5Dataset I tryed to inspire myself from the blaze-html Markup type. And I would like to be able to describe a contain like this hdf5 $ do group "name" $ do dataset "name1" array1 dataset "name2" array2 group "other-name" $ do etc... instead of H5Root ( H5Group "name" [ dataset ]...) the final idea, is to be able to serialize object via a class ToHdf5 where toHdf5 :: a -> Hdf5 So my question is someone can help me design this ? thanks for your help Frederic From to_br at uni-bremen.de Tue Sep 3 09:43:40 2019 From: to_br at uni-bremen.de (Tobias Brandt) Date: Tue, 3 Sep 2019 11:43:40 +0200 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: References: Message-ID: <5800a3ad-403a-16a9-d0a2-cab467d7b35a@uni-bremen.de> Hello Frederic, you might want to take a look at /free monads/ and the free library . Cheers, Tobias On 9/2/19 9:20 PM, PICCA Frederic-Emmanuel wrote: > Hello, I try to write a monad instance for this type which represent the content of an hdf5 file. > This file format is similar to a filesystem, where directories are Group and files Dataset. > > I end up with this type. > > data Hdf5M a > = H5Root (Hdf5M a) > | H5Group ByteString [Hdf5M a] -- A group can contain other groups and/or datasets > | forall sh b. (NativeType b, Shape sh) => H5Dataset ByteString (Array F sh b) > > type Hdf5 = Hdf5M () > > hdf5 :: Hdf5 -> Hdf5 > hdf5 = H5Root > > group :: ByteString -> [Hdf5] -> Hdf5 > group g = H5Group g > > dataset :: (NativeType b, Shape sh) => ByteString -> (Array F sh b) -> Hdf5 > dataset = H5Dataset > > I tryed to inspire myself from the blaze-html Markup type. > > And I would like to be able to describe a contain like this > > hdf5 $ do > group "name" $ do > dataset "name1" array1 > dataset "name2" array2 > group "other-name" $ do > etc... > > instead of > > H5Root ( H5Group "name" [ dataset ]...) > > the final idea, is to be able to serialize object via a > > class ToHdf5 where > toHdf5 :: a -> Hdf5 > > So my question is someone can help me design this ? > > thanks for your help > > Frederic > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Tue Sep 3 17:40:56 2019 From: monkleyon at gmail.com (MarLinn) Date: Tue, 3 Sep 2019 19:40:56 +0200 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: References: Message-ID: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> Hi. > I end up with this type. > > data Hdf5M a > = H5Root (Hdf5M a) > | H5Group ByteString [Hdf5M a] -- A group can contain other groups and/or datasets > | forall sh b. (NativeType b, Shape sh) => H5Dataset ByteString (Array F sh b) > > […] > > And I would like to be able to describe a contain like this > > hdf5 $ do > group "name" $ do > dataset "name1" array1 > dataset "name2" array2 > group "other-name" $ do > etc... You don't need a monad instance for this. First of all, you don't even need do syntax to make something "pretty" similar to this. hdf5 $ group "name" $ [ dataset "name1" array1 , dataset "name2" array2 , group "other-name" $ [ … But if you insist, you can just use an existing monad like WriterT. For example (simplified): data Composite a = Base a | Composite [Composite a] type CompositeWriter a = Writer [Composite a] () base = tell . pure . Base composite = censor (pure . Composite) asComposite = Composite . snd . runWriter test = asComposite $ do     base 'a'     base 'b'     composite $ do       base 'c'       base 'd' Hope that helps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Tue Sep 3 18:30:21 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Tue, 3 Sep 2019 14:30:21 -0400 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> References: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> Message-ID: Being able to omit []'s and commas is a very natural desire, and it's not clear why would anyone need to engage with monads to achieve this. Although today monads is probably the only way (NB: look at the RebindableSyntax extension), there were a number of discussions over GHC Proposals as to how to retrofit it into the language, e.g. [Record with Syntax][Record-with]. This and (closed unmerged) the [Extra Commas][Extra-Commas] proposal prompted Joachim to start a [wiki page][All-things-layout] gathering this kind of ideas — which I highly recommend to check out and, possibly, brainstorm. Hopefully, it will turn into a new, this time successful GHC proposal. [Extra-Commas]: https://github.com/ghc-proposals/ghc-proposals/pull/87 [Record-with]: https://github.com/ghc-proposals/ghc-proposals/pull/231 [All-things-layout]: https://gitlab.haskell.org/ghc/ghc/wikis/All-things-layout -- Kind regards, Artem On Tue, 3 Sep 2019 at 13:42, MarLinn wrote: > Hi. > > I end up with this type. > > data Hdf5M a > = H5Root (Hdf5M a) > | H5Group ByteString [Hdf5M a] -- A group can contain other groups and/or datasets > | forall sh b. (NativeType b, Shape sh) => H5Dataset ByteString (Array F sh b) > > […] > > And I would like to be able to describe a contain like this > > hdf5 $ do > group "name" $ do > dataset "name1" array1 > dataset "name2" array2 > group "other-name" $ do > etc... > > You don't need a monad instance for this. First of all, you don't even > need do syntax to make something "pretty" similar to this. > > hdf5 $ > group "name" $ > [ dataset "name1" array1 > , dataset "name2" array2 > , group "other-name" $ [ > … > > But if you insist, you can just use an existing monad like WriterT. For > example (simplified): > > data Composite a = Base a | Composite [Composite a] > > type CompositeWriter a = Writer [Composite a] () > > base = tell . pure . Base > > composite = censor (pure . Composite) > > asComposite = Composite . snd . runWriter > > test = asComposite $ do > base 'a' > base 'b' > composite $ do > base 'c' > base 'd' > > Hope that helps. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 hilco.wijbenga at gmail.com Wed Sep 4 02:32:29 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Tue, 3 Sep 2019 19:32:29 -0700 Subject: [Haskell-cafe] Stack & Test Coverage Message-ID: Hi all, I have a very simple newtype Index = Index Int deriving (Eq, Ord, Enum) for which I have written tests with both HSpec and QuickCheck. Specifically, I have written tests for "==", "/=", "compare" (for all of EQ, LT, and GT), and "toEnum" & "fromEnum". So I thought I had _very_ thoroughly covered that one line. :-) Unfortunately, after running "stack clean ; stack test --coverage" I see in the HTML report that only Eq has been tested and that Ord and Enum have _no_ coverage (i.e. "never executed"). (The module also has some regular functions and an explicit Show instance [all with tests] and those are apparently fine. So coverage does seem to work but not the way I expect?) What am I doing wrong? Cheers, Hilco From ben at smart-cactus.org Wed Sep 4 06:14:38 2019 From: ben at smart-cactus.org (Ben Gamari) Date: Wed, 04 Sep 2019 08:14:38 +0200 Subject: [Haskell-cafe] Stack & Test Coverage In-Reply-To: References: Message-ID: On September 4, 2019 4:32:29 AM GMT+02:00, Hilco Wijbenga wrote: >Hi all, > >I have a very simple > >newtype Index = Index Int deriving (Eq, Ord, Enum) > >for which I have written tests with both HSpec and QuickCheck. >Specifically, I have written tests for "==", "/=", "compare" (for all >of EQ, LT, and GT), and "toEnum" & "fromEnum". So I thought I had >_very_ thoroughly covered that one line. :-) > >Unfortunately, after running "stack clean ; stack test --coverage" I >see in the HTML report that only Eq has been tested and that Ord and >Enum have _no_ coverage (i.e. "never executed"). > >(The module also has some regular functions and an explicit Show >instance [all with tests] and those are apparently fine. So coverage >does seem to work but not the way I expect?) > >What am I doing wrong? > >Cheers, >Hilco >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. This sounds like it may be a ghc bug. Can you open a ticket at https://gitlab.haskell.org/ghc/ghc? Cheers, - Ben From vamchale at gmail.com Thu Sep 5 00:22:22 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 4 Sep 2019 19:22:22 -0500 Subject: [Haskell-cafe] c2hs syntax highlighting in vim Message-ID: <76ebeea0-d0a6-98b0-b817-34a72da1c677@gmail.com> Hi all, I wrote a vim plugin to highlight c2hs files, viz. https://github.com/vmchale/c2hs-vim Cheers, Vanessa McHale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From hilco.wijbenga at gmail.com Thu Sep 5 05:14:36 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Wed, 4 Sep 2019 22:14:36 -0700 Subject: [Haskell-cafe] Stack & Test Coverage In-Reply-To: References: Message-ID: On Tue, Sep 3, 2019 at 11:14 PM Ben Gamari wrote: > > On September 4, 2019 4:32:29 AM GMT+02:00, Hilco Wijbenga wrote: > >Hi all, > > > >I have a very simple > > > >newtype Index = Index Int deriving (Eq, Ord, Enum) > > > >for which I have written tests with both HSpec and QuickCheck. > >Specifically, I have written tests for "==", "/=", "compare" (for all > >of EQ, LT, and GT), and "toEnum" & "fromEnum". So I thought I had > >_very_ thoroughly covered that one line. :-) > > > >Unfortunately, after running "stack clean ; stack test --coverage" I > >see in the HTML report that only Eq has been tested and that Ord and > >Enum have _no_ coverage (i.e. "never executed"). > > > >(The module also has some regular functions and an explicit Show > >instance [all with tests] and those are apparently fine. So coverage > >does seem to work but not the way I expect?) > > > >What am I doing wrong? > > > >Cheers, > >Hilco > >_______________________________________________ > >Haskell-Cafe mailing list > >To (un)subscribe, modify options or view archives go to: > >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >Only members subscribed via the mailman list are allowed to post. > > This sounds like it may be a ghc bug. Can you open a ticket at https://gitlab.haskell.org/ghc/ghc? Well, I wasn't expecting that. :-) I created a tiny test project with just the newtype and even removed Enum. I tried all LTSs listed at https://www.stackage.org from LST-3.22 all the way up to nightly-2019-09-04 and they all behave the same way. (Stack is _awesome_ for this.) I also tried "data" instead of "newtype". That made no difference. Are you sure this might be a GHC bug? Surely someone would have noticed sometime during the last 4 years? It would have been in GHC 7.10.2 already. Anyway, if "yes" then I'll create an issue. It should be very easy to reproduce. (I don't mean to doubt you but it's rather rare in software that it's "the compiler" and not "the developer". :-) I don't want to waste anyone's time.) From hilco.wijbenga at gmail.com Thu Sep 5 05:25:20 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Wed, 4 Sep 2019 22:25:20 -0700 Subject: [Haskell-cafe] Stack & Test Coverage In-Reply-To: References: Message-ID: On Wed, Sep 4, 2019 at 10:14 PM Hilco Wijbenga wrote: > > On Tue, Sep 3, 2019 at 11:14 PM Ben Gamari wrote: > > > > On September 4, 2019 4:32:29 AM GMT+02:00, Hilco Wijbenga wrote: > > >Hi all, > > > > > >I have a very simple > > > > > >newtype Index = Index Int deriving (Eq, Ord, Enum) > > > > > >for which I have written tests with both HSpec and QuickCheck. > > >Specifically, I have written tests for "==", "/=", "compare" (for all > > >of EQ, LT, and GT), and "toEnum" & "fromEnum". So I thought I had > > >_very_ thoroughly covered that one line. :-) > > > > > >Unfortunately, after running "stack clean ; stack test --coverage" I > > >see in the HTML report that only Eq has been tested and that Ord and > > >Enum have _no_ coverage (i.e. "never executed"). > > > > > >(The module also has some regular functions and an explicit Show > > >instance [all with tests] and those are apparently fine. So coverage > > >does seem to work but not the way I expect?) > > > > > >What am I doing wrong? > > > > > >Cheers, > > >Hilco > > >_______________________________________________ > > >Haskell-Cafe mailing list > > >To (un)subscribe, modify options or view archives go to: > > >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > >Only members subscribed via the mailman list are allowed to post. > > > > This sounds like it may be a ghc bug. Can you open a ticket at https://gitlab.haskell.org/ghc/ghc? > > Well, I wasn't expecting that. :-) > > I created a tiny test project with just the newtype and even removed > Enum. I tried all LTSs listed at https://www.stackage.org from > LST-3.22 all the way up to nightly-2019-09-04 and they all behave the > same way. (Stack is _awesome_ for this.) I also tried "data" instead > of "newtype". That made no difference. > > Are you sure this might be a GHC bug? Surely someone would have > noticed sometime during the last 4 years? It would have been in GHC > 7.10.2 already. Anyway, if "yes" then I'll create an issue. It should > be very easy to reproduce. (I don't mean to doubt you but it's rather > rare in software that it's "the compiler" and not "the developer". :-) > I don't want to waste anyone's time.) Mmm, so for sake of completeness: ----- Lib.hs module Lib where newtype Index = Index Int deriving (Eq, Ord, Show) ----- LibSpec.hs module LibSpec (spec) where import Test.Hspec import Test.QuickCheck import Lib genValidIndexes :: Gen (Index, Index) genValidIndexes = do lft <- choose (0, 100) rgt <- choose (0, 100) pure (Index lft, Index rgt) prop_EqIndex :: (Index, Index) -> Bool prop_EqIndex (lftIndex@(Index lft), rgtIndex@(Index rgt)) = (lftIndex == rgtIndex) == (lft == rgt) prop_OrdIndex :: (Index, Index) -> Bool prop_OrdIndex (lftIndex@(Index lft), rgtIndex@(Index rgt)) = compare lftIndex rgtIndex == compare lft rgt spec :: Spec spec = do describe "Index::Eq" $ do it "Index 0 == Index 0" $ Index 0 == Index 0 `shouldBe` True it "Index 0 /= Index 1" $ Index 0 /= Index 1 `shouldBe` True it "Index 1 /= Index 0" $ Index 1 /= Index 0 `shouldBe` True it "prop_Eq" $ property $ forAll genValidIndexes prop_EqIndex describe "Index::Ord" $ do it "compare (Index 0) (Index 0)" $ compare (Index 0) (Index 0) `shouldBe` EQ it "compare (Index 1) (Index 2)" $ compare (Index 1) (Index 2) `shouldBe` LT it "compare (Index 2) (Index 1)" $ compare (Index 2) (Index 1) `shouldBe` GT it "prop_OrdIndex" $ property $ forAll genValidIndexes prop_OrdIndex From a.pelenitsyn at gmail.com Thu Sep 5 06:39:08 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Thu, 5 Sep 2019 02:39:08 -0400 Subject: [Haskell-cafe] Stack & Test Coverage In-Reply-To: References: Message-ID: Hello Hilco, Please, do file a bug. -- Best, Artem On Thu, Sep 5, 2019, 1:26 AM Hilco Wijbenga wrote: > On Wed, Sep 4, 2019 at 10:14 PM Hilco Wijbenga > wrote: > > > > On Tue, Sep 3, 2019 at 11:14 PM Ben Gamari wrote: > > > > > > On September 4, 2019 4:32:29 AM GMT+02:00, Hilco Wijbenga < > hilco.wijbenga at gmail.com> wrote: > > > >Hi all, > > > > > > > >I have a very simple > > > > > > > >newtype Index = Index Int deriving (Eq, Ord, Enum) > > > > > > > >for which I have written tests with both HSpec and QuickCheck. > > > >Specifically, I have written tests for "==", "/=", "compare" (for all > > > >of EQ, LT, and GT), and "toEnum" & "fromEnum". So I thought I had > > > >_very_ thoroughly covered that one line. :-) > > > > > > > >Unfortunately, after running "stack clean ; stack test --coverage" I > > > >see in the HTML report that only Eq has been tested and that Ord and > > > >Enum have _no_ coverage (i.e. "never executed"). > > > > > > > >(The module also has some regular functions and an explicit Show > > > >instance [all with tests] and those are apparently fine. So coverage > > > >does seem to work but not the way I expect?) > > > > > > > >What am I doing wrong? > > > > > > > >Cheers, > > > >Hilco > > > >_______________________________________________ > > > >Haskell-Cafe mailing list > > > >To (un)subscribe, modify options or view archives go to: > > > >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > >Only members subscribed via the mailman list are allowed to post. > > > > > > This sounds like it may be a ghc bug. Can you open a ticket at > https://gitlab.haskell.org/ghc/ghc? > > > > Well, I wasn't expecting that. :-) > > > > I created a tiny test project with just the newtype and even removed > > Enum. I tried all LTSs listed at https://www.stackage.org from > > LST-3.22 all the way up to nightly-2019-09-04 and they all behave the > > same way. (Stack is _awesome_ for this.) I also tried "data" instead > > of "newtype". That made no difference. > > > > Are you sure this might be a GHC bug? Surely someone would have > > noticed sometime during the last 4 years? It would have been in GHC > > 7.10.2 already. Anyway, if "yes" then I'll create an issue. It should > > be very easy to reproduce. (I don't mean to doubt you but it's rather > > rare in software that it's "the compiler" and not "the developer". :-) > > I don't want to waste anyone's time.) > > Mmm, so for sake of completeness: > > ----- Lib.hs > module Lib where > newtype Index = Index Int deriving (Eq, Ord, Show) > > ----- LibSpec.hs > module LibSpec (spec) where > > import Test.Hspec > import Test.QuickCheck > import Lib > > genValidIndexes :: Gen (Index, Index) > genValidIndexes = do lft <- choose (0, 100) > rgt <- choose (0, 100) > pure (Index lft, Index rgt) > > prop_EqIndex :: (Index, Index) -> Bool > prop_EqIndex (lftIndex@(Index lft), rgtIndex@(Index rgt)) = (lftIndex > == rgtIndex) == (lft == rgt) > > prop_OrdIndex :: (Index, Index) -> Bool > prop_OrdIndex (lftIndex@(Index lft), rgtIndex@(Index rgt)) = compare > lftIndex rgtIndex == compare lft rgt > > spec :: Spec > spec > = do > describe "Index::Eq" $ > do it "Index 0 == Index 0" $ Index 0 == Index 0 `shouldBe` True > it "Index 0 /= Index 1" $ Index 0 /= Index 1 `shouldBe` True > it "Index 1 /= Index 0" $ Index 1 /= Index 0 `shouldBe` True > it "prop_Eq" $ property $ forAll genValidIndexes prop_EqIndex > describe "Index::Ord" $ > do it "compare (Index 0) (Index 0)" $ compare (Index 0) (Index > 0) `shouldBe` EQ > it "compare (Index 1) (Index 2)" $ compare (Index 1) (Index > 2) `shouldBe` LT > it "compare (Index 2) (Index 1)" $ compare (Index 2) (Index > 1) `shouldBe` GT > it "prop_OrdIndex" $ property $ forAll genValidIndexes > prop_OrdIndex > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ivanperezdominguez at gmail.com Thu Sep 5 12:54:00 2019 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Thu, 5 Sep 2019 08:54:00 -0400 Subject: [Haskell-cafe] c2hs syntax highlighting in vim In-Reply-To: <76ebeea0-d0a6-98b0-b817-34a72da1c677@gmail.com> References: <76ebeea0-d0a6-98b0-b817-34a72da1c677@gmail.com> Message-ID: Cool! As a vim user, I'm happy to see efforts towards making haskell support in vim better. Thanks! Ivan On Wed, 4 Sep 2019 at 20:23, Vanessa McHale wrote: > Hi all, > > I wrote a vim plugin to highlight c2hs files, viz. > https://github.com/vmchale/c2hs-vim > > Cheers, > Vanessa McHale > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 hilco.wijbenga at gmail.com Fri Sep 6 05:01:31 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Thu, 5 Sep 2019 22:01:31 -0700 Subject: [Haskell-cafe] Stack & Test Coverage In-Reply-To: References: Message-ID: https://gitlab.haskell.org/ghc/ghc/issues/17155 From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Sep 6 08:58:01 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 6 Sep 2019 08:58:01 +0000 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> References: , <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> Message-ID: > You don't need a monad instance for this. First of all, you don't even need do syntax to make something "pretty" similar to this. > hdf5 $ > group "name" $ > [ dataset "name1" array1 > , dataset "name2" array2 > , group "other-name" $ [ > … This is for now the solution I decide to keep., nevertheless thanks for the monad ;). Now I would like you opinion about a type which allows me to select a node in this tree. I need to extract a bunch of values from these hdf5 files. So I discribe a location in the tree, like this with another type quite similar to the first but with only one child per group. This way there is only one dataset extracted. (maybe later, I will discuss about extracting multiple dataset ;). data Hdf5Path sh e = H5RootPath (Hdf5Path sh e) | H5GroupPath ByteString (Hdf5Path sh e) | H5DatasetPath ByteString hdf5p $ group "name" $ group "otherName" $ dataset "myDataset" Then I need to write something like this. withDataset :: File -> Hdf5Path sh e -> (Dataset -> IO r) -> IO r BUT, I would like to express this path like this hdf5p :: group :: group "otherName" $ dataset "mydataset" So should I define a type and modify the group constructor like this H5GroupPath BytString (Hdf5Path sh e) GroupDesc = ByName ByteString | ByPosition Int | etc... H5GroupPath GropDesc (Hdf5Path sh e) the only problem I see with this is that I need to encode all the strategies in this type. Is there a better way to do this sort of things. thanks Frederic From will.yager at gmail.com Fri Sep 6 12:35:00 2019 From: will.yager at gmail.com (Will Yager) Date: Fri, 6 Sep 2019 20:35:00 +0800 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: References: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> Message-ID: Hi Frederic, Lenses (http://hackage.haskell.org/package/lens) are a powerful and well-supported way of peering into data structures. They are a bit of work to learn, but well worth it. Will On Sep 6, 2019, at 4:58 PM, PICCA Frederic-Emmanuel wrote: >> You don't need a monad instance for this. First of all, you don't even need do syntax to make something "pretty" similar to this. > >> hdf5 $ >> group "name" $ >> [ dataset "name1" array1 >> , dataset "name2" array2 >> , group "other-name" $ [ >> … > > This is for now the solution I decide to keep., nevertheless thanks for the monad ;). > > Now I would like you opinion about a type which allows me to select a node in this tree. > > I need to extract a bunch of values from these hdf5 files. > So I discribe a location in the tree, like this with another type quite similar to the first but with only > one child per group. This way there is only one dataset extracted. > > (maybe later, I will discuss about extracting multiple dataset ;). > > data Hdf5Path sh e > = H5RootPath (Hdf5Path sh e) > | H5GroupPath ByteString (Hdf5Path sh e) > | H5DatasetPath ByteString > > hdf5p $ group "name" $ group "otherName" $ dataset "myDataset" > > Then I need to write something like this. > > withDataset :: File -> Hdf5Path sh e -> (Dataset -> IO r) -> IO r > > BUT, I would like to express this path like this > > hdf5p :: group :: group "otherName" $ dataset "mydataset" > > So should I define a type and modify the group constructor like this > > H5GroupPath BytString (Hdf5Path sh e) > > GroupDesc = ByName ByteString > | ByPosition Int > | etc... > > H5GroupPath GropDesc (Hdf5Path sh e) > > the only problem I see with this is that I need to encode all the strategies in this type. > > Is there a better way to do this sort of things. > > thanks > > Frederic > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Fri Sep 6 12:51:09 2019 From: monkleyon at gmail.com (MarLinn) Date: Fri, 6 Sep 2019 14:51:09 +0200 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: References: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> Message-ID: <111d8188-2ecd-b128-78fb-6e00d30c69cc@gmail.com> > So I discribe a location in the tree, like this with another type quite similar to the first but with only > one child per group. This way there is only one dataset extracted. > > (maybe later, I will discuss about extracting multiple dataset ;). > > data Hdf5Path sh e > = H5RootPath (Hdf5Path sh e) > | H5GroupPath ByteString (Hdf5Path sh e) > | H5DatasetPath ByteString > > hdf5p $ group "name" $ group "otherName" $ dataset "myDataset" > > Is there a better way to do this sort of things. The answer to this depends a lot on how powerful you want your path to be. But the easiest way would probably be to just wrap functions: -- can be used with functions from Data.List data Path a = GroupPath ([Hdf5M a] -> Hdf5M a) (Path a) | … test = hdf5p $ group head   $ group (firstOfName "otherName") $ dataset "mydataset" test2 = hdf5p $ group (!! 6) $ group (firstOfName "otherName") $ dataset "mydataset" firstOfName n = fromJust . (find $ hasName n) hasName :: ByteString -> Hdf5M a -> Bool Or if you want more restrictions on which types of paths can be constructed data Path a = GroupPathWithFilter (Hdf5M a -> Bool) (Path a) | GroupPathByIndex Int (Path a) … -- equivalent to "head" test = hdf5p $ group (const True) $ group (hasName "otherName") $ dataset "mydataset" test2 = hdf5p $ groupAt 6 $ group (hasName "otherName") $ dataset "mydataset" Side note: I don't see a reason why the path needs to be recursive if this is all you want. type Path a = [PathSegment a] data PathSegment a = GroupPath (Hdf5M a -> Bool) | … test = hdf5p [group (const True) , group (hasName "otherName") , dataset "mydataset"]  What if you want something more like an XPath or a path with wildcards? You can still expand on these ideas easily. type Path a = [PathSegment a] data PathSegment a = GroupPath ([Hdf5M a] -> [Hdf5M a]) | … test = hdf5p [group (pure . head)   , group (filter $ hasName "otherName") , dataset "mydataset"] test2 = hdf5p [group (pure . (!! 6)) , group (filter $ hasName "otherName") , dataset "mydataset"] -- or more likely test = hdf5p [group head   , groups (hasName "otherName") , dataset "mydataset"] test2 = hdf5p' [group (!! 6) , groups (hasName "otherName") , dataset "mydataset"] -- But these are basically just lists of [Hdf5M a] → [Hdf5M a] functions with one special function -- at the end – which can also be cast as such a function. Therefore something like this would also be possible: newtype Path a = Path [[Hdf5M a] -> [Hdf5M a]] compilePath (Path fs) = filter isDataset . foldl1 (.) fs -- Path can also be turned into a monoid now test = hdf5p $ group head <> groups (hasName "otherName") <> dataset "mydataset" -- which also means it would be prudent to reduce this to newtype Path a = Path ([Hdf5M a] -> [Hdf5M a]) While this final solution looks quite elegant from my POV, there are several directions this can't be extended into as easily as the recursive tree. So this is just a bunch of options from a few minutes of brainstorming, the best option for your particular problem is probably somewhere between these and the ones you already had. Cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Sep 6 12:57:15 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 6 Sep 2019 12:57:15 +0000 Subject: [Haskell-cafe] How to write a Monad instance for this type In-Reply-To: <111d8188-2ecd-b128-78fb-6e00d30c69cc@gmail.com> References: <45dcda9e-d00e-2c97-4a79-92eb7e55d8be@gmail.com> , <111d8188-2ecd-b128-78fb-6e00d30c69cc@gmail.com> Message-ID: thanks I lot for your time, I will think about this for my use cases :) Cheers Frederic ________________________________________ De : MarLinn [monkleyon at gmail.com] Envoyé : vendredi 6 septembre 2019 14:51 À : PICCA Frederic-Emmanuel; haskell-cafe at haskell.org Objet : Re: [Haskell-cafe] How to write a Monad instance for this type So I discribe a location in the tree, like this with another type quite similar to the first but with only one child per group. This way there is only one dataset extracted. (maybe later, I will discuss about extracting multiple dataset ;). data Hdf5Path sh e = H5RootPath (Hdf5Path sh e) | H5GroupPath ByteString (Hdf5Path sh e) | H5DatasetPath ByteString hdf5p $ group "name" $ group "otherName" $ dataset "myDataset" Is there a better way to do this sort of things. The answer to this depends a lot on how powerful you want your path to be. But the easiest way would probably be to just wrap functions: -- can be used with functions from Data.List data Path a = GroupPath ([Hdf5M a] -> Hdf5M a) (Path a) | … test = hdf5p $ group head $ group (firstOfName "otherName") $ dataset "mydataset" test2 = hdf5p $ group (!! 6) $ group (firstOfName "otherName") $ dataset "mydataset" firstOfName n = fromJust . (find $ hasName n) hasName :: ByteString -> Hdf5M a -> Bool Or if you want more restrictions on which types of paths can be constructed data Path a = GroupPathWithFilter (Hdf5M a -> Bool) (Path a) | GroupPathByIndex Int (Path a) … -- equivalent to "head" test = hdf5p $ group (const True) $ group (hasName "otherName") $ dataset "mydataset" test2 = hdf5p $ groupAt 6 $ group (hasName "otherName") $ dataset "mydataset" Side note: I don't see a reason why the path needs to be recursive if this is all you want. type Path a = [PathSegment a] data PathSegment a = GroupPath (Hdf5M a -> Bool) | … test = hdf5p [group (const True) , group (hasName "otherName") , dataset "mydataset"] What if you want something more like an XPath or a path with wildcards? You can still expand on these ideas easily. type Path a = [PathSegment a] data PathSegment a = GroupPath ([Hdf5M a] -> [Hdf5M a]) | … test = hdf5p [group (pure . head) , group (filter $ hasName "otherName") , dataset "mydataset"] test2 = hdf5p [group (pure . (!! 6)) , group (filter $ hasName "otherName") , dataset "mydataset"] -- or more likely test = hdf5p [group head , groups (hasName "otherName") , dataset "mydataset"] test2 = hdf5p' [group (!! 6) , groups (hasName "otherName") , dataset "mydataset"] -- But these are basically just lists of [Hdf5M a] → [Hdf5M a] functions with one special function -- at the end – which can also be cast as such a function. Therefore something like this would also be possible: newtype Path a = Path [[Hdf5M a] -> [Hdf5M a]] compilePath (Path fs) = filter isDataset . foldl1 (.) fs -- Path can also be turned into a monoid now test = hdf5p $ group head <> groups (hasName "otherName") <> dataset "mydataset" -- which also means it would be prudent to reduce this to newtype Path a = Path ([Hdf5M a] -> [Hdf5M a]) While this final solution looks quite elegant from my POV, there are several directions this can't be extended into as easily as the recursive tree. So this is just a bunch of options from a few minutes of brainstorming, the best option for your particular problem is probably somewhere between these and the ones you already had. Cheers. From carter.schonwald at gmail.com Fri Sep 6 16:07:51 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 6 Sep 2019 12:07:51 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 and cabal-install version In-Reply-To: References: <87zhjwl1mx.fsf@smart-cactus.org> Message-ID: V1 or v2 install? On Mon, Sep 2, 2019 at 11:42 AM George Colpitts wrote: > https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says > > cabal-install users should note that cabal-install-3.0 or later is > required for use with GHC 8.8. > > but this seems wrong or have I done something wrong? > > $ cabal install cabal-install > cabal install cabal-install > ... > > Resolving dependencies... > cabal: Could not resolve dependencies: > [__0] trying: cabal-install-3.0.0.0 (user goal) > [__1] next goal: time (dependency of cabal-install) > [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install => > base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...) > [__1] trying: time-1.9.3 > [__2] next goal: stm (dependency of cabal-install) > [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install => > base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...) > [__2] trying: stm-2.5.0.0 > [__3] next goal: process (dependency of cabal-install) > [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict: cabal-install > => > base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...) > [__3] trying: process-1.6.5.1 > [__4] next goal: pretty (dependency of cabal-install) > [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict: cabal-install > => > base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...) > [__4] trying: pretty-1.1.3.6 > [__5] next goal: network (dependency of cabal-install) > [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict: cabal-install > => > base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...) > [__5] trying: network-3.1.0.1 > [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install) > [__7] next goal: template-haskell (dependency of hackage-security) > [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict: > cabal-install => base>=4.8 && <4.13, template-haskell => > base==4.13.0.0/installed-4.1...) > [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0, > template-haskell-2.13.0.0, template-haskell-2.12.0.0, > template-haskell-2.11.1.0, template-haskell-2.11.0.0, > template-haskell-2.10.0.0, template-haskell-2.9.0.0, > template-haskell-2.8.0.0, > template-haskell-2.7.0.0, template-haskell-2.6.0.0, > template-haskell-2.5.0.0, > template-haskell-2.4.0.1, template-haskell-2.4.0.0, > template-haskell-2.3.0.1, > template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from > non-upgradeable package requires installed instance) > [__7] fail (backjumping, conflict set: cabal-install, hackage-security, > template-haskell) > After searching the rest of the dependency tree exhaustively, these were > the > goals I've had most trouble fulfilling: base, cabal-install, directory, > template-haskell, process, time, network, pretty, hackage-security, > deepseq, > HTTP, stm, cabal-install:lib > > > On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari wrote: > >> >> Hello everyone, >> >> The GHC team is pleased to announce the release candidate for GHC 8.8.1. >> The source distribution, binary distributions, and documentation are >> available at >> >> https://downloads.haskell.org/ghc/8.8.1 >> >> This release is the culmination of over 3000 commits by over one hundred >> contributors and has several new features and numerous bug fixes >> relative to GHC 8.6: >> >> * Visible kind applications are now supported (GHC Proposal #15) >> >> * Profiling now works correctly on 64-bit Windows (although still may >> be problematic on 32-bit Windows due to platform limitations; see >> #15934) >> >> * A new code layout algorithm for amd64's native code generator >> significantly improving the runtime performance of some kernels >> >> * The introduction of a late lambda-lifting pass which may reduce >> allocations significantly for some programs. >> >> * Further work on Trees That Grow, enabling improved code re-use of the >> Haskell AST in tooling >> >> * Users can write `forall` in more contexts (GHC Proposal #7) >> >> * The pattern-match checker is now more precise in the presence of >> strict fields with uninhabited types. >> >> * A comprehensive audit of GHC's memory ordering barriers has been >> performed, resulting in a number of fixes that should significantly >> improve the reliability of programs on architectures with >> weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 >> implementations). >> >> * A long-standing linker limitation rendering GHCi unusable with >> projects with cyclic symbol dependencies has been fixed (#13786) >> >> * Further work on the Hadrian build system >> >> * Countless miscellaneous bug-fixes >> >> Unfortunately, due to a build issue (#17108) found late in the release >> process >> i386 Windows builds are currently unavailable. These will be provided in >> the coming weeks. >> >> As always, if anything looks amiss do let us know. >> >> Happy compiling! >> >> Cheers, >> >> - Ben >> >> >> [1] >> https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shayne.fletcher at daml.com Fri Sep 6 16:48:42 2019 From: shayne.fletcher at daml.com (Shayne Fletcher) Date: Fri, 6 Sep 2019 12:48:42 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 and cabal-install version In-Reply-To: References: <87zhjwl1mx.fsf@smart-cactus.org> Message-ID: I got there by doing, ``` cabal v2-install --installdir=~/.cabal/bin alex cabal v2-install --installdir=~/.cabal/bin happy ``` and things seemed to be going smoothly enough after that. On Fri, Sep 6, 2019 at 12:08 PM Carter Schonwald wrote: > V1 or v2 install? > > On Mon, Sep 2, 2019 at 11:42 AM George Colpitts > wrote: > >> https://www.haskell.org/ghc/blog/20190825-ghc-8.8.1-released.html says >> >> cabal-install users should note that cabal-install-3.0 or later is >> required for use with GHC 8.8. >> >> but this seems wrong or have I done something wrong? >> >> $ cabal install cabal-install >> cabal install cabal-install >> ... >> >> Resolving dependencies... >> cabal: Could not resolve dependencies: >> [__0] trying: cabal-install-3.0.0.0 (user goal) >> [__1] next goal: time (dependency of cabal-install) >> [__1] rejecting: time-1.9.3/installed-1.9... (conflict: cabal-install => >> base>=4.8 && <4.13, time => base==4.13.0.0/installed-4.1...) >> [__1] trying: time-1.9.3 >> [__2] next goal: stm (dependency of cabal-install) >> [__2] rejecting: stm-2.5.0.0/installed-2.5... (conflict: cabal-install => >> base>=4.8 && <4.13, stm => base==4.13.0.0/installed-4.1...) >> [__2] trying: stm-2.5.0.0 >> [__3] next goal: process (dependency of cabal-install) >> [__3] rejecting: process-1.6.5.1/installed-1.6... (conflict: >> cabal-install => >> base>=4.8 && <4.13, process => base==4.13.0.0/installed-4.1...) >> [__3] trying: process-1.6.5.1 >> [__4] next goal: pretty (dependency of cabal-install) >> [__4] rejecting: pretty-1.1.3.6/installed-1.1... (conflict: cabal-install >> => >> base>=4.8 && <4.13, pretty => base==4.13.0.0/installed-4.1...) >> [__4] trying: pretty-1.1.3.6 >> [__5] next goal: network (dependency of cabal-install) >> [__5] rejecting: network-3.1.0.1/installed-CeX... (conflict: >> cabal-install => >> base>=4.8 && <4.13, network => base==4.13.0.0/installed-4.1...) >> [__5] trying: network-3.1.0.1 >> [__6] trying: hackage-security-0.5.3.0 (dependency of cabal-install) >> [__7] next goal: template-haskell (dependency of hackage-security) >> [__7] rejecting: template-haskell-2.15.0.0/installed-2.1... (conflict: >> cabal-install => base>=4.8 && <4.13, template-haskell => >> base==4.13.0.0/installed-4.1...) >> [__7] rejecting: template-haskell-2.15.0.0, template-haskell-2.14.0.0, >> template-haskell-2.13.0.0, template-haskell-2.12.0.0, >> template-haskell-2.11.1.0, template-haskell-2.11.0.0, >> template-haskell-2.10.0.0, template-haskell-2.9.0.0, >> template-haskell-2.8.0.0, >> template-haskell-2.7.0.0, template-haskell-2.6.0.0, >> template-haskell-2.5.0.0, >> template-haskell-2.4.0.1, template-haskell-2.4.0.0, >> template-haskell-2.3.0.1, >> template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from >> non-upgradeable package requires installed instance) >> [__7] fail (backjumping, conflict set: cabal-install, hackage-security, >> template-haskell) >> After searching the rest of the dependency tree exhaustively, these were >> the >> goals I've had most trouble fulfilling: base, cabal-install, directory, >> template-haskell, process, time, network, pretty, hackage-security, >> deepseq, >> HTTP, stm, cabal-install:lib >> >> >> On Mon, Aug 26, 2019 at 6:25 AM Ben Gamari wrote: >> >>> >>> Hello everyone, >>> >>> The GHC team is pleased to announce the release candidate for GHC 8.8.1. >>> The source distribution, binary distributions, and documentation are >>> available at >>> >>> https://downloads.haskell.org/ghc/8.8.1 >>> >>> This release is the culmination of over 3000 commits by over one hundred >>> contributors and has several new features and numerous bug fixes >>> relative to GHC 8.6: >>> >>> * Visible kind applications are now supported (GHC Proposal #15) >>> >>> * Profiling now works correctly on 64-bit Windows (although still may >>> be problematic on 32-bit Windows due to platform limitations; see >>> #15934) >>> >>> * A new code layout algorithm for amd64's native code generator >>> significantly improving the runtime performance of some kernels >>> >>> * The introduction of a late lambda-lifting pass which may reduce >>> allocations significantly for some programs. >>> >>> * Further work on Trees That Grow, enabling improved code re-use of the >>> Haskell AST in tooling >>> >>> * Users can write `forall` in more contexts (GHC Proposal #7) >>> >>> * The pattern-match checker is now more precise in the presence of >>> strict fields with uninhabited types. >>> >>> * A comprehensive audit of GHC's memory ordering barriers has been >>> performed, resulting in a number of fixes that should significantly >>> improve the reliability of programs on architectures with >>> weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 >>> implementations). >>> >>> * A long-standing linker limitation rendering GHCi unusable with >>> projects with cyclic symbol dependencies has been fixed (#13786) >>> >>> * Further work on the Hadrian build system >>> >>> * Countless miscellaneous bug-fixes >>> >>> Unfortunately, due to a build issue (#17108) found late in the release >>> process >>> i386 Windows builds are currently unavailable. These will be provided in >>> the coming weeks. >>> >>> As always, if anything looks amiss do let us know. >>> >>> Happy compiling! >>> >>> Cheers, >>> >>> - Ben >>> >>> >>> [1] >>> https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* , creators of *DAML * -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at  http://www.digitalasset.com/emaildisclaimer.html . If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Fri Sep 6 19:00:21 2019 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 6 Sep 2019 15:00:21 -0400 Subject: [Haskell-cafe] Concurrent reads, ordered writes? Message-ID: <73763097-279F-4162-B7C2-0EC8E26FCD00@gmail.com> I've implemented a solution for this problem, but it seems a bit less clean than it could be, which leaves me wondering if there's a data structure or algorithm specifically for this purpose: We've got multiple concurrent thereads reading items from a (TBQueue A), calling f :: A -> B, and writing to a (TBQueue B). We must, though, write items into the (TBQueue B) in the order that the corresponding As were read (the order they were put in the (TBQueue A)). Are there existing libraries which solve this or a similar problem? Ideally with niceties like configuring whether the pending out-of-order writes block the worker threads, and a way of signalling there's no more work to perform. Thanks! Tom From jeroen at chordify.net Mon Sep 9 08:32:50 2019 From: jeroen at chordify.net (Jeroen Bransen) Date: Mon, 9 Sep 2019 10:32:50 +0200 Subject: [Haskell-cafe] Concurrent reads, ordered writes? In-Reply-To: <73763097-279F-4162-B7C2-0EC8E26FCD00@gmail.com> References: <73763097-279F-4162-B7C2-0EC8E26FCD00@gmail.com> Message-ID: <1ce816e8-259b-92a8-760c-9b711eed6b5c@chordify.net> Hello Tom, I am not aware of any specific algorithm or existing package for this purpose, the best that I can come up with is [1]. It works by using two auxillary queues and two main worker threads that have a special task. One of them is the only thread reading from the input queue, thereby avoiding race conditions in the "take an item and store where in the output this element should come"-stage. It creates an MVar for each item, puts that in the job queue together with the input, and puts that in the other auxillary queue as well. The other main worker thread is reading the MVars in order and is the only thread writing to the output queue, thereby again avoiding race conditions. Now the real worker threads only need to read from the auxillary queue where they get the A and and MVar where they write the B. I am not sure whether or not this satisfies your "cleanness" desire, but I believe it has two nice properties which are not so easy to get: 1. The worker threads only do the real work, and are not blocked by other workers still working on earlier items 2. It is not hard to prove that this approach does not lead to deadlocks Regards, Jeroen [1] https://gist.github.com/jbransen/be81d70cfe2a85fe7d2dfbafc00b561c Op 6-9-2019 om 21:00 schreef amindfv at gmail.com: > I've implemented a solution for this problem, but it seems a bit less clean than it could be, which leaves me wondering if there's a data structure or algorithm specifically for this purpose: > > We've got multiple concurrent thereads reading items from a (TBQueue A), calling f :: A -> B, and writing to a (TBQueue B). We must, though, write items into the (TBQueue B) in the order that the corresponding As were read (the order they were put in the (TBQueue A)). > > Are there existing libraries which solve this or a similar problem? Ideally with niceties like configuring whether the pending out-of-order writes block the worker threads, and a way of signalling there's no more work to perform. > > Thanks! > Tom > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From amindfv at gmail.com Mon Sep 9 15:30:38 2019 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 9 Sep 2019 11:30:38 -0400 Subject: [Haskell-cafe] Concurrent reads, ordered writes? In-Reply-To: <1ce816e8-259b-92a8-760c-9b711eed6b5c@chordify.net> References: <73763097-279F-4162-B7C2-0EC8E26FCD00@gmail.com> <1ce816e8-259b-92a8-760c-9b711eed6b5c@chordify.net> Message-ID: Hi Jeroen - thanks! I hadn't heard from anyone so over the weekend I sketched up an early version of a library for this purpose: https://hackage.haskell.org/package/orderly-workers A few decisions you and I made are the same (a thread each for input and output chans to avoid race conditions, MVars for finished work so worker threads aren't blocked waiting for their "turn" at the output). In other ways our code is different and I'm looking forward to digging into differences! (For example, I already see a place I should be forcing strictness instead of assuming it'll be forced in user code). For the use-case orderly-workers was designed for, it's got the task from ~6 mins to ~2 mins with 5 worker threads. I'm happy with this, as the producer and consumer processes are also doing substantial work. Open to any comments/criticism of the library. Thanks! Tom > El 9 sept 2019, a las 04:32, Jeroen Bransen escribió: > > Hello Tom, > > I am not aware of any specific algorithm or existing package for this > purpose, the best that I can come up with is [1]. It works by using two > auxillary queues and two main worker threads that have a special task. > One of them is the only thread reading from the input queue, thereby > avoiding race conditions in the "take an item and store where in the > output this element should come"-stage. It creates an MVar for each > item, puts that in the job queue together with the input, and puts that > in the other auxillary queue as well. The other main worker thread is > reading the MVars in order and is the only thread writing to the output > queue, thereby again avoiding race conditions. Now the real worker > threads only need to read from the auxillary queue where they get the A > and and MVar where they write the B. > > I am not sure whether or not this satisfies your "cleanness" desire, but > I believe it has two nice properties which are not so easy to get: > 1. The worker threads only do the real work, and are not blocked by > other workers still working on earlier items > 2. It is not hard to prove that this approach does not lead to deadlocks > > Regards, > Jeroen > > > [1] https://gist.github.com/jbransen/be81d70cfe2a85fe7d2dfbafc00b561c > > Op 6-9-2019 om 21:00 schreef amindfv at gmail.com: >> I've implemented a solution for this problem, but it seems a bit less clean than it could be, which leaves me wondering if there's a data structure or algorithm specifically for this purpose: >> >> We've got multiple concurrent thereads reading items from a (TBQueue A), calling f :: A -> B, and writing to a (TBQueue B). We must, though, write items into the (TBQueue B) in the order that the corresponding As were read (the order they were put in the (TBQueue A)). >> >> Are there existing libraries which solve this or a similar problem? Ideally with niceties like configuring whether the pending out-of-order writes block the worker threads, and a way of signalling there's no more work to perform. >> >> Thanks! >> Tom >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 gabriel.rodriguez at udc.es Mon Sep 9 15:33:09 2019 From: gabriel.rodriguez at udc.es (=?Windows-1252?Q?Gabriel_Rodr=EDguez_=C1lvarez?=) Date: Mon, 9 Sep 2019 15:33:09 +0000 Subject: [Haskell-cafe] [CC2020] 2nd CFP for the ACM SIGPLAN 2020 International Conference on Compiler Construction In-Reply-To: References: , , Message-ID: ACM SIGPLAN 2020 International Conference on Compiler Construction (CC'20) co-located with CGO, PPoPP and HPCA San Diego, CA, USA February 22 - 23, 2020 https://conf.researchr.org/home/CC-2020 The ACM SIGPLAN 2020 International Conference on Compiler Construction (CC 2020) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input programs that describe how a system operates, including traditional compiler construction as a special case. Original contributions are solicited on the topics of interest which include, but are not limited to: - Compilation and interpretation techniques, including program representation, analysis, and transformation; code generation, optimization, and synthesis; the verification thereof - Run-time techniques, including memory management, virtual machines, and dynamic and just-in-time compilation - Programming tools, including refactoring editors, checkers, verifiers, compilers, debuggers, and profilers - Techniques for specific domains, such as secure, parallel, distributed, embedded or mobile environments - Design and implementation of novel language constructs, programming models, and domain-specific languages CC 2020 is the 29th edition of the conference. From this year onwards, CC is an ACM SIGPLAN conference and will implement guidelines and procedures recommended by SIGPLAN https://www.sigplan.org. ================================================================================================= To subscribe to the CC announce mailing list, see cc_conference_announce at googlegroups.com To subscribe to the CC announce Twitter account, see @cc2020conf (https://twitter.com/cc2020conf) ================================================================================================= IMPORTANT DATES Abstract Submission: 23 October 2019 Paper Submission : 30 October 2019 Rebuttal : 4-6 December 2019 Artifact Submission: 13 December 2019 Author Notification: 24 December 2019 Final papers due : 15 January 2020 Conference : 22–23 February 2020 All submissions must be made electronically through the conference web site and include an abstract (100–400 words), author contact information, the full list of authors and their affiliations. Full paper submissions must be in PDF formatted printable on both A4 and US letter size paper. All papers must be prepared in ACM Conference Format using the 2-column acmart format. Papers should contain a maximum of 10 pages of text (in a typeface no smaller than 10 point) or figures, NOT INCLUDING references. There is no page limit for references and they must include the name of all authors (not {et al.}). Appendices are not allowed, but the authors may submit supplementary material, such as proofs or source code; all supplementary material must be in PDF or ZIP format. Looking at supplementary material is at the discretion of the reviewers. Submission is double blind and authors will need to identify any potential conflicts of interest with PC, as defined here: http://www.sigplan.org/Resources/Policies/Review/ (ACM SIGPLAN policy). Authors are encouraged to submit their artifacts for the Artifact Evaluation (AE). The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. To ease the organization of the AE committee, we kindly ask authors to submit their artifact at the latest 10 days after the rebuttal. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information will be made available on the CC AE web page. Deadlines expire at midnight anywhere on earth. ORGANIZERS General Chair Louis-Noel Pouchet Colorado State University Program Chair Alexandra Jimborean Uppsala University Artifact Evaluation Chairs Michel Steuwer University of Glasgow Martin Kong University of Oklahoma Publicity Chair Gabriel Rodriguez University of A Coruna Web Chair Mihail Popov Uppsala University Steering Committee Bjorn Franke University of Edinburgh Sebastian Hack Saarland University Manuel Hermenegildo IMDEA SW Institute and Technical U. of Madrid Peng Wu Huawei America Research Lab Ayal Zaks Intel and Technion, Israel Jingling Xue University of New South Wales, Australia Christophe Dubach University of Edinburgh Nelson J. Amaral University of Alberta Milind Kulkarni Purdue University Program Committee Apan Qasem AMD/Texas State University Bernhard Scholz University of Sydney Bettina Heim Microsoft Bilha Mendelson Optitura Brian Demsky UC Irvine Changhee Jung Virginia Tech Christian Schulte KTH EJ Park Los Alamos National Laboratory Delphine Demange Inria Dongyoon Lee Virginia Tech Fernando Magno Quintao Pereira UFMG Brazil Haowei Wu Google Manuel Hermenegildo IMDEA and T.U. Madrid Matin Hashemi Sharif University of Technology Michel Steuwer University of Glasgow Mila Dalla Preda University of Verona Nelson J. Amaral University of Alberta Philippe Clauss University of Strasbourg Pavlos Petoumenos University of Edinburgh Rumyana Neykova Brunel London Santosh Nagarakatte Rutgers University Sebastian Hack University of Saarland Tomofumi Yuki Inria Xu Liu College of William and Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Mon Sep 9 19:26:24 2019 From: alexander.vershilov at gmail.com (Alexander Vershilov) Date: Mon, 9 Sep 2019 22:26:24 +0300 Subject: [Haskell-cafe] Concurrent reads, ordered writes? In-Reply-To: References: <73763097-279F-4162-B7C2-0EC8E26FCD00@gmail.com> <1ce816e8-259b-92a8-760c-9b711eed6b5c@chordify.net> Message-ID: Hello, it's possible to create no additional threads and return values via TBQueue (TMVar a). Then thread that reads replies can block on getting the result from the first thread, while other workers are working. Here is a basic example: https://github.com/qnikst/haskell-fun/blob/cdaf070758fd9b61b37582f06f44d284c6c3b824/jobs/Main.hs But this very naive and I didn't even try to do anything about exceptions asynchronous or not. -- Best wishes, Alexander. > On 9 Sep 2019, at 18:30, amindfv at gmail.com wrote: > > Hi Jeroen - thanks! I hadn't heard from anyone so over the weekend I sketched up an early version of a library for this purpose: > > https://hackage.haskell.org/package/orderly-workers > > A few decisions you and I made are the same (a thread each for input and output chans to avoid race conditions, MVars for finished work so worker threads aren't blocked waiting for their "turn" at the output). In other ways our code is different and I'm looking forward to digging into differences! (For example, I already see a place I should be forcing strictness instead of assuming it'll be forced in user code). > > For the use-case orderly-workers was designed for, it's got the task from ~6 mins to ~2 mins with 5 worker threads. I'm happy with this, as the producer and consumer processes are also doing substantial work. > > Open to any comments/criticism of the library. > > Thanks! > Tom > >> El 9 sept 2019, a las 04:32, Jeroen Bransen escribió: >> >> Hello Tom, >> >> I am not aware of any specific algorithm or existing package for this >> purpose, the best that I can come up with is [1]. It works by using two >> auxillary queues and two main worker threads that have a special task. >> One of them is the only thread reading from the input queue, thereby >> avoiding race conditions in the "take an item and store where in the >> output this element should come"-stage. It creates an MVar for each >> item, puts that in the job queue together with the input, and puts that >> in the other auxillary queue as well. The other main worker thread is >> reading the MVars in order and is the only thread writing to the output >> queue, thereby again avoiding race conditions. Now the real worker >> threads only need to read from the auxillary queue where they get the A >> and and MVar where they write the B. >> >> I am not sure whether or not this satisfies your "cleanness" desire, but >> I believe it has two nice properties which are not so easy to get: >> 1. The worker threads only do the real work, and are not blocked by >> other workers still working on earlier items >> 2. It is not hard to prove that this approach does not lead to deadlocks >> >> Regards, >> Jeroen >> >> >> [1] https://gist.github.com/jbransen/be81d70cfe2a85fe7d2dfbafc00b561c >> >> Op 6-9-2019 om 21:00 schreef amindfv at gmail.com: >>> I've implemented a solution for this problem, but it seems a bit less clean than it could be, which leaves me wondering if there's a data structure or algorithm specifically for this purpose: >>> >>> We've got multiple concurrent thereads reading items from a (TBQueue A), calling f :: A -> B, and writing to a (TBQueue B). We must, though, write items into the (TBQueue B) in the order that the corresponding As were read (the order they were put in the (TBQueue A)). >>> >>> Are there existing libraries which solve this or a similar problem? Ideally with niceties like configuring whether the pending out-of-order writes block the worker threads, and a way of signalling there's no more work to perform. >>> >>> Thanks! >>> Tom >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 athas at sigkill.dk Tue Sep 10 18:53:00 2019 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 10 Sep 2019 20:53:00 +0200 Subject: [Haskell-cafe] Taking over regex-base on Hackage Message-ID: <877e6gkmpf.fsf@sigkill.dk> regex-base is at the bottom of the regex-* package hierarchy and has remarkably remained unchanged and working since the last release in 2010. Alas, the MonadFail change in GHC 8.8 breaks it and the maintainer, Christopher Kuklewicz, seems to have been absent for a while. Most of his other packages have long since been taken over by others. I would like to take over regex-base in order to patch it to work with GHC 8.8. -- \ Troels /\ Henriksen From danburton.email at gmail.com Tue Sep 10 18:59:59 2019 From: danburton.email at gmail.com (Dan Burton) Date: Tue, 10 Sep 2019 14:59:59 -0400 Subject: [Haskell-cafe] Taking over regex-base on Hackage In-Reply-To: <877e6gkmpf.fsf@sigkill.dk> References: <877e6gkmpf.fsf@sigkill.dk> Message-ID: You might want to coordinate with the other proposed takeover. https://mail.haskell.org/pipermail/libraries/2019-September/029927.html -- Dan Burton On Tue, Sep 10, 2019 at 2:53 PM Troels Henriksen wrote: > regex-base is at the bottom of the regex-* package hierarchy and has > remarkably remained unchanged and working since the last release in > 2010. Alas, the MonadFail change in GHC 8.8 breaks it and the > maintainer, Christopher Kuklewicz, seems to have been absent for a > while. Most of his other packages have long since been taken over by > others. I would like to take over regex-base in order to patch it to > work with GHC 8.8. > > -- > \ Troels > /\ Henriksen > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 hannelitaa at gmail.com Wed Sep 11 11:52:58 2019 From: hannelitaa at gmail.com (Hanneli Tavante) Date: Wed, 11 Sep 2019 08:52:58 -0300 Subject: [Haskell-cafe] [POPL2020] Call for student volunteers Message-ID: Hello! The call for Student Volunteers at POPL2020 is opened until October 17th! The 2020 edition will be in New Orleans, USA, January19th-25th. More information here: https://popl20.sigplan.org/attending/students We encourage all the students to apply - with or without experience, local and non-local, undergrads and graduate students. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Thu Sep 12 08:15:55 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Thu, 12 Sep 2019 08:15:55 +0000 Subject: [Haskell-cafe] parallele tolistM of the pipes module Message-ID: Hello, I would like to know how to write a parallele version of the pipes function: toListM :: Monad m => Producer a m () -> m [a] toListM = fold step begin done where step x a = x . (a:) begin = id done x = x [] {-# INLINABLE toListM #-} I want to extract all the a from th epipes but concurrently. is it possible ? Cheers Frederic From vamchale at gmail.com Sun Sep 15 19:45:47 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Sun, 15 Sep 2019 14:45:47 -0500 Subject: [Haskell-cafe] [ANN] lzlib bindings in Haskell Message-ID: Hi all, I have released a library containing a high-level API for lzlib  (and bindings to the full lzlib), viz. http://hackage.haskell.org/package/lzlib Cheers, Vanessa McHale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From hilco.wijbenga at gmail.com Mon Sep 16 00:28:20 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sun, 15 Sep 2019 17:28:20 -0700 Subject: [Haskell-cafe] Default "type" in type class Message-ID: Hi all, I'm trying to create a "HasToList" type class. It starts off really simple: class HasToList collection where toList ∷ collection element → [element] instance HasToList Set where toList = Data.Set.toList Unfortunately, this breaks down with Data.EnumSet.EnumSet. So instance HasToList EnumSet where toList = Data.EnumSet.toList doesn't compile and I could not find a way to add "Enum a =>" to either the instance or "toList". (Well, not without making the compiler upset.) With the aid of ConstraintKinds and TypeFamilies (and not much understanding on my end, obviously) I created class HasToList collection where type Requirement collection element :: Constraint toList ∷ Requirement collection element => collection element → [element] instance HasToList Set where type Requirement Set a = () toList = Data.Set.toList instance HasToList EnumSet where type Requirement EnumSet a = Enum a toList = Data.EnumSet.toList This works but now I have to add the constraint to every instance even though only a tiny minority actually need it. Is there a way to add a default "type implementation"? I tried the obvious type Requirement collection element :: Constraint = () and type Requirement collection element :: Constraint type Requirement collection element :: Constraint = () but neither compiles. Another problem is that the compiler can't compile something like this: isteps ∷ HasToList collection ⇒ collection String → [(Int, String)] isteps steps = Data.List.Index.indexed (toList steps) because it doesn't know which constraint to apply ("Could not deduce: Requirement hasToList String"). That seems fair but also irrelevant at this point. I feel like this is all far too complicated for what I'm trying to accomplish. :-) While I would like to have an answer to the questions above, I guess what I really want is a simpler way to implement HasToList. Cheers, Hilco From hilco.wijbenga at gmail.com Mon Sep 16 02:00:50 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sun, 15 Sep 2019 19:00:50 -0700 Subject: [Haskell-cafe] Default "type" in type class In-Reply-To: References: Message-ID: On Sun, Sep 15, 2019 at 5:28 PM Hilco Wijbenga wrote: > > Hi all, > > I'm trying to create a "HasToList" type class. It starts off really simple: > > class HasToList collection where > toList ∷ collection element → [element] > > instance HasToList Set where > toList = Data.Set.toList > > Unfortunately, this breaks down with Data.EnumSet.EnumSet. So > > instance HasToList EnumSet where > toList = Data.EnumSet.toList > > doesn't compile and I could not find a way to add "Enum a =>" to > either the instance or "toList". (Well, not without making the > compiler upset.) > > With the aid of ConstraintKinds and TypeFamilies (and not much > understanding on my end, obviously) I created > > class HasToList collection where > type Requirement collection element :: Constraint > toList ∷ Requirement collection element => collection element > → [element] > > instance HasToList Set where > type Requirement Set a = () > toList = Data.Set.toList > > instance HasToList EnumSet where > type Requirement EnumSet a = Enum a > toList = Data.EnumSet.toList > > This works but now I have to add the constraint to every instance even > though only a tiny minority actually need it. Is there a way to add a > default "type implementation"? > > I tried the obvious > > type Requirement collection element :: Constraint = () > > and > > type Requirement collection element :: Constraint > type Requirement collection element :: Constraint = () > > but neither compiles. > > Another problem is that the compiler can't compile something like this: > > isteps ∷ HasToList collection ⇒ collection String → [(Int, String)] > isteps steps = Data.List.Index.indexed (toList steps) > > because it doesn't know which constraint to apply ("Could not deduce: > Requirement hasToList String"). That seems fair but also irrelevant at > this point. > > I feel like this is all far too complicated for what I'm trying to > accomplish. :-) While I would like to have an answer to the questions > above, I guess what I really want is a simpler way to implement > HasToList. > > Cheers, > Hilco This: class HasToList collection element where toList ∷ collection element -> [element] instance HasToList Set element where toList = Data.Set.toList instance Enum element => HasToList EnumSet where toList = Data.EnumSet.toList compiles fine, of course. Strange, I thought I had tried that. From Graham.Hutton at nottingham.ac.uk Mon Sep 16 08:32:53 2019 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 16 Sep 2019 08:32:53 +0000 Subject: [Haskell-cafe] MPC 2019 - final call for participation Message-ID: Dear all, Final call for participation for the Mathematics of Program Construction (MPC) conference in Portugal. MPC 2019 will feature 15 research papers and 4 keynotes, and is co-located with Formal Methods 2019 and many other events. See you in Porto! https://tinyurl.com/MPC-Porto Best wishes, Graham Hutton Program Chair, MPC 2019 ====================================================================== *** FINAL CALL FOR PARTICIPATION -- MPC 2019 *** 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== PROGRAM: https://tinyurl.com/yxvvc5vb ACCEPTED PAPERS: https://tinyurl.com/yyuhy8ze REGISTRATION AND TRAVEL: https://tinyurl.com/y4uetlsr KEYNOTE SPEAKERS: Assia Mahboubi (MPC) INRIA, France Annabelle McIver (MPC) Macquarie University, Australia Tony Hoare (UTP) Oxford University, UK Shriram Krishnamurthi (FM) Brown University, USA BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, USA Gabriele Keller Utrecht University, The Netherlands Ekaterina Komendantskaya Heriot-Watt University, UK Chris Martens North Carolina State University, USA Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK For any queries about the program please contact the program chair, Graham Hutton . CONFERENCE VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISER: José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira . ====================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From hesselink at gmail.com Mon Sep 16 09:05:36 2019 From: hesselink at gmail.com (Erik Hesselink) Date: Mon, 16 Sep 2019 11:05:36 +0200 Subject: [Haskell-cafe] Default "type" in type class In-Reply-To: References: Message-ID: You can also define a default type family instance to the class declaration: class HasToList collection where type Requirement collection element :: Constraint type Requirement collection element = () Regards, Erik On Mon, 16 Sep 2019 at 04:02, Hilco Wijbenga wrote: > On Sun, Sep 15, 2019 at 5:28 PM Hilco Wijbenga > wrote: > > > > Hi all, > > > > I'm trying to create a "HasToList" type class. It starts off really > simple: > > > > class HasToList collection where > > toList ∷ collection element → [element] > > > > instance HasToList Set where > > toList = Data.Set.toList > > > > Unfortunately, this breaks down with Data.EnumSet.EnumSet. So > > > > instance HasToList EnumSet where > > toList = Data.EnumSet.toList > > > > doesn't compile and I could not find a way to add "Enum a =>" to > > either the instance or "toList". (Well, not without making the > > compiler upset.) > > > > With the aid of ConstraintKinds and TypeFamilies (and not much > > understanding on my end, obviously) I created > > > > class HasToList collection where > > type Requirement collection element :: Constraint > > toList ∷ Requirement collection element => collection element > > → [element] > > > > instance HasToList Set where > > type Requirement Set a = () > > toList = Data.Set.toList > > > > instance HasToList EnumSet where > > type Requirement EnumSet a = Enum a > > toList = Data.EnumSet.toList > > > > This works but now I have to add the constraint to every instance even > > though only a tiny minority actually need it. Is there a way to add a > > default "type implementation"? > > > > I tried the obvious > > > > type Requirement collection element :: Constraint = () > > > > and > > > > type Requirement collection element :: Constraint > > type Requirement collection element :: Constraint = () > > > > but neither compiles. > > > > Another problem is that the compiler can't compile something like this: > > > > isteps ∷ HasToList collection ⇒ collection String → [(Int, String)] > > isteps steps = Data.List.Index.indexed (toList steps) > > > > because it doesn't know which constraint to apply ("Could not deduce: > > Requirement hasToList String"). That seems fair but also irrelevant at > > this point. > > > > I feel like this is all far too complicated for what I'm trying to > > accomplish. :-) While I would like to have an answer to the questions > > above, I guess what I really want is a simpler way to implement > > HasToList. > > > > Cheers, > > Hilco > > This: > > class HasToList collection element where > toList ∷ collection element -> [element] > > instance HasToList Set element where > toList = Data.Set.toList > > instance Enum element => HasToList EnumSet where > toList = Data.EnumSet.toList > > compiles fine, of course. > > Strange, I thought I had tried that. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Mon Sep 16 19:08:01 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 16 Sep 2019 21:08:01 +0200 Subject: [Haskell-cafe] Class of ordered tuples Message-ID: <7540865B-8CB5-4CAA-84AC-0E83643A5D1B@aatal-apotheke.de> Dear Cafe, I had a lengthy discussion with GHC but so far it won't let me do the following. (Code below is simplified to transport the idea. Type families don't seem to do the trick, either.) A finite set of types A, B, C, ... is totally ordered. This can be expressed e.g. by a multi-parameter type class and type-level natural numbers: instance Index A 0 where instance Index B 1 where etc. Now I want a type class Range and an appropriate set of instance declarations that has A, B, (A,B), (A,C), (A,(B,C)) etc. as members but not (B,A) or (C,C). That is, each type appears at most once and in the defined order. The problem is overlapping instances of the base case with the inductive case. instance Index a n => Range a n n instance (Range a x y, Range b x' y', y < x') => Range (a,b) x y' Then the compiler rightfully complains that someone could write an instance Index (a,b) n which would lead to conflicting instances of Range (a,b) n n. I can not make either of the type classes Index nor Range closed because there will be several of those sets of types. This problem is like smart constructors for ordered lists, but on the type level. Thanks in advance for any hints. Olaf From lysxia at gmail.com Mon Sep 16 19:18:14 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 16 Sep 2019 15:18:14 -0400 Subject: [Haskell-cafe] Class of ordered tuples In-Reply-To: <7540865B-8CB5-4CAA-84AC-0E83643A5D1B@aatal-apotheke.de> References: <7540865B-8CB5-4CAA-84AC-0E83643A5D1B@aatal-apotheke.de> Message-ID: Hi Olaf, > Then the compiler rightfully complains that someone could write an instance Index (a,b) n Do you expect that to happen in practice or is that only a theoretical possibility? (If you could tell GHC that "Index (a, b) n" is forever forbidden, would you?) Have you considered using a constructor to disambiguate pairs (a, b) from singletons: newtype Singleton a = Sg a instance Index a n => Range (Singleton a) n n or using overlapping instances and an explicit equality constraint to ensure that the pair instance is a "substitution instance" of the singleton instance: instance {-# OVERLAPPABLE #-} (Index a n, n ~ n') => Range a n n' or a hybrid approach with both Singleton (instead of overlap) and the explicit equality constraint (for more general type inference): instance (Index a n, n ~ n') => Range (Singleton a) n n' Cheers, Li-yao On 9/16/19 3:08 PM, Olaf Klinke wrote: > Dear Cafe, > > I had a lengthy discussion with GHC but so far it won't let me do the following. (Code below is simplified to transport the idea. Type families don't seem to do the trick, either.) > A finite set of types A, B, C, ... is totally ordered. This can be expressed e.g. by a multi-parameter type class and type-level natural numbers: > > instance Index A 0 where > instance Index B 1 where > etc. > > Now I want a type class Range and an appropriate set of instance declarations that has > A, B, (A,B), (A,C), (A,(B,C)) etc. as members but not > (B,A) or (C,C). That is, each type appears at most once and in the defined order. > > The problem is overlapping instances of the base case with the inductive case. > > instance Index a n => Range a n n > instance (Range a x y, Range b x' y', y < x') => Range (a,b) x y' > > Then the compiler rightfully complains that someone could write an instance Index (a,b) n > which would lead to conflicting instances of Range (a,b) n n. I can not make either of the type classes Index nor Range closed because there will be several of those sets of types. This problem is like smart constructors for ordered lists, but on the type level. > > Thanks in advance for any hints. > Olaf > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From hilco.wijbenga at gmail.com Tue Sep 17 02:44:27 2019 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Mon, 16 Sep 2019 19:44:27 -0700 Subject: [Haskell-cafe] Fusion & Laziness Message-ID: Hi all, I'd like to have a better understanding of fusion and (maybe?) laziness. Let's say I have an (exported) type "data EndResult = ... !(Vector Thing) ..." and an intermediate, unexported type "data IntermediateResult = ... !(Vector Thing) ...". (I suppose it doesn't need to be Vector, it could be Set, or some other data structure that (I imagine) is relatively expensive to map over, unlike, say [].) [To start off, I want to state my, possibly incorrect, understanding of fusion and how it does not (in my expectation) apply to Vector, Set, et cetera. A List can essentially disappear as it's replaced by a loop but a Vector would not: the executing code would create and garbage collect multiple intermediate Vectors before finally returning the end result.] Assume that I need my algorithm to go from initial input to IntermediateResult to subsequent IntermediateResult (a few times) to EndResult. In my case, each subsequent IntermediateResult is a bit smaller than the previous one but that's probably irrelevant. Should I prefer IntermediateResult to be lazy? Should I use [] instead of Vector in the IntermediateResult? What about the functions that actually operate on IntermediateResult, should I prefer to use [] or Vector there? I'm currently able to use Data.Vector.concatMap in some places, is that just as optimized? I realize that the correct answer more than likely is "don't worry about it". And that I'm being very vague. :-) I'm not looking for anything definitive, I'm just hoping to improve my understanding and intuition. What should I consider when thinking about these types of things? If I don't want to create two separate implementations and profile them, are there "obvious" signs one way or another? Cheers, Hilco From lexi.lambda at gmail.com Tue Sep 17 05:30:43 2019 From: lexi.lambda at gmail.com (Alexis King) Date: Tue, 17 Sep 2019 00:30:43 -0500 Subject: [Haskell-cafe] Fusion & Laziness In-Reply-To: References: Message-ID: Disclaimer: I am not an expert on fusion. I think it would help you to understand a little bit about how fusion works, since that makes it easier to develop an intuition for what will/won’t get fused. Here’s a crash course: fusion is implemented via *rewrite rules *, which are user-defined code transformation rules applied by the GHC optimizer. The essence of list fusion is a single rewrite rule defined in the standard library, which rewrites all expressions of the shape foldr k z (build g) to g k z, where build is a function exported by GHC.Exts with the following simple definition: build g = g (:) [] How do you get fusion from that? Here’s the trick: fusable functions that consume lists are implemented using foldr, while ones that build lists are implemented using build. For example, sum could be implemented using foldr like this: sum = foldr (+) 0 …and map (which both consumes and builds) could be expressed like this: map f xs = build (\cons nil -> foldr (\x ys -> f x `cons` ys) nil xs) Now if you write sum (map f xs), and sum and map are both inlined, you’ll get foldr (+) 0 (build (\cons nil -> foldr (\x ys -> f x `cons` ys) nil xs)) which matches the rewrite rule from above and gets rewritten into this: foldr (\x ys -> f x + ys) 0 xs Like magic, the intermediate list has disappeared! The details are a little more complicated than that in practice, but that’s the core idea. Keeping that context in mind, let me answer some of your questions directly. On Sep 16, 2019, at 21:44, Hilco Wijbenga wrote: > [To start off, I want to state my, possibly incorrect, understanding > of fusion and how it does not (in my expectation) apply to Vector, > Set, et cetera. A List can essentially disappear as it's replaced by a > loop but a Vector would not: the executing code would create and > garbage collect multiple intermediate Vectors before finally returning > the end result.] Since fusion is implemented via rewrite rules, which can be defined by anyone, operations on library-defined datatypes *can* be fused if the library author provides the necessary rewrite rules. Other datatypes use different fusion strategies than the foldr/build fusion mentioned above, but the core ideas are similar. For the specific two types you mentioned, Vector operations *do* happen to be fused, while Set operations are not. Set operations are hard to fuse because duplicates need to be removed from the stream, and determining if an element is already in the set fundamentally requires a data structure. You could, however, always convert a set to a list, transform the list with a sequence of fusable operations, and turn it back into a set. Assume that I need my algorithm to go from initial input to > IntermediateResult to subsequent IntermediateResult (a few times) to > EndResult. In my case, each subsequent IntermediateResult is a bit > smaller than the previous one but that's probably irrelevant. > Should I prefer IntermediateResult to be lazy? Should I use [] instead > of Vector in the IntermediateResult? What about the functions that > actually operate on IntermediateResult, should I prefer to use [] or > Vector there? I'm currently able to use Data.Vector.concatMap in some > places, is that just as optimized? Remember that fusion is based on rewrite rules, which are fundamentally transformations on the *code*. Therefore, what matters most is the structure of the code you have written, not what values are flowing around your program at runtime. If a list produced by build ends up being passed to foldr, but GHC couldn’t inline definitions enough to see the *syntactic* pattern foldr k z (build g), then fusion can’t happen. Therefore, if you want fusion to happen, make sure that you use standard list operations to construct or consume lists (e.g. anything in Prelude or Data.List), not manually-written recursive functions that pattern-match on lists (GHC doesn’t know how to fuse those). Make sure GHC is able to inline things enough it will be able to discover chains of fusable operations. If you’re really worried about it, learn to read the GHC Core that can be dumped by the optimizer; this blog post is a good overview of all of these concepts. But your gut is right: you probably just shouldn’t worry about it. Alexis -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman.cheplyaka at tweag.io Tue Sep 17 07:16:44 2019 From: roman.cheplyaka at tweag.io (Roman Cheplyaka) Date: Tue, 17 Sep 2019 10:16:44 +0300 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr Message-ID: Hi all, I'd like to attach a finalizer to FunPtrs (which point to JIT-compiled functions that need to be deallocated). However, the act of running the finalizer (no matter what it does) results in a segfault. Here's a minimal example: {-# LANGUAGE UnboxedTuples, MagicHash #-} import GHC.Exts (FunPtr(..)) import GHC.Base import Foreign.Ptr import System.Mem attachFinalizer :: FunPtr a -> IO () -> IO () attachFinalizer fptr@(FunPtr addr) (IO fin) = IO $ \s0 ->   case mkWeak# addr fptr fin s0 of     (# s1, _ #) -> (# s1, () #) foreign import ccall "wrapper"   mkIO :: IO () -> IO (FunPtr (IO ())) main = do   fptr <- mkIO $ return ()   attachFinalizer fptr $ do     -- The exact contents of the finalizer doesn't seem to matter     putStrLn "+++ finalizer ran"     freeHaskellFunPtr fptr   putStrLn "+++ attached successfully"   performGC Is there a proper way to do this? (GHC 8.6.5) Roman -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrohavoc at gmail.com Tue Sep 17 08:02:23 2019 From: astrohavoc at gmail.com (Shao Cheng) Date: Tue, 17 Sep 2019 16:02:23 +0800 Subject: [Haskell-cafe] Fusion & Laziness In-Reply-To: References: Message-ID: Hi Hilco, To guarantee no intermediate Vectors are ever allocated, you can use the "Bundle" type in https://hackage.haskell.org/package/vector-0.12.0.3/docs/Data-Vector-Fusion-Bundle.html for intermediate values, and only convert the Bundle to a list or vector in the final step. In fact, most interfaces in the vector package are wrapped with "stream" and "unstream" calls under the hood, using Bundle to do the actual transformation, but still exposing the Vector type as input/output, and the composed stream/unstream calls are eliminated by the ghc rewrite rules. Cheers, Cheng On Tue, Sep 17, 2019 at 10:45 AM Hilco Wijbenga wrote: > Hi all, > > I'd like to have a better understanding of fusion and (maybe?) laziness. > > Let's say I have an (exported) type "data EndResult = ... !(Vector > Thing) ..." and an intermediate, unexported type "data > IntermediateResult = ... !(Vector Thing) ...". (I suppose it doesn't > need to be Vector, it could be Set, or some other data structure that > (I imagine) is relatively expensive to map over, unlike, say [].) > > [To start off, I want to state my, possibly incorrect, understanding > of fusion and how it does not (in my expectation) apply to Vector, > Set, et cetera. A List can essentially disappear as it's replaced by a > loop but a Vector would not: the executing code would create and > garbage collect multiple intermediate Vectors before finally returning > the end result.] > > Assume that I need my algorithm to go from initial input to > IntermediateResult to subsequent IntermediateResult (a few times) to > EndResult. In my case, each subsequent IntermediateResult is a bit > smaller than the previous one but that's probably irrelevant. > > Should I prefer IntermediateResult to be lazy? Should I use [] instead > of Vector in the IntermediateResult? What about the functions that > actually operate on IntermediateResult, should I prefer to use [] or > Vector there? I'm currently able to use Data.Vector.concatMap in some > places, is that just as optimized? > > I realize that the correct answer more than likely is "don't worry > about it". And that I'm being very vague. :-) I'm not looking for > anything definitive, I'm just hoping to improve my understanding and > intuition. > > What should I consider when thinking about these types of things? If I > don't want to create two separate implementations and profile them, > are there "obvious" signs one way or another? > > Cheers, > Hilco > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 sylvain at haskus.fr Tue Sep 17 08:05:34 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 17 Sep 2019 10:05:34 +0200 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr In-Reply-To: References: Message-ID: <60928c43-610f-0af9-a887-fa412dbecbe0@haskus.fr> Hi, You can't attach a finalizer to an unpointed type (here Addr#). It explains the segfault. You would have to attach the finalizer to `fptr` but it's quite fragile because GHC may remove the boxing in some cases. Sylvain On 17/09/2019 09:16, Roman Cheplyaka wrote: > > Hi all, > > I'd like to attach a finalizer to FunPtrs (which point to JIT-compiled > functions that need to be deallocated). > > However, the act of running the finalizer (no matter what it does) > results in a segfault. > > Here's a minimal example: > > {-# LANGUAGE UnboxedTuples, MagicHash #-} > import GHC.Exts (FunPtr(..)) > import GHC.Base > import Foreign.Ptr > import System.Mem > > attachFinalizer :: FunPtr a -> IO () -> IO () > attachFinalizer fptr@(FunPtr addr) (IO fin) = IO $ \s0 -> >   case mkWeak# addr fptr fin s0 of >     (# s1, _ #) -> (# s1, () #) > > foreign import ccall "wrapper" >   mkIO :: IO () -> IO (FunPtr (IO ())) > > main = do >   fptr <- mkIO $ return () >   attachFinalizer fptr $ do >     -- The exact contents of the finalizer doesn't seem to matter >     putStrLn "+++ finalizer ran" >     freeHaskellFunPtr fptr >   putStrLn "+++ attached successfully" >   performGC > > Is there a proper way to do this? (GHC 8.6.5) > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 matthewtpickering at gmail.com Tue Sep 17 08:13:14 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 17 Sep 2019 09:13:14 +0100 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr In-Reply-To: References: Message-ID: Hi Roman, I don't believe you can key a weak pointer on an Addr# as it's not a normal heap allocated object. Cheers, Matt On Tue, Sep 17, 2019 at 8:17 AM Roman Cheplyaka wrote: > > Hi all, > > I'd like to attach a finalizer to FunPtrs (which point to JIT-compiled functions that need to be deallocated). > > However, the act of running the finalizer (no matter what it does) results in a segfault. > > Here's a minimal example: > > {-# LANGUAGE UnboxedTuples, MagicHash #-} > import GHC.Exts (FunPtr(..)) > import GHC.Base > import Foreign.Ptr > import System.Mem > > attachFinalizer :: FunPtr a -> IO () -> IO () > attachFinalizer fptr@(FunPtr addr) (IO fin) = IO $ \s0 -> > case mkWeak# addr fptr fin s0 of > (# s1, _ #) -> (# s1, () #) > > foreign import ccall "wrapper" > mkIO :: IO () -> IO (FunPtr (IO ())) > > main = do > fptr <- mkIO $ return () > attachFinalizer fptr $ do > -- The exact contents of the finalizer doesn't seem to matter > putStrLn "+++ finalizer ran" > freeHaskellFunPtr fptr > putStrLn "+++ attached successfully" > performGC > > Is there a proper way to do this? (GHC 8.6.5) > > Roman > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 roman.cheplyaka at tweag.io Tue Sep 17 08:26:55 2019 From: roman.cheplyaka at tweag.io (Roman Cheplyaka) Date: Tue, 17 Sep 2019 11:26:55 +0300 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr In-Reply-To: References: Message-ID: <07f8a85e-d4e3-71f8-ed4a-569b7c34658e@tweag.io> On 17/09/2019 10.50, Shao Cheng wrote: > Hi Roman, > > mkWeak# 's "key" and "value" arguments must both be lifted types, see https://gitlab.haskell.org/ghc/ghc/blob/master/rts/PrimOps.cmm#L699. Your code directly passes the raw Addr# which is not a managed pointer, thus the segfault. Ah, that makes sense — thanks Cheng (and Matthew). I modeled my code after mkWeakIORef, and I assumed that MutVar# and Addr# were in the same category. > I recommend using ForeignPtr in this case. You can add finalizers to ForeignPtr properly, and coerce from ForeignPtr to FunPtr when using it, since they're both containing the Addr# under the hood. I considered doing that, but that'd require quite a bit of code to be constantly converting between ForeignPtr and FunPtr and also converting IO () finalizers to FunPtr (...) finalizers. System.Mem.Weak looks like a better fit because it uses IO () finalizers. I think I'll try attaching a finalizer to ForeignPtr itself and be careful to retain a pointer to ForeignPtr (perhaps with the help of a StablePtr) while it's in use. Or, if that doesn't work, I might implement a reference counter instead. Roman From olf at aatal-apotheke.de Tue Sep 17 08:26:57 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 17 Sep 2019 10:26:57 +0200 (CEST) Subject: [Haskell-cafe] Class of ordered tuples In-Reply-To: References: <7540865B-8CB5-4CAA-84AC-0E83643A5D1B@aatal-apotheke.de> Message-ID: <1108700783.235069.1568708817963@webmail.strato.de> Ah, the trick is to do away with the Index class altogether and use just one instance declaration! Below I use type families because the actual index is irrelevant for the class methods. In contrast, with MultiParamTypeClasses and FunctionalDependencies the user must always explicitly give the two index parameters when invoking the class methods. With the code below, I can simply write > parse A > parse (A,B) But invoking > parse (B,A) results in the error message: Couldn't match type ‘'GT’ with ‘'LT’ {-# LANGUAGE TypeFamilies, DataKinds #-} module OrderedTuple where import GHC.TypeNats -- This will really be be a parser type type P a = a -> String class Range a where type Start a :: Nat type End a :: Nat parse :: P a data A = A deriving (Show) instance Range A where type Start A = 0 type End A = 0 parse = show data B = B deriving (Show) instance Range B where type Start B = 1 type End B = 1 parse = show instance (Range a, Range b, CmpNat (End a) (Start b) ~ 'LT) => Range (a,b) where type Start (a,b) = Start a type End (a,b) = End b parse (a,b) = "("++(parse a)++","++(parse b)++")" > On 16 September 2019 at 21:18 Li-yao Xia wrote: > > > Hi Olaf, > > > Then the compiler rightfully complains that someone could write an > instance Index (a,b) n > > > Do you expect that to happen in practice or is that only a theoretical > possibility? (If you could tell GHC that "Index (a, b) n" is forever > forbidden, would you?) > > > Have you considered using a constructor to disambiguate pairs (a, b) > from singletons: > > newtype Singleton a = Sg a > > instance Index a n => Range (Singleton a) n n > > or using overlapping instances and an explicit equality constraint to > ensure that the pair instance is a "substitution instance" of the > singleton instance: > > instance {-# OVERLAPPABLE #-} (Index a n, n ~ n') => Range a n n' > > or a hybrid approach with both Singleton (instead of overlap) and the > explicit equality constraint (for more general type inference): > > instance (Index a n, n ~ n') => Range (Singleton a) n n' > > Cheers, > Li-yao > > On 9/16/19 3:08 PM, Olaf Klinke wrote: > > Dear Cafe, > > > > I had a lengthy discussion with GHC but so far it won't let me do the following. (Code below is simplified to transport the idea. Type families don't seem to do the trick, either.) > > A finite set of types A, B, C, ... is totally ordered. This can be expressed e.g. by a multi-parameter type class and type-level natural numbers: > > > > instance Index A 0 where > > instance Index B 1 where > > etc. > > > > Now I want a type class Range and an appropriate set of instance declarations that has > > A, B, (A,B), (A,C), (A,(B,C)) etc. as members but not > > (B,A) or (C,C). That is, each type appears at most once and in the defined order. > > > > The problem is overlapping instances of the base case with the inductive case. > > > > instance Index a n => Range a n n > > instance (Range a x y, Range b x' y', y < x') => Range (a,b) x y' > > > > Then the compiler rightfully complains that someone could write an instance Index (a,b) n > > which would lead to conflicting instances of Range (a,b) n n. I can not make either of the type classes Index nor Range closed because there will be several of those sets of types. This problem is like smart constructors for ordered lists, but on the type level. > > > > Thanks in advance for any hints. > > Olaf > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > From matthewtpickering at gmail.com Tue Sep 17 08:40:13 2019 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 17 Sep 2019 09:40:13 +0100 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr In-Reply-To: <07f8a85e-d4e3-71f8-ed4a-569b7c34658e@tweag.io> References: <07f8a85e-d4e3-71f8-ed4a-569b7c34658e@tweag.io> Message-ID: It is my understanding that you can attach a weak pointer to a MurVar# or a ThreadId# because they are implemented using the standard closure layout, ie an info table pointer followed by a payload. Addr# is not represented in the same way. Cheers, Matt On Tue, Sep 17, 2019 at 9:27 AM Roman Cheplyaka wrote: > > On 17/09/2019 10.50, Shao Cheng wrote: > > Hi Roman, > > > > mkWeak# 's "key" and "value" arguments must both be lifted types, see https://gitlab.haskell.org/ghc/ghc/blob/master/rts/PrimOps.cmm#L699. Your code directly passes the raw Addr# which is not a managed pointer, thus the segfault. > Ah, that makes sense — thanks Cheng (and Matthew). I modeled my code after mkWeakIORef, and I assumed that MutVar# and Addr# were in the same category. > > I recommend using ForeignPtr in this case. You can add finalizers to ForeignPtr properly, and coerce from ForeignPtr to FunPtr when using it, since they're both containing the Addr# under the hood. > > I considered doing that, but that'd require quite a bit of code to be constantly converting between ForeignPtr and FunPtr and also converting IO () finalizers to FunPtr (...) finalizers. System.Mem.Weak looks like a better fit because it uses IO () finalizers. > > I think I'll try attaching a finalizer to ForeignPtr itself and be careful to retain a pointer to ForeignPtr (perhaps with the help of a StablePtr) while it's in use. Or, if that doesn't work, I might implement a reference counter instead. > > Roman > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 stefan.wehr at gmail.com Tue Sep 17 12:24:09 2019 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Tue, 17 Sep 2019 14:24:09 +0200 Subject: [Haskell-cafe] [ANN] Call for Contributions: BOB 2020 [Feb 28, Deadline Nov 8] Message-ID: BOB Conference 2020 "What happens when we use what's best for a change?" http://bobkonf.de/2020/cfc.html Berlin, February 28 Call for Contributions Deadline: November 8, 2019 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Speaker Grants BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and database - event-based modelling and architectures - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------- We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://bobcfc.active-group.de/en/bob2020/cfp Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 8, 2019 - Notification: November 22, 2019 - Program: December 6, 2019 Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg -------------- next part -------------- An HTML attachment was scrubbed... URL: From zemyla at gmail.com Tue Sep 17 14:22:49 2019 From: zemyla at gmail.com (Zemyla) Date: Tue, 17 Sep 2019 09:22:49 -0500 Subject: [Haskell-cafe] Attach a finalizer to a FunPtr In-Reply-To: References: <07f8a85e-d4e3-71f8-ed4a-569b7c34658e@tweag.io> Message-ID: Yeah, the restriction on attaching a finalizer is that the value it's attached to has to be boxed, not that it has to be lifted. A ByteArray# with the Addr# stored inside could have a finalizer attached. On Tue, Sep 17, 2019, 03:40 Matthew Pickering wrote: > It is my understanding that you can attach a weak pointer to a MurVar# > or a ThreadId# because they are implemented using the standard closure > layout, ie an info table pointer followed by a payload. Addr# is not > represented in the same way. > > Cheers, > > Matt > > > On Tue, Sep 17, 2019 at 9:27 AM Roman Cheplyaka > wrote: > > > > On 17/09/2019 10.50, Shao Cheng wrote: > > > Hi Roman, > > > > > > mkWeak# 's "key" and "value" arguments must both be lifted types, see > https://gitlab.haskell.org/ghc/ghc/blob/master/rts/PrimOps.cmm#L699. Your > code directly passes the raw Addr# which is not a managed pointer, thus the > segfault. > > Ah, that makes sense — thanks Cheng (and Matthew). I modeled my code > after mkWeakIORef, and I assumed that MutVar# and Addr# were in the same > category. > > > I recommend using ForeignPtr in this case. You can add finalizers to > ForeignPtr properly, and coerce from ForeignPtr to FunPtr when using it, > since they're both containing the Addr# under the hood. > > > > I considered doing that, but that'd require quite a bit of code to be > constantly converting between ForeignPtr and FunPtr and also converting IO > () finalizers to FunPtr (...) finalizers. System.Mem.Weak looks like a > better fit because it uses IO () finalizers. > > > > I think I'll try attaching a finalizer to ForeignPtr itself and be > careful to retain a pointer to ForeignPtr (perhaps with the help of a > StablePtr) while it's in use. Or, if that doesn't work, I might implement a > reference counter instead. > > > > Roman > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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 juan.casanova at ed.ac.uk Tue Sep 17 13:56:36 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Tue, 17 Sep 2019 14:56:36 +0100 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes Message-ID: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> Hello, Pretty simple question here really. I think I've searched for it several times in the past and ended up surprised I did not find an answer. Simple example: sum expressions. One way to define this, one that is comfortable to construct new sums, would be: data Sum = Value Int | Sum Sum Sum Another one, one that is comfortable to check equality with (and other similar things that rely on some notion of normal form), would be (essentially non-empty lists of ints): data Sum = Value Int | Sum Int Sum Now, in many cases you really want to go with the first one for several reasons. You just do not care about normalization in most cases, or maybe you do something more abstract and complicated on top of it that delays the possibility or the sensibility of normalization until something else happens later. So say, that I have the first definition. But then, I want to define equality semantically. An obvious way to go is to produce a function that normalizes Sums (from the first definition) to guarantee that the first sub-sum is always going to be a value, and then check that these two are "equal". And this is where my question comes in, because, of course, the following is infinite recursion: instance Eq Sum where a == b = (normalize a) == (normalize b) What I'd like is to be able to override the default implementation of Eq, but be able to *explicitly* call syntactic equality in calculating it, so that I can do: instance Eq Sum where a == b = (syntacticEq (normalize a) (normalize b)) So, I can see how this is not as straightforward as a function. You cannot correctly produce a polymorphic function syntacticEq :: a -> a -> Bool that works on the SYNTAX of a because it is hidden inside the polymorphic function. What (deriving Eq) does (as I understand it) is to produce an instance at compilation time by looking at how the specific type is presented. But that same compilation time producing could be done to produce it as a function instead of as an implementation of Eq, so that syntacticEq would not be an actual function, but some sort of "macro" that, on compile time, creates the default implementation of equality, but instead of defining it as (==) it defines it as a new function that is only used there. Of course, I can just implement syntactic equality myself explicitly, but when I have to do this for 3, 4, 7 types, some of which have many cases, and a lot of these are polymorphic, so that I have to put all the (Eq arg1, Eq arg2, Eq arg3, ...) => constraints before all of them, it gets old quick. So, is there something like this? Am I saying something really dumb? Of course, I am thinking about equality here, but the same could be said for any standard derivation of classes, like Functor, Show, etc. ALL of them sound like I've wanted to do them at some point in the past. Thanks, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From sylvain at haskus.fr Tue Sep 17 16:03:51 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 17 Sep 2019 18:03:51 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> Message-ID: <6ee07b42-2e08-dbab-26eb-aff8617f4c86@haskus.fr> Hi, The usual (cumbersome) solution would be to use a newtype wrapper. Something like: ``` {-# LANGUAGE DerivingStrategies #-} {-# LANGUAGE DerivingVia #-} import Data.Coerce data Sum    = Value Int    | Sum Sum Sum    deriving stock Eq    deriving stock Show normalize :: Sum -> Sum normalize (Value i)                 = Value i normalize (Sum (Value i) b)         = Sum (Value i) (normalize b) normalize (Sum (Sum x y) b)         = normalize (Sum x (Sum y b)) -- | Normalized sum newtype NSum    = NSum Sum    deriving Show via Sum instance Eq NSum where    NSum a == NSum b = normalize a == normalize b sample1 :: Sum sample1 = Value 10 `Sum` (Value 11 `Sum` Value 12) sample2 :: Sum sample2 = (Value 10 `Sum` Value 11) `Sum` Value 12 sample1' :: NSum sample1' = coerce sample1 sample2' :: NSum sample2' = coerce sample2 test1 = sample1 == sample2 test2 = sample1' == sample2' ``` It would be interesting to combine DerivingVia and DerivingStrategies to allow what you want: ``` data Sum    = Value Int    | Sum Sum Sum    deriving stock Eq via normalize ``` It would require a GHC proposal though (and some more thinking). Sylvain On 17/09/2019 15:56, Juan Casanova wrote: > Hello, > > Pretty simple question here really. I think I've searched for it > several times in the past and ended up surprised I did not find an > answer. > > Simple example: sum expressions. > > One way to define this, one that is comfortable to construct new sums, > would be: > > data Sum = Value Int | Sum Sum Sum > > Another one, one that is comfortable to check equality with (and other > similar things that rely on some notion of normal form), would be > (essentially non-empty lists of ints): > > data Sum = Value Int | Sum Int Sum > > Now, in many cases you really want to go with the first one for > several reasons. You just do not care about normalization in most > cases, or maybe you do something more abstract and complicated on top > of it that delays the possibility or the sensibility of normalization > until something else happens later. So say, that I have the first > definition. > > But then, I want to define equality semantically. An obvious way to go > is to produce a function that normalizes Sums (from the first > definition) to guarantee that the first sub-sum is always going to be > a value, and then check that these two are "equal". > > And this is where my question comes in, because, of course, the > following is infinite recursion: > > instance Eq Sum where a == b = (normalize a) == (normalize b) > > What I'd like is to be able to override the default implementation of > Eq, but be able to *explicitly* call syntactic equality in calculating > it, so that I can do: > > instance Eq Sum where a == b = (syntacticEq (normalize a) (normalize b)) > > So, I can see how this is not as straightforward as a function. You > cannot correctly produce a polymorphic function syntacticEq :: a -> a > -> Bool that works on the SYNTAX of a because it is hidden inside the > polymorphic function. What (deriving Eq) does (as I understand it) is > to produce an instance at compilation time by looking at how the > specific type is presented. But that same compilation time producing > could be done to produce it as a function instead of as an > implementation of Eq, so that syntacticEq would not be an actual > function, but some sort of "macro" that, on compile time, creates the > default implementation of equality, but instead of defining it as (==) > it defines it as a new function that is only used there. > > Of course, I can just implement syntactic equality myself explicitly, > but when I have to do this for 3, 4, 7 types, some of which have many > cases, and a lot of these are polymorphic, so that I have to put all > the (Eq arg1, Eq arg2, Eq arg3, ...) => constraints before all of > them, it gets old quick. > > So, is there something like this? Am I saying something really dumb? > Of course, I am thinking about equality here, but the same could be > said for any standard derivation of classes, like Functor, Show, etc. > ALL of them sound like I've wanted to do them at some point in the past. > > Thanks, > Juan. > From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Tue Sep 17 19:10:38 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 17 Sep 2019 20:10:38 +0100 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> Message-ID: <20190917191038.dejvrardym643qdc@weber> On Tue, Sep 17, 2019 at 02:56:36PM +0100, Juan Casanova wrote: > data Sum = Value Int | Sum Sum Sum [...] > But then, I want to define equality semantically. An obvious way to go is to > produce a function that normalizes Sums (from the first definition) to > guarantee that the first sub-sum is always going to be a value, and then > check that these two are "equal". > > And this is where my question comes in, because, of course, the following is > infinite recursion: > > instance Eq Sum where a == b = (normalize a) == (normalize b) Then why not introduce a datatype which guarantees structurally the that value is normalised and use its Eq? data SumNormalised = ValueNormalised Int | SumNormalised Int Sum deriving Eq normalize :: Sum -> Sum Normalised normalize = instance Eq Sum where a == b = (==) `on` normalize Tom From komendantskaya at gmail.com Wed Sep 18 08:27:16 2019 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Wed, 18 Sep 2019 09:27:16 +0100 Subject: [Haskell-cafe] Practical Aspects of Declarative Languages PADL2020: 2nd CFP Message-ID: 22nd International Symposium on Practical Aspects of Declarative Languages (PADL 2020) https://popl20.sigplan.org/home/PADL-2020,20-21 January 2020, New Orleans, Louisiana, United States Co-located with ACM POPL 2020 ( https://popl20.sigplan.org/) ------------------------------ *Declarative languages* is an umbrella term that include functional, logic, and constraint programming languages. These languages have been successfully applied to many different real-world situations, ranging from database management to active networks to software engineering to decision support systems. New developments in theory and implementation have opened up new application areas. At the same time, applications of declarative languages to challenging problems raise intriguing research questions, such as scalable design and implementation, language extensions for application deployment, and programming environments. PADL is a well-established forum for researchers and practitioners to present original work emphasizing novel applications and implementation techniques for all forms of declarative programming, including functional and logic programming, database and constraint programming, and theorem proving. Topics of interest include, but are not limited to: - Innovative applications of declarative languages - Declarative domain-specific languages and applications - Practical applications of theoretical results - New language developments and their impact on applications - Declarative languages for software engineering - Evaluation of implementation techniques on practical applications - Practical experiences and industrial applications - Novel uses of declarative languages in the classroom - Practical languages and extensions such as probabilistic and reactive languages *PADL 2020* especially welcomes new ideas and approaches pertaining to applications, design and implementation of declarative languages going beyond the scope of the past PADL symposia, for example, advanced database languages and contract languages, as well as verification and theorem proving methods that rely on declarative languages. Important Dates and Submission Guidelines: - Abstracts due: 11 October 2019 - Papers due: 18 October 2019 - Notification to authors: 18 November 2019 - Camera-ready: 29 November 2020 - Symposium dates: 20 - 21 January 2020 Submission instructions can be found at: https://popl20.sigplan.org/home/PADL-2020#Call-for-Papers Looking forward to receiving your submission, PADL19 PC members: https://popl20.sigplan.org/home/PADL-2020#About -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.casanova at ed.ac.uk Wed Sep 18 12:20:34 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Wed, 18 Sep 2019 13:20:34 +0100 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <20190917191038.dejvrardym643qdc@weber> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <20190917191038.dejvrardym643qdc@weber> Message-ID: <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> > Then why not introduce a datatype which guarantees structurally the that > value is normalised and use its Eq? There are many reasons for it. The first two have to do with code clarity. 1. Adding a datatype means that anytime I wish to use the normalized sum from a sum that I know is already normalized, I have to prepend it with the data constructor. This is something that bothers me outside of the equality checking thing, because once is fine, twice is bearable, but when you end up having 5 unavoidable wrappers on everything you want to use, doing pattern matching becomes very annoying. Yes, you can make it less bad by creating intermediate functions that wrap and unwrap, but this does not always solve the problem. 2. If normalization is only used for equality, for instance, (or equality and few other things) then doing this creates unnecessary duplication of types. For example, I have two sum values, which I care not if they have been normalized or they haven't (in fact, I care that they are only normalized if it has been necessary to do so). At some point, I need to check their equality. With your approach, I need to create the normalized sum version and check equality there, and then of course I can continue using the original values, but the point is I have had to create the added type and explicitly construct it to check for equality. Because I can't just do (==) on the non-normalized sum values wherever I need to check for equality, I need to explicitly transform into normalized form and check equality, and at that point the type helps nothing. 3. It reduces reusability. Say that I need to check for equality many times or between a collection of elements (e.g. to sort them). I can normalize them all once in the beginning to avoid normalizing several times. But then, because they are a different type, I cannot apply to them the other operations that I have defined for the non-normalized type. Sure, I can lift them to the normalized type, and even if this is fairly straightforward, it implies duplicating all the functions that I could ever want to use on a pre-normalized sum (which, to be honest, could be basically all of them). Yes, I can always do clever things like create a type class or whatnot. But that is precisely my point: I am having to do complicated things and writing a lot of code for something that is very straightforward: normalize (here, I'll show you how), and then check for equality. Of course, normalize on an already normalized sum is expected to be very quick, so pre-normalizing a sum that we know will be equality checked many times is gonna be both comfortable and easy. But in order to be able to do that, I have to manually implement syntactic equality on the side. Something which GHC *already knows how to do*. And as I said, this is fine for 1 type. Even 3. But for 15 it starts to be a concern. Of course it's not a major concern, but it's one of those things that seem like you could gain a lot from doing so little. Also of course, if efficiency and reducing normalization to the very minimum are critical, then I would end up having a monad in which the value may or may not have already been normalized, and the first time normalization is necessary, I store the normalized value and use that onwards. But this is, again, too much complexity for something that should be simple. Thanks for the reply anyway, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From sylvain at haskus.fr Wed Sep 18 12:50:25 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 18 Sep 2019 14:50:25 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <6ee07b42-2e08-dbab-26eb-aff8617f4c86@haskus.fr> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <6ee07b42-2e08-dbab-26eb-aff8617f4c86@haskus.fr> Message-ID: <1a470bcb-69e1-aa79-f677-4a4befc221b3@haskus.fr> I have created an issue: https://gitlab.haskell.org/ghc/ghc/issues/17210 On 17/09/2019 18:03, Sylvain Henry wrote: > Hi, > > The usual (cumbersome) solution would be to use a newtype wrapper. > Something like: > > ``` > > {-# LANGUAGE DerivingStrategies #-} > {-# LANGUAGE DerivingVia #-} > > import Data.Coerce > > data Sum >    = Value Int >    | Sum Sum Sum >    deriving stock Eq >    deriving stock Show > > normalize :: Sum -> Sum > normalize (Value i)                 = Value i > normalize (Sum (Value i) b)         = Sum (Value i) (normalize b) > normalize (Sum (Sum x y) b)         = normalize (Sum x (Sum y b)) > > > -- | Normalized sum > newtype NSum >    = NSum Sum >    deriving Show via Sum > > instance Eq NSum where >    NSum a == NSum b = normalize a == normalize b > > > sample1 :: Sum > sample1 = Value 10 `Sum` (Value 11 `Sum` Value 12) > > sample2 :: Sum > sample2 = (Value 10 `Sum` Value 11) `Sum` Value 12 > > sample1' :: NSum > sample1' = coerce sample1 > > sample2' :: NSum > sample2' = coerce sample2 > > test1 = sample1 == sample2 > > test2 = sample1' == sample2' > > ``` > > > It would be interesting to combine DerivingVia and DerivingStrategies > to allow what you want: > > ``` > data Sum >    = Value Int >    | Sum Sum Sum >    deriving stock Eq via normalize > > ``` > > It would require a GHC proposal though (and some more thinking). > > Sylvain > > > On 17/09/2019 15:56, Juan Casanova wrote: >> Hello, >> >> Pretty simple question here really. I think I've searched for it >> several times in the past and ended up surprised I did not find an >> answer. >> >> Simple example: sum expressions. >> >> One way to define this, one that is comfortable to construct new >> sums, would be: >> >> data Sum = Value Int | Sum Sum Sum >> >> Another one, one that is comfortable to check equality with (and >> other similar things that rely on some notion of normal form), would >> be (essentially non-empty lists of ints): >> >> data Sum = Value Int | Sum Int Sum >> >> Now, in many cases you really want to go with the first one for >> several reasons. You just do not care about normalization in most >> cases, or maybe you do something more abstract and complicated on top >> of it that delays the possibility or the sensibility of normalization >> until something else happens later. So say, that I have the first >> definition. >> >> But then, I want to define equality semantically. An obvious way to >> go is to produce a function that normalizes Sums (from the first >> definition) to guarantee that the first sub-sum is always going to be >> a value, and then check that these two are "equal". >> >> And this is where my question comes in, because, of course, the >> following is infinite recursion: >> >> instance Eq Sum where a == b = (normalize a) == (normalize b) >> >> What I'd like is to be able to override the default implementation of >> Eq, but be able to *explicitly* call syntactic equality in >> calculating it, so that I can do: >> >> instance Eq Sum where a == b = (syntacticEq (normalize a) (normalize b)) >> >> So, I can see how this is not as straightforward as a function. You >> cannot correctly produce a polymorphic function syntacticEq :: a -> a >> -> Bool that works on the SYNTAX of a because it is hidden inside the >> polymorphic function. What (deriving Eq) does (as I understand it) is >> to produce an instance at compilation time by looking at how the >> specific type is presented. But that same compilation time producing >> could be done to produce it as a function instead of as an >> implementation of Eq, so that syntacticEq would not be an actual >> function, but some sort of "macro" that, on compile time, creates the >> default implementation of equality, but instead of defining it as >> (==) it defines it as a new function that is only used there. >> >> Of course, I can just implement syntactic equality myself explicitly, >> but when I have to do this for 3, 4, 7 types, some of which have many >> cases, and a lot of these are polymorphic, so that I have to put all >> the (Eq arg1, Eq arg2, Eq arg3, ...) => constraints before all of >> them, it gets old quick. >> >> So, is there something like this? Am I saying something really dumb? >> Of course, I am thinking about equality here, but the same could be >> said for any standard derivation of classes, like Functor, Show, etc. >> ALL of them sound like I've wanted to do them at some point in the past. >> >> Thanks, >> Juan. >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From monkleyon at gmail.com Wed Sep 18 12:53:32 2019 From: monkleyon at gmail.com (MarLinn) Date: Wed, 18 Sep 2019 14:53:32 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <20190917191038.dejvrardym643qdc@weber> <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> Message-ID: <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> What about phantom types? {-# LANGUAGE KindSignatures, DataKinds #-} data IsNormalized = Normalized | NotNormalized data Sum (n :: IsNormalized) = Value Int | Sum (Sum n) (Sum n) You could still say instance MyClass (Sum n) where… but you could also write normalizeSum :: Sum NotNormalized -> Sum Normalized -- or even create a class with two inhabitants for this instance Eq (Sum NotNormalized) where (==) = (==) `on` normalizeSum instance Eq (Sum Normalized) where … -- real implementation It's not ideal. For example if you want to sort a list, it would still be better to normalize the whole list before sorting, but at least you could still use the other operators afterwards without a "denormalization" step. So maybe it would help reduce some boilerplate? Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From juan.casanova at ed.ac.uk Wed Sep 18 13:34:36 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Wed, 18 Sep 2019 14:34:36 +0100 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <20190917191038.dejvrardym643qdc@weber> <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> Message-ID: <20190918143436.343741s2ls2krc84@www.staffmail.ed.ac.uk> Quoting MarLinn on Wed, 18 Sep 2019 14:53:32 +0200: > What about phantom types? > > {-# LANGUAGE KindSignatures, DataKinds #-} > data IsNormalized = Normalized | NotNormalized > data Sum (n :: IsNormalized) = Value Int | Sum (Sum n) (Sum n) > > normalizeSum :: Sum NotNormalized -> Sum Normalized -- or even > create a class with two inhabitants for this > instance Eq (Sum NotNormalized) where (==) = (==) `on` normalizeSum > instance Eq (Sum Normalized) where … -- real implementation That looks quite good tbh. I did not know you could do that. Care to explain, are "Normalized" and "NotNormalized" types, data constructors, type families? A combination of them? Of course you still have to write a fair amount of code, but it does look a lot better than what I've been using and what I've seen suggested so far. At least to me. Thanks, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From sylvain at haskus.fr Wed Sep 18 14:46:47 2019 From: sylvain at haskus.fr (Sylvain Henry) Date: Wed, 18 Sep 2019 16:46:47 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <20190917191038.dejvrardym643qdc@weber> <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> Message-ID: <7851bbfd-beba-a889-bac1-ea6e71a8f099@haskus.fr> Nice! Moreover the "real implementation" can use standalone deriving: ``` {-# LANGUAGE DataKinds #-}{-# LANGUAGE KindSignatures #-}{-# LANGUAGE StandaloneDeriving #-}{-# LANGUAGE FlexibleInstances #-}import Data.Functiondata IsNormalized = Normalized | NotNormalizeddata Sum (e :: IsNormalized)   = Value Int   | Sum (Sum e) (Sum e)   deriving (Show)normalize :: Sum a -> Sum Normalizednormalize (Value i)                 = Value inormalize (Sum (Value i) b)         = Sum (Value i) (normalize b)normalize (Sum (Sum x y) b)         = normalize (Sum x (Sum y b))instance Eq (Sum NotNormalized) where   (==) = (==) `on` normalizederiving instance Eq (Sum Normalized)sample1 :: Sum NotNormalizedsample1 = Value 10 `Sum` (Value 11 `Sum` Value 12)sample2 :: Sum NotNormalizedsample2 = (Value 10 `Sum` Value 11) `Sum` Value 12test = sample1 == sample2-- True ``` On 18/09/2019 14:53, MarLinn wrote: > > What about phantom types? > > {-# LANGUAGE KindSignatures, DataKinds #-} > data IsNormalized = Normalized | NotNormalized > data Sum (n :: IsNormalized) = Value Int | Sum (Sum n) (Sum n) > > You could still say > > instance MyClass (Sum n) where… > > but you could also write > > normalizeSum :: Sum NotNormalized -> Sum Normalized -- or even create a class with two inhabitants for this > instance Eq (Sum NotNormalized) where (==) = (==) `on` normalizeSum > instance Eq (Sum Normalized) where … -- real implementation > > It's not ideal. For example if you want to sort a list, it would still > be better to normalize the whole list before sorting, but at least you > could still use the other operators afterwards without a > "denormalization" step. So maybe it would help reduce some boilerplate? > > Cheers, > MarLinn > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Wed Sep 18 17:07:52 2019 From: monkleyon at gmail.com (MarLinn) Date: Wed, 18 Sep 2019 19:07:52 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <20190918143436.343741s2ls2krc84@www.staffmail.ed.ac.uk> References: <20190917145636.37662fln7b2u5pgk@www.staffmail.ed.ac.uk> <20190917191038.dejvrardym643qdc@weber> <20190918132034.10396097pepqv9s8@www.staffmail.ed.ac.uk> <1f53dd21-36c6-1bc5-acfd-952ed44ae9a0@gmail.com> <20190918143436.343741s2ls2krc84@www.staffmail.ed.ac.uk> Message-ID: <6827b0d4-f3d9-b7c6-e9c8-f82cda8fdd60@gmail.com> On 18/09/2019 15.34, Juan Casanova wrote: > Quoting MarLinn on Wed, 18 Sep 2019 14:53:32 +0200: > >> What about phantom types? >> >>     {-# LANGUAGE KindSignatures, DataKinds #-} >>     data IsNormalized = Normalized | NotNormalized >>     data Sum (n :: IsNormalized) = Value Int | Sum (Sum n) (Sum n) >> >>     normalizeSum :: Sum NotNormalized -> Sum Normalized -- or even >> create a class with two inhabitants for this >>     instance Eq (Sum NotNormalized) where (==) = (==) `on` normalizeSum >>     instance Eq (Sum Normalized) where … -- real implementation > > > That looks quite good tbh. I did not know you could do that. Care to > explain, are "Normalized" and "NotNormalized" types, data > constructors, type families? A combination of them? I'm not an expert, so I apologize if I get some of the details wrong. This is all a trick with kinds. Kinds are to types as types are to values. The key is in the two extensions. DataKinds allows you to use data as kinds. So it's possible to use IsNormalized as a kind inhabited by the two types Normalized and NotNormalized in the same ways as you can use the kind * that is inhabited by all "normal" types. Note that types of kind * are also in turn inhabited by values; types of kind IsNormalized are not, so you can only use it and it's types in signatures for now. KindSignatures then allows you to use the signature in the definition of Sum which tells GHC that the first parameter of Sum has this new kind, so only its inhabitants can be used in this place. You can check this by asking GHCI ":kind Sum". It will tell you that "Sum :: IsNormalized -> *", so Sum has a kind that takes a type of kind IsNormalized and returns a kind of the usual type *. Hope that helps. From olf at aatal-apotheke.de Wed Sep 18 19:49:00 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 18 Sep 2019 21:49:00 +0200 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes Message-ID: <7329D625-88C3-472E-8A52-820855F70E83@aatal-apotheke.de> IMHO Tom's suggestion is the way to go, because: (1) The normalized values form a sub-set of the general ones. If you have just one data type for both, then you'll have no static guarantee of normalization, and this will lead to mistakes once you fail to track the normalize calls. (2) Since the normalized values are a sub-set, coercing a normalized value back into the super-type is cheap. (3) Two distinct types guarantee that you won't do the same work twice. Your proposal of (==) `on` normalize will re-calculate the normalization every time you call (==), if no memoization happens. (4) The existing machinery of the compiler suffices to do what you want. If you consider the two forms semantically equal then maybe the non-normalized form should be represented as a thunk. Isn't that what the ShowS type is about? Just my 2 cents. Olaf From juan.casanova at ed.ac.uk Wed Sep 18 21:44:40 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Wed, 18 Sep 2019 22:44:40 +0100 Subject: [Haskell-cafe] Explicitly calling syntactic equality on datatypes In-Reply-To: <7329D625-88C3-472E-8A52-820855F70E83@aatal-apotheke.de> References: <7329D625-88C3-472E-8A52-820855F70E83@aatal-apotheke.de> Message-ID: <20190918224440.16264eo6kg53530g@www.staffmail.ed.ac.uk> > (1) The normalized values form a sub-set of the general ones. If you > have just one data type for both, then you'll have no static > guarantee of normalization, and this will lead to mistakes once you > fail to track the normalize calls. I think this summarizes why we are thinking different things. I realize that "normalization" is a strong term, but do remember I was using this as an example (in my real example it is a form of normalization as well, though). The main thing is that, normalization or however you call it is *not* a main feature of my program. At least not right now. If it were, I'd agree with you that two separate types would be the way to go, and it might in the future. But, it is conceivable that this process is just a way to check equality, and that small operations that are not omnipresent in the rest of the program to be performed before syntactic equality is a pretty usual situation when checking equality for certain types. Therefore, forcing the user to re-implement syntactic equality every one of those times, specially when the compiler already knows how to do this, seems weird. In short, I agree with you that if the concept of normalization is important, separating the types is the right way to go. But this was not the main focus of my original post. I was more interested in saying: there is a small unimportant operation to be performed before checking equality, and thi sis forcing me to reimplement the entire thing. Thanks, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From simon at joyful.com Thu Sep 19 18:05:26 2019 From: simon at joyful.com (Simon Michael) Date: Thu, 19 Sep 2019 11:05:26 -0700 Subject: [Haskell-cafe] How are we helping ? Climate Strike / Earth Strike fri 20, fri 27 Message-ID: <1819EEB4-80EF-4219-93A4-D38CFD956811@joyful.com> Hi all, There's world-wide "strike" event, to raise awareness and stimulate climate action, happening tomorrow and also on friday 27th. Some folks will observe one, the other, both, or the whole period between. We probably don't all share the same awareness or even concern about climate change.. but this is changing rapidly. I wanted to start a discussion and figure out something we could do to support these events.. earlier. But I'm working, preparing for a trip, etc. etc. and "ran out of time". I'll send this now at least. If the site goes green or something, this is the reason. Re the sep 20 and sep 27 events: Thanks to Open Collective, for their leadership and blog post: https://blog.opencollective.com/digital-climate-strike hledger's opencollective, though we're not really using it yet, is opted in for tomorrow: https://opencollective.com/hledger Origin and recent history of this event: https://en.wikipedia.org/wiki/School_strike_for_climate#'Intergenerational'_Global_Climate_Strikes_in_September_2019 There are probably a bunch of "home" sites for this, here are two: https://www.fridaysforfuture.org https://www.earth-strike.com Going forward: I think "How are we helping?" is a standard question every individual, project, institution should be answering. For the hledger project, I've had a few ideas for a long time but haven't managed to manifest them yet. Looking into the near future, some days it feels like working on hledger is a waste of time. Probably many of you can relate. If you are working on anything in this direction I'd love to hear more. Best! -Simon PS I ran out of time even more for crafting a mail to haskell-cafe; cc'ing this anyway. From lemming at henning-thielemann.de Sat Sep 21 18:34:31 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 21 Sep 2019 20:34:31 +0200 (CEST) Subject: [Haskell-cafe] [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations In-Reply-To: <621948562.14027387.1569070778626@mail.yahoo.com> References: <621948562.14027387.1569070778626.ref@mail.yahoo.com> <621948562.14027387.1569070778626@mail.yahoo.com> Message-ID: On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote: > My library that can help to optimize using 'case ... of ...' construction if there are multiple (more than at > least 5) variants. > mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations Isn't this a problem you would solve using Data.Map? From zemyla at gmail.com Sat Sep 21 20:57:27 2019 From: zemyla at gmail.com (Zemyla) Date: Sat, 21 Sep 2019 15:57:27 -0500 Subject: [Haskell-cafe] [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations In-Reply-To: References: <621948562.14027387.1569070778626.ref@mail.yahoo.com> <621948562.14027387.1569070778626@mail.yahoo.com> Message-ID: No, because Data.Map is Ord a => a -> Maybe b. On Sat, Sep 21, 2019, 13:35 Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote: > > > My library that can help to optimize using 'case ... of ...' > construction if there are multiple (more than at > > least 5) variants. > > mm2: The library that can be used for optimization of multiple (Ord a) > => a -> b transformations > > Isn't this a problem you would solve using Data.Map? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Sat Sep 21 21:36:32 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 21 Sep 2019 23:36:32 +0200 (CEST) Subject: [Haskell-cafe] [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations In-Reply-To: References: <621948562.14027387.1569070778626.ref@mail.yahoo.com> <621948562.14027387.1569070778626@mail.yahoo.com> Message-ID: On Sat, 21 Sep 2019, Zemyla wrote: > No, because Data.Map is Ord a => a -> Maybe b. The same applies to the Vector solution ... Or you use lookup as partial function, i.e. (Map.!) :: Map a b -> a -> b. From vamchale at gmail.com Sat Sep 21 23:03:07 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Sat, 21 Sep 2019 18:03:07 -0500 Subject: [Haskell-cafe] Changing a function definition causes an error at link-time Message-ID: <97f83887-e927-b265-e363-710747e03e6b@gmail.com> Hi all, I have a function ft :: CMode -> FileType ft i = toEnum (fromIntegral i) which is used to marshal a function defined with c2hs, viz. {# fun archive_entry_filetype as ^ { `ArchiveEntryPtr' } -> `FileType' ft #} This all works fine under GHC 8.8.1-GHC-8.2.2. When I try to compile the test suite with GHC 8.0.2 I get Linking /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/t/libarchive-test/build/libarchive-test/libarchive-test ... /usr/bin/ld: /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o): in function `rg6i_info': (.text+0x9cd6): undefined reference to `archive_entry_acl_next_w' /usr/bin/ld: /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o): in function `cjVN_info': (.text+0x128c6): undefined reference to `archive_entry_acl_next_w' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) When I define the marshaling function with ft :: CMode -> FileType ft 0 = error "here" ft i = toEnum (fromIntegral i) I can no longer compile the test suite; it fails with a linker error, even with GHC 8.8.1-GHC-8.2.2. I get Linking /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/t/libarchive-test/build/libarchive-test/libarchive-test ... /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o)(.text+0x9d86): error: undefined reference to 'archive_entry_acl_next_w' /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o):function libarchivezm2zi0zi0zi0zminplace_CodecziArchiveziForeignziArchiveEntry_zdwarchiveEntryAclNextW_info: error: undefined reference to 'archive_entry_acl_next_w' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) You can have a look at some of some of the code in this branch here: https://github.com/vmchale/libarchive/blob/ghc-potential-bug/src/Codec/Archive/Foreign/ArchiveEntry.chs#L27 and here: https://github.com/vmchale/libarchive/blob/ghc-potential-bug/src/Codec/Archive/Foreign/ArchiveEntry.hs#L57 Cheers, Vanessa McHale -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From raoknz at gmail.com Sun Sep 22 11:01:55 2019 From: raoknz at gmail.com (Richard O'Keefe) Date: Sun, 22 Sep 2019 23:01:55 +1200 Subject: [Haskell-cafe] How are we helping ? Climate Strike / Earth Strike fri 20, fri 27 In-Reply-To: <1819EEB4-80EF-4219-93A4-D38CFD956811@joyful.com> References: <1819EEB4-80EF-4219-93A4-D38CFD956811@joyful.com> Message-ID: Recommendation 1: Primum non nocere. How do you know whether you are doing harm or not? You have to study. You have to study multiple sides, bearing in mind at all times that you may be wrong, they may be wrong, and their facts may be fictions, and so may yours. I have collected and read over 8000 pages of papers on climate, and as a result, I am not impressed by the climate strikes. In my country, the government already devoutly believes in climate change. We have an actual Minister for Climate Change. In my city, most of the candidates for the upcoming local body election proclaim their belief that Something Needs to be Done, and I will be very impressed if any of them actually has an idea. The climate strikes will certainly achieve nothing *here*, and let's face it, unless and until you get the Big Two (China and India) to do something, the climate strikes will be ineffective posturing that accomplish nothing for the world as a whole. Recommendation 2: In this mailing list, you're talking to people who love programming. There are some exceedingly impressive people here. Those of us with computing skills who are sincere in their fear of climate change and equally sincere in their desire to do something constructive should, well, do something constructive. Here I point to the people who keep on making Haskell a better and better language for parallel programming, making Haskell a serious candidate for at least supporting supercomputing. As one specific example, the supercomputing project I was involved with, until my government decided to pull out, was seriously planning to do a major component of the system software in Python. Python has many virtues, but it would be nice to use a language in which mistakes are more quickly detected. I also point to the people who were making Haskell a usable DSL for GPU crunching. We *desperately* need good tools for supercomputing. I should point to clash-lang.org here too. I would suggest that by making it easier for people to move demanding computations to FPGAs and thereby reduce the amount of electrical power needed, any one Clash person has done more for the planet than any hundred climate strikers. Did I mention that I have three Global Circulation Models on this machine? Of course they have serious problems matching the behaviour of the actual planet. But is that because they have the physics wrong (I was at a talk by a physicist who believed he had found why the Antarctic is gaining ice, contrary to predictions, for example) or because the code is wrong? Let me put it this way: climate modelling code tends to be written by physicists, not by software engineers. They are extremely intelligent people, but they have a higher tolerance for unbeautiful code than I do. I gave a talk earlier this year "Why HPC needs SE" and I was able to find more horrid examples (not all from GCMs, but some of them were) than I had time for. Are you on this mailing list and wanting to do something real about climate change? Then try to get your skills used to improve the craft of supercomputing and climate modelling. Alternatively, there will be a lot of work needed on climate monitoring. Try to get your skills used to improve climate monitoring. I spent a couple of weeks earlier this year helping to write a grant proposal for a precision agriculture/climate monitoring project. We got through round 1; I'll hear about round 2 at the end of the month. THAT will help with the environment whatever the climate does. Recommendation 3: Put climate change activities on things like Change.Org and SumOfUs. (Both of which send me stuff.) That is a much more effective way to reach an audience. On Fri, 20 Sep 2019 at 06:06, Simon Michael wrote: > > Hi all, > > There's world-wide "strike" event, to raise awareness and stimulate climate action, happening tomorrow and also on friday 27th. Some folks will observe one, the other, both, or the whole period between. > > We probably don't all share the same awareness or even concern about climate change.. but this is changing rapidly. I wanted to start a discussion and figure out something we could do to support these events.. earlier. But I'm working, preparing for a trip, etc. etc. and "ran out of time". I'll send this now at least. If the site goes green or something, this is the reason. > > Re the sep 20 and sep 27 events: > > Thanks to Open Collective, for their leadership and blog post: https://blog.opencollective.com/digital-climate-strike > > hledger's opencollective, though we're not really using it yet, is opted in for tomorrow: https://opencollective.com/hledger > > Origin and recent history of this event: https://en.wikipedia.org/wiki/School_strike_for_climate#'Intergenerational'_Global_Climate_Strikes_in_September_2019 > > There are probably a bunch of "home" sites for this, here are two: > https://www.fridaysforfuture.org > https://www.earth-strike.com > > Going forward: > > I think "How are we helping?" is a standard question every individual, project, institution should be answering. > > For the hledger project, I've had a few ideas for a long time but haven't managed to manifest them yet. Looking into the near future, some days it feels like working on hledger is a waste of time. Probably many of you can relate. > > If you are working on anything in this direction I'd love to hear more. > > Best! > -Simon > > PS I ran out of time even more for crafting a mail to haskell-cafe; cc'ing this anyway. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From olf at aatal-apotheke.de Sun Sep 22 19:14:56 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 22 Sep 2019 21:14:56 +0200 Subject: [Haskell-cafe] How are we helping? Climate Strike / Earth Strike fri 20, fri 27 Message-ID: Haskeller working in the renewable energy sector here. Richard O'Keefe has good points, it is hard for the average programmer to have a real impact on climate change. Power consumption of computing equipment, though, is indeed a huge part of our electricity usage, so any progress will be very welcome in this sector. Ask your cloud computing vendor where the data center sources its power. It ought to look like this. [*] My suggestion is to help make renewables the cheapest power source in the market. It already is in some countries, and both China and India are investing massively in wind and solar power, not beause of morale, but beause it is cheap. So go ahead and develop good SCADA software, help the grid operators balance their volatile loads, use deep learning and so-called AI to make maintenance cheaper and life cycles longer. And, but this has nothing to do with programming, keep pestering your first-world governments. Even if your country's share in the global emissions is minute, showing that even industrialized countries can reduce their emissions hopefully leads to others following. But this is only going to work if saving the environment is also cheaper compared to going on as usual. Olaf [*] http://windcores.de/en/homepage/#!/who From bernardobruno at gmail.com Mon Sep 23 08:50:26 2019 From: bernardobruno at gmail.com (Bruno Bernardo) Date: Mon, 23 Sep 2019 10:50:26 +0200 Subject: [Haskell-cafe] FMBC 2019 Call for Participation - Porto (Portugal), October 11 Message-ID: [Please accept our apologies for duplicates.] ===================================================== Call for Participation 1st Workshop on Formal Methods for Blockchains (FMBC) 2019 https://sites.google.com/view/fmbc/home Porto, Portugal, October 11 Part of the 3rd World Congress on Formal Methods http://formalmethods2019.inesctec.pt/ ===================================================== About FMBC ---------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the blockchain. Thus, Smart Contracts can facilitate the economic activity of blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of blockchain so ware. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write smart contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for blockchain technology. Topics include, but are not limited to: * Design and implementation of Smar Contract languages * Formal models of blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for blockchain-specific cryptographic primitives or   protocols * Formal languages for Smart Contracts * Verification of Smart Contracts Invited Speaker -------------------- Ilya Sergey (Yale-NUS College / NUS School of Computing) Contributed papers -------------------------- See the workshop program at: https://sites.google.com/view/fmbc/program Registration ---------------- Registration is shared for all FM events: http://formalmethods2019.inesctec.pt/?page_id=2363 Attending ------------- See the FM webpage at: http://formalmethods2019.inesctec.pt/?page_id=140 Contact ---------- mailto:fmbc19 at easychair.org From juan.casanova at ed.ac.uk Mon Sep 23 19:05:38 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Mon, 23 Sep 2019 20:05:38 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order Message-ID: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Hello again, haskell-cafe. I was trying to implement the Unifiable typeclass from Control.Unification on one of my types, and did so fine, but then realized I needed a Traversable instance. So I thought about it, and concluded: Yes, my type definitely is Traversable, and I implemented Traversable. But then I realized I needed a Foldable instance for that. And then I wasn't so sure anymore. I *can* implement a Foldable instance, but it requires a choice of the order in which my structure is traversed that I don't really want to make? A.k.a: I can think of at least two different ways of implementing Foldable that would give different results if the function passed to foldr was not associative. So I looked online a bit, and it seems this is a topic people have talked about, but maybe not precisely in the context of the order. What I have gathered is that: yes, if a functor is Traversable, then there is at least one way to implement a Foldable in it. And I understand this, but then, I don't really grasp how that works in my specific case. Because my Traversable instance does not make a choice of this order (at least I think so), and I do need to make that choice to implement Foldable (at least I think so), and I don't see how the "default" implementation of foldMap in terms of traverse makes that choice. But the choice must be made somewhere if it is made in the Foldable. So what is going on? Of course, here's the code. My types: data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq My Traversable instance (with comments on intermediate types because otherwise it can get pretty obscure): instance Traversable (SOTermF fn) where traverse f (SOF (ConstF c)) = pure (SOF (ConstF c)) traverse f (SOF (Proj idx)) = pure (SOF (Proj idx)) -- f g :: f b -- map f sargs = [f b] -- CompF :: a -> ([a] -> SOTermPF fn p a) -- (\h -> \ts -> SOF (CompF h ts)) :: ([a] -> SOTermF fn a) -- fmap (\h -> \ts -> SOF (CompF h ts)) (f g) :: f ([b] -> SOTermF fn b) -- traverse :: (aa -> ff bb) -> [aa] -> ff [bb] -- traverse :: (f b -> f b) -> [f b] -> f [b] -- ((fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*>) :: f [b] -> f (SOTermF fn b) -- traverse id (map f sargs) :: f [b] -- (fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*> (traverse id (map f sargs)) :: f (SOTermF fn b) traverse f (SOF (CompF g sargs)) = (fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*> (traverse id (map f sargs)) But to implement Foldable I need to choose an order because in the case where I do have elements under the functor (CompF), I have them in two shapes: The "head" and the "arguments" (the p and the [f] in CompF p [f]). So, of course, the arguments are traversed in the order of the list, but the order that I need to choose is: Do I apply the head first and the arguments later or do I apply the arguments first and the head later? But my traverse seems so natural. Am I making that choice there? Maybe if I made the fmap over the arguments (while traversing the list) instead of over the head, and then did a flipped application of <*>? Does that mean my traverse instance has implicitly assumed that the head will be done first? All of this is really out of curiosity and making sure I know what I'm doing: I will not use foldr on my structure and I'm pretty sure that the traversal that Control.Unification needs is associative. But I don't like seeing arbitrary choices appear out of nowhere in my code, I want to make sure of why I made them. :P Thanks in advance, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From evan at evan-borden.com Mon Sep 23 22:18:34 2019 From: evan at evan-borden.com (Evan Borden) Date: Mon, 23 Sep 2019 17:18:34 -0500 Subject: [Haskell-cafe] ANN: network 3.1.1.0 Message-ID: I'm happy to announce the release of network 3.1.1.0. http://hackage.haskell.org/package/network-3.1.1.0 Changes: - A new API: gracefulClose. #417 Also see Kazu's blog post on the design choices in this function https://kazu-yamamoto.hatenablog.jp/entry/2019/09/20/165939 - touchSocket, unsafeFdSocket: Allow direct access to a socket's file descriptor while providing tools to prevent it from being garbage collected. This also deprecated fdSocket in favor of unsafeFdSocket and withFdSocket. #423 - socketToFd: Duplicates a socket as a file descriptor and closes the source socket. #424 As always thank you to network's contributors. -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Tue Sep 24 07:05:11 2019 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 24 Sep 2019 09:05:11 +0200 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: Hi, Your choice of Traversable must already give you an answer to that question. In fact, if you could implement `Traversable` you can get `Foldable` for free by using `foldMapDefault` [ http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Traversable.html#v:foldMapDefault]. Then you know that both instances "agree" on their behavior. Regards, Alejandro El lun., 23 sept. 2019 a las 21:06, Juan Casanova () escribió: > Hello again, haskell-cafe. > > I was trying to implement the Unifiable typeclass from > Control.Unification on one of my types, and did so fine, but then > realized I needed a Traversable instance. > > So I thought about it, and concluded: Yes, my type definitely is > Traversable, and I implemented Traversable. But then I realized I > needed a Foldable instance for that. > > And then I wasn't so sure anymore. I *can* implement a Foldable > instance, but it requires a choice of the order in which my structure > is traversed that I don't really want to make? A.k.a: I can think of > at least two different ways of implementing Foldable that would give > different results if the function passed to foldr was not associative. > > So I looked online a bit, and it seems this is a topic people have > talked about, but maybe not precisely in the context of the order. > What I have gathered is that: yes, if a functor is Traversable, then > there is at least one way to implement a Foldable in it. And I > understand this, but then, I don't really grasp how that works in my > specific case. Because my Traversable instance does not make a choice > of this order (at least I think so), and I do need to make that choice > to implement Foldable (at least I think so), and I don't see how the > "default" implementation of foldMap in terms of traverse makes that > choice. But the choice must be made somewhere if it is made in the > Foldable. So what is going on? > > Of course, here's the code. My types: > > data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq > newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq > > My Traversable instance (with comments on intermediate types because > otherwise it can get pretty obscure): > > instance Traversable (SOTermF fn) where > traverse f (SOF (ConstF c)) = pure (SOF (ConstF c)) > traverse f (SOF (Proj idx)) = pure (SOF (Proj idx)) > -- f g :: f b > -- map f sargs = [f b] > -- CompF :: a -> ([a] -> SOTermPF fn p a) > -- (\h -> \ts -> SOF (CompF h ts)) :: ([a] -> SOTermF fn a) > -- fmap (\h -> \ts -> SOF (CompF h ts)) (f g) :: f ([b] -> SOTermF > fn b) > -- traverse :: (aa -> ff bb) -> [aa] -> ff [bb] > -- traverse :: (f b -> f b) -> [f b] -> f [b] > -- ((fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*>) :: f [b] -> > f > (SOTermF fn b) > -- traverse id (map f sargs) :: f [b] > -- (fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*> (traverse id > (map > f sargs)) :: f (SOTermF fn b) > traverse f (SOF (CompF g sargs)) = (fmap (\h -> \ts -> SOF (CompF > h > ts)) (f g)) <*> (traverse id (map f sargs)) > > But to implement Foldable I need to choose an order because in the > case where I do have elements under the functor (CompF), I have them > in two shapes: The "head" and the "arguments" (the p and the [f] in > CompF p [f]). So, of course, the arguments are traversed in the order > of the list, but the order that I need to choose is: Do I apply the > head first and the arguments later or do I apply the arguments first > and the head later? But my traverse seems so natural. Am I making that > choice there? Maybe if I made the fmap over the arguments (while > traversing the list) instead of over the head, and then did a flipped > application of <*>? Does that mean my traverse instance has implicitly > assumed that the head will be done first? > > All of this is really out of curiosity and making sure I know what I'm > doing: I will not use foldr on my structure and I'm pretty sure that > the traversal that Control.Unification needs is associative. But I > don't like seeing arbitrary choices appear out of nowhere in my code, > I want to make sure of why I made them. :P > > Thanks in advance, > Juan. > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jamesbtobin at gmail.com Tue Sep 24 07:10:29 2019 From: jamesbtobin at gmail.com (James Tobin) Date: Tue, 24 Sep 2019 08:10:29 +0100 Subject: [Haskell-cafe] JOB | Web Architect (London, UK) Message-ID: Hello, I'm working with an employer that is looking to hire a permanent front end architect to join their London office. You should have experience with Javascript and frameworks such as (but not only) React. Consequently, I had hoped that some members of this mailing list may like to discuss further off-list using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James From byorgey at gmail.com Tue Sep 24 09:56:06 2019 From: byorgey at gmail.com (Brent Yorgey) Date: Tue, 24 Sep 2019 04:56:06 -0500 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: Your implementation of traverse DOES make a choice of order (any implementation must). In particular f <*> x does the effects of f first, and then x. -Brent On Mon, Sep 23, 2019, 2:06 PM Juan Casanova wrote: > Hello again, haskell-cafe. > > I was trying to implement the Unifiable typeclass from > Control.Unification on one of my types, and did so fine, but then > realized I needed a Traversable instance. > > So I thought about it, and concluded: Yes, my type definitely is > Traversable, and I implemented Traversable. But then I realized I > needed a Foldable instance for that. > > And then I wasn't so sure anymore. I *can* implement a Foldable > instance, but it requires a choice of the order in which my structure > is traversed that I don't really want to make? A.k.a: I can think of > at least two different ways of implementing Foldable that would give > different results if the function passed to foldr was not associative. > > So I looked online a bit, and it seems this is a topic people have > talked about, but maybe not precisely in the context of the order. > What I have gathered is that: yes, if a functor is Traversable, then > there is at least one way to implement a Foldable in it. And I > understand this, but then, I don't really grasp how that works in my > specific case. Because my Traversable instance does not make a choice > of this order (at least I think so), and I do need to make that choice > to implement Foldable (at least I think so), and I don't see how the > "default" implementation of foldMap in terms of traverse makes that > choice. But the choice must be made somewhere if it is made in the > Foldable. So what is going on? > > Of course, here's the code. My types: > > data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq > newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq > > My Traversable instance (with comments on intermediate types because > otherwise it can get pretty obscure): > > instance Traversable (SOTermF fn) where > traverse f (SOF (ConstF c)) = pure (SOF (ConstF c)) > traverse f (SOF (Proj idx)) = pure (SOF (Proj idx)) > -- f g :: f b > -- map f sargs = [f b] > -- CompF :: a -> ([a] -> SOTermPF fn p a) > -- (\h -> \ts -> SOF (CompF h ts)) :: ([a] -> SOTermF fn a) > -- fmap (\h -> \ts -> SOF (CompF h ts)) (f g) :: f ([b] -> SOTermF > fn b) > -- traverse :: (aa -> ff bb) -> [aa] -> ff [bb] > -- traverse :: (f b -> f b) -> [f b] -> f [b] > -- ((fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*>) :: f [b] -> > f > (SOTermF fn b) > -- traverse id (map f sargs) :: f [b] > -- (fmap (\h -> \ts -> SOF (CompF h ts)) (f g)) <*> (traverse id > (map > f sargs)) :: f (SOTermF fn b) > traverse f (SOF (CompF g sargs)) = (fmap (\h -> \ts -> SOF (CompF > h > ts)) (f g)) <*> (traverse id (map f sargs)) > > But to implement Foldable I need to choose an order because in the > case where I do have elements under the functor (CompF), I have them > in two shapes: The "head" and the "arguments" (the p and the [f] in > CompF p [f]). So, of course, the arguments are traversed in the order > of the list, but the order that I need to choose is: Do I apply the > head first and the arguments later or do I apply the arguments first > and the head later? But my traverse seems so natural. Am I making that > choice there? Maybe if I made the fmap over the arguments (while > traversing the list) instead of over the head, and then did a flipped > application of <*>? Does that mean my traverse instance has implicitly > assumed that the head will be done first? > > All of this is really out of curiosity and making sure I know what I'm > doing: I will not use foldr on my structure and I'm pretty sure that > the traversal that Control.Unification needs is associative. But I > don't like seeing arbitrary choices appear out of nowhere in my code, > I want to make sure of why I made them. :P > > Thanks in advance, > Juan. > > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 juan.casanova at ed.ac.uk Tue Sep 24 11:12:21 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Tue, 24 Sep 2019 12:12:21 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: <20190924121221.19172xrlcsvi114w@www.staffmail.ed.ac.uk> Quoting Brent Yorgey on Tue, 24 Sep 2019 04:56:06 -0500: > Your implementation of traverse DOES make a choice of order (any > implementation must). In particular f <*> x does the effects of f first, > and then x. > Ahhh, so it's in the applicative that the order choice happens! And I could change it by essentially flipping the function application and so on. That makes sense. Thanks! -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From danburton.email at gmail.com Tue Sep 24 17:00:23 2019 From: danburton.email at gmail.com (Dan Burton) Date: Tue, 24 Sep 2019 10:00:23 -0700 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 is now available In-Reply-To: <87zhjwl1mx.fsf@smart-cactus.org> References: <87zhjwl1mx.fsf@smart-cactus.org> Message-ID: Will base-4.13.0.0 (which ships with ghc 8.8) be uploaded to hackage? -- Dan Burton On Mon, Aug 26, 2019 at 2:25 AM Ben Gamari wrote: > > Hello everyone, > > The GHC team is pleased to announce the release candidate for GHC 8.8.1. > The source distribution, binary distributions, and documentation are > available at > > https://downloads.haskell.org/ghc/8.8.1 > > This release is the culmination of over 3000 commits by over one hundred > contributors and has several new features and numerous bug fixes > relative to GHC 8.6: > > * Visible kind applications are now supported (GHC Proposal #15) > > * Profiling now works correctly on 64-bit Windows (although still may > be problematic on 32-bit Windows due to platform limitations; see > #15934) > > * A new code layout algorithm for amd64's native code generator > significantly improving the runtime performance of some kernels > > * The introduction of a late lambda-lifting pass which may reduce > allocations significantly for some programs. > > * Further work on Trees That Grow, enabling improved code re-use of the > Haskell AST in tooling > > * Users can write `forall` in more contexts (GHC Proposal #7) > > * The pattern-match checker is now more precise in the presence of > strict fields with uninhabited types. > > * A comprehensive audit of GHC's memory ordering barriers has been > performed, resulting in a number of fixes that should significantly > improve the reliability of programs on architectures with > weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 > implementations). > > * A long-standing linker limitation rendering GHCi unusable with > projects with cyclic symbol dependencies has been fixed (#13786) > > * Further work on the Hadrian build system > > * Countless miscellaneous bug-fixes > > Unfortunately, due to a build issue (#17108) found late in the release > process > i386 Windows builds are currently unavailable. These will be provided in > the coming weeks. > > As always, if anything looks amiss do let us know. > > Happy compiling! > > Cheers, > > - Ben > > > [1] > https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Tue Sep 24 20:30:07 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 24 Sep 2019 21:30:07 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: <20190924203007.57x6tthtuyic4our@weber> On Mon, Sep 23, 2019 at 08:05:38PM +0100, Juan Casanova wrote: > data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq > newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq > > My Traversable instance (with comments on intermediate types because > otherwise it can get pretty obscure): Everyone else has made good comments, but to add a little and to be a little more explicit: your data type uses [] so it makes sense to directly inherit the Traversable (and hence Foldable) instance from that. Your instance was a little convoluted. Here's what I would suggest: instance Foldable (SOTermF fn) where foldMap = foldMapDefault instance Traversable (SOTermF fn) where traverse f (SOF (ConstF c)) = pure (SOF (ConstF c)) traverse f (SOF (Proj idx)) = pure (SOF (Proj idx)) traverse f (SOF (CompF g sargs)) = SOF <$> (CompF <$> f g <*> traverse f sargs) From ben at well-typed.com Tue Sep 24 21:22:02 2019 From: ben at well-typed.com (Ben Gamari) Date: Tue, 24 Sep 2019 17:22:02 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 is now available In-Reply-To: References: <87zhjwl1mx.fsf@smart-cactus.org> Message-ID: <87tv91gzk9.fsf@smart-cactus.org> Dan Burton writes: > Will base-4.13.0.0 (which ships with ghc 8.8) be uploaded to hackage? > Yes, although it's currently waiting for someone with maintainer rights for `base`, et al to push them. I have requested access myself although haven't yet heard back. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Tue Sep 24 22:09:08 2019 From: david.feuer at gmail.com (David Feuer) Date: Tue, 24 Sep 2019 18:09:08 -0400 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: On Mon, Sep 23, 2019, 3:05 PM Juan Casanova wrote: My types: > > data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq > Here's a more modular option for the Traversable instance. import Data.Bitraversable import Data.Bifoldable import Control.Applicative import Data.Traversable instance Bifoldable (SOTermPF fn) where bifoldMap = bifoldMapDefault instance Bitraversable (SOTermPF fn) where bitraverse _f _g (ConstF fn) = pure (ConstF fn) bitraverse _f _g (Proj i) = pure (Proj i) bitraverse f g (CompF p fs) = liftA2 CompF (f p) (traverse g fs) instance Foldable (SOTermF fn) where foldMap = foldMapDefault instance Traversable (SOTermF fn) where traverse f (SOF q) = SOF <$> bitraverse f f q > -------------- next part -------------- An HTML attachment was scrubbed... URL: From silvio.frischi at gmail.com Wed Sep 25 06:57:46 2019 From: silvio.frischi at gmail.com (Silvio Frischknecht) Date: Wed, 25 Sep 2019 08:57:46 +0200 Subject: [Haskell-cafe] JOB | Web Architect (London, UK) In-Reply-To: References: Message-ID: <98b627b3-c255-b16a-245e-3b287983cb4f@gmail.com> Off topic? This is the forth such job offer from this email address. From nadine.and.henry at pobox.com Wed Sep 25 14:56:00 2019 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Wed, 25 Sep 2019 09:56:00 -0500 Subject: [Haskell-cafe] Stack overflow with ReadP Message-ID: <23947.32768.327363.40968@gargle.gargle.HOWL> Dear Haskell gurus, There has to be something very simple that I am misunderstanding here. I have tried sticking in trace statement, using the ghci debugger, but it just makes no sense to me. Please tell me what I am missing. Best wishes, Henry Laxen -------------------------------------------------------------------------------- module S where import Text.ParserCombinators.ReadP import Data.Char data Exp = Num Int | Add Exp Exp deriving (Eq, Show) expr :: ReadP Exp expr = do e <- (parseNumber +++ parseAdd) return e parseAdd :: ReadP Exp parseAdd = do e1 <- expr _ <- char '+' e2 <- expr return (Add e1 e2) parseNumber :: ReadP Exp parseNumber = do ds <- (munch1 isDigit) return . Num . read $ ds parse s = let parses = (readP_to_S expr) s in case parses of (p : _) -> fst (last parses) _ -> error "parse error" main = do print $ parse "1" λ> main *** Exception: stack overflow λ> parse "1+2" *** Exception: stack overflow -------------------------------------------------------------------------------- -- Nadine and Henry Laxen The rest is silence Villa Alta #6 Calle Gaviota #10 Never try to teach a pig to sing Chapala It wastes your time +52 (376) 765-3181 And it annoys the pig From jaro.reinders at gmail.com Wed Sep 25 15:05:17 2019 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Wed, 25 Sep 2019 17:05:17 +0200 Subject: [Haskell-cafe] Stack overflow with ReadP In-Reply-To: <23947.32768.327363.40968@gargle.gargle.HOWL> References: <23947.32768.327363.40968@gargle.gargle.HOWL> Message-ID: <1516ac3f-d814-9926-0011-0d35e5480163@gmail.com> Your parseAdd parser is left recursive which causes infinite recursion. Maybe this wikipedia article can help: https://en.wikipedia.org/wiki/Left_recursion#Removing_left_recursion On 25-09-2019 16:56, Henry Laxen wrote: > > Dear Haskell gurus, > > There has to be something very simple that I am misunderstanding here. I have > tried sticking in trace statement, using the ghci debugger, but it just makes > no sense to me. Please tell me what I am missing. > > Best wishes, > Henry Laxen > -------------------------------------------------------------------------------- > > module S where > > import Text.ParserCombinators.ReadP > import Data.Char > > data Exp = Num Int | Add Exp Exp > deriving (Eq, Show) > > expr :: ReadP Exp > expr = do > e <- (parseNumber +++ parseAdd) > return e > > parseAdd :: ReadP Exp > parseAdd = do > e1 <- expr > _ <- char '+' > e2 <- expr > return (Add e1 e2) > > parseNumber :: ReadP Exp > parseNumber = do > ds <- (munch1 isDigit) > return . Num . read $ ds > > parse s = let parses = (readP_to_S expr) s in > case parses of > (p : _) -> fst (last parses) > _ -> error "parse error" > main = do > print $ parse "1" > > λ> main > *** Exception: stack overflow > λ> parse "1+2" > *** Exception: stack overflow > > -------------------------------------------------------------------------------- > From allbery.b at gmail.com Wed Sep 25 15:06:45 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 25 Sep 2019 11:06:45 -0400 Subject: [Haskell-cafe] Stack overflow with ReadP In-Reply-To: <23947.32768.327363.40968@gargle.gargle.HOWL> References: <23947.32768.327363.40968@gargle.gargle.HOWL> Message-ID: This is going to do expr -> parseAdd -> expr -> parseAdd -> ... . You need to factor your parser to avoid this kind of left recursion. And (+++) is going to try both parsers even though the left-hand one succeeds, because it's symmetric. You may want to use (<++) to make it take the left-hand parser when it succeeds without trying the right-hand. On Wed, Sep 25, 2019 at 10:56 AM Henry Laxen wrote: > > Dear Haskell gurus, > > There has to be something very simple that I am misunderstanding here. I > have > tried sticking in trace statement, using the ghci debugger, but it just > makes > no sense to me. Please tell me what I am missing. > > Best wishes, > Henry Laxen > > -------------------------------------------------------------------------------- > > module S where > > import Text.ParserCombinators.ReadP > import Data.Char > > data Exp = Num Int | Add Exp Exp > deriving (Eq, Show) > > expr :: ReadP Exp > expr = do > e <- (parseNumber +++ parseAdd) > return e > > parseAdd :: ReadP Exp > parseAdd = do > e1 <- expr > _ <- char '+' > e2 <- expr > return (Add e1 e2) > > parseNumber :: ReadP Exp > parseNumber = do > ds <- (munch1 isDigit) > return . Num . read $ ds > > parse s = let parses = (readP_to_S expr) s in > case parses of > (p : _) -> fst (last parses) > _ -> error "parse error" > main = do > print $ parse "1" > > λ> main > *** Exception: stack overflow > λ> parse "1+2" > *** Exception: stack overflow > > > -------------------------------------------------------------------------------- > > -- > Nadine and Henry Laxen The rest is silence > Villa Alta #6 > Calle Gaviota #10 Never try to teach a pig to sing > Chapala It wastes your time > +52 (376) 765-3181 And it annoys the pig > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Sep 25 15:07:41 2019 From: david.feuer at gmail.com (David Feuer) Date: Wed, 25 Sep 2019 11:07:41 -0400 Subject: [Haskell-cafe] Stack overflow with ReadP In-Reply-To: <23947.32768.327363.40968@gargle.gargle.HOWL> References: <23947.32768.327363.40968@gargle.gargle.HOWL> Message-ID: You have "unguarded" recursion between expr and parseAdd. When you try to parse an expression, one option is to parse an addition. When you go to do that, you look to parse an expression followed by other stuff. Thanks to the structure of ReadP, I *believe* this will actually work ... if you just take the first result. But if you keep going, you will definitely find yourself stuck. On Wed, Sep 25, 2019, 10:56 AM Henry Laxen wrote: > > Dear Haskell gurus, > > There has to be something very simple that I am misunderstanding here. I > have > tried sticking in trace statement, using the ghci debugger, but it just > makes > no sense to me. Please tell me what I am missing. > > Best wishes, > Henry Laxen > > -------------------------------------------------------------------------------- > > module S where > > import Text.ParserCombinators.ReadP > import Data.Char > > data Exp = Num Int | Add Exp Exp > deriving (Eq, Show) > > expr :: ReadP Exp > expr = do > e <- (parseNumber +++ parseAdd) > return e > > parseAdd :: ReadP Exp > parseAdd = do > e1 <- expr > _ <- char '+' > e2 <- expr > return (Add e1 e2) > > parseNumber :: ReadP Exp > parseNumber = do > ds <- (munch1 isDigit) > return . Num . read $ ds > > parse s = let parses = (readP_to_S expr) s in > case parses of > (p : _) -> fst (last parses) > _ -> error "parse error" > main = do > print $ parse "1" > > λ> main > *** Exception: stack overflow > λ> parse "1+2" > *** Exception: stack overflow > > > -------------------------------------------------------------------------------- > > -- > Nadine and Henry Laxen The rest is silence > Villa Alta #6 > Calle Gaviota #10 Never try to teach a pig to sing > Chapala It wastes your time > +52 (376) 765-3181 And it annoys the pig > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 juan.casanova at ed.ac.uk Wed Sep 25 17:03:20 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Wed, 25 Sep 2019 18:03:20 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190924203007.57x6tthtuyic4our@weber> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> <20190924203007.57x6tthtuyic4our@weber> Message-ID: <20190925180320.18814gp0xuf8si04@www.staffmail.ed.ac.uk> Thanks Tom, Looking at your suggested solution, it looks very similar to mine albeit two differences. One is "just" (as if it were not important) code clarity in that you use <$> instead of fmap which enables you to avoid lambda abstraction, but that part is operationally the same as mine. The other is that you do (traverse f sargs), whereas I did (traverse id (map f sargs)). This made me think. Is this always the same? Is it the same only for [] or for any Traversable? If it is, then, considering map is just fmap for lists, and that all Traversables must be Functors, why isn't traverse just defined as traverse_alt :: (Traversable t, Applicative f) => t (f a) -> f (t a) traverse_alt = traverse id and let fmap deal with the mapping of the function? Of course this wouldn't be the implementation, it would be the other way around. Instances of Traversable would implement traverse_alt, and then whenever I wanted to do what traverse currently does, I would just do: traverse_alt (fmap f inputs). What is there to gain by including the mapping into the traversal *in the implementation of traverse itself*? Thanks again, Juan. Quoting Tom Ellis on Tue, 24 Sep 2019 21:30:07 +0100: > On Mon, Sep 23, 2019 at 08:05:38PM +0100, Juan Casanova wrote: >> data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq >> newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq >> >> My Traversable instance (with comments on intermediate types because >> otherwise it can get pretty obscure): > > Everyone else has made good comments, but to add a little and to be a little > more explicit: your data type uses [] so it makes sense to directly inherit > the Traversable (and hence Foldable) instance from that. Your instance was > a little convoluted. Here's what I would suggest: > > instance Foldable (SOTermF fn) where > foldMap = foldMapDefault > > instance Traversable (SOTermF fn) where > traverse f (SOF (ConstF c)) = pure (SOF (ConstF c)) > traverse f (SOF (Proj idx)) = pure (SOF (Proj idx)) > traverse f (SOF (CompF g sargs)) = > SOF <$> (CompF <$> f g <*> traverse f sargs) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From juan.casanova at ed.ac.uk Wed Sep 25 17:05:53 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Wed, 25 Sep 2019 18:05:53 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> Message-ID: <20190925180553.141017gssk8rrukg@www.staffmail.ed.ac.uk> That is lovely. Makes it super clear. Hadn't thought about Bitraversable and Bifoldable. Thanks a lot. Juan. Quoting David Feuer on Tue, 24 Sep 2019 18:09:08 -0400: > On Mon, Sep 23, 2019, 3:05 PM Juan Casanova wrote: > > My types: >> >> data SOTermPF fn p f = ConstF fn | Proj Int | CompF p [f] deriving Eq > > newtype SOTermF fn f = SOF (SOTermPF fn f f) deriving Eq >> > > Here's a more modular option for the Traversable instance. > > import Data.Bitraversable > import Data.Bifoldable > import Control.Applicative > import Data.Traversable > > instance Bifoldable (SOTermPF fn) where > bifoldMap = bifoldMapDefault > > instance Bitraversable (SOTermPF fn) where > bitraverse _f _g (ConstF fn) = pure (ConstF fn) > bitraverse _f _g (Proj i) = pure (Proj i) > bitraverse f g (CompF p fs) = > liftA2 CompF (f p) (traverse g fs) > > instance Foldable (SOTermF fn) where > foldMap = foldMapDefault > > instance Traversable (SOTermF fn) where > traverse f (SOF q) = SOF <$> bitraverse f f q > >> > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Sep 25 18:06:54 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 25 Sep 2019 19:06:54 +0100 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190925180320.18814gp0xuf8si04@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> <20190924203007.57x6tthtuyic4our@weber> <20190925180320.18814gp0xuf8si04@www.staffmail.ed.ac.uk> Message-ID: <20190925180654.w2wrgtawjy2p6lcf@weber> On Wed, Sep 25, 2019 at 06:03:20PM +0100, Juan Casanova wrote: > why isn't traverse just defined as > > traverse_alt :: (Traversable t, Applicative f) => t (f a) -> f (t a) > traverse_alt = traverse id > > and let fmap deal with the mapping of the function? Of course this wouldn't > be the implementation, it would be the other way around. Instances of > Traversable would implement traverse_alt, and then whenever I wanted to do > what traverse currently does, I would just do: traverse_alt (fmap f inputs). > What is there to gain by including the mapping into the traversal *in the > implementation of traverse itself*? Your `traverse_alt` is called `sequence`: https://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Traversable.html#Traversable They're both useful and you can define each in terms of the other. I'd say I use traverse about ten times more than sequence. It's basically equivalent to `mapM`, i.e. "map with an effect". `fmap` followed by `sequence` tends to read a bit clumsily. Tom From ietf-dane at dukhovni.org Wed Sep 25 17:50:16 2019 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 25 Sep 2019 13:50:16 -0400 Subject: [Haskell-cafe] Foldable, Traversable and choosing an order In-Reply-To: <20190925180320.18814gp0xuf8si04@www.staffmail.ed.ac.uk> References: <20190923200538.49373kox2dadq6ck@www.staffmail.ed.ac.uk> <20190924203007.57x6tthtuyic4our@weber> <20190925180320.18814gp0xuf8si04@www.staffmail.ed.ac.uk> Message-ID: > On Sep 25, 2019, at 1:03 PM, Juan Casanova wrote: > > Considering map is just fmap for lists, and that all Traversables must be Functors, why isn't traverse just defined as > > traverse_alt :: (Traversable t, Applicative f) => t (f a) -> f (t a) > traverse_alt = traverse id > > and let fmap deal with the mapping of the function? Of course this wouldn't be the implementation, it would be the other way around. Instances of Traversable would implement traverse_alt, and then whenever I wanted to do what traverse currently does, I would just do: traverse_alt (fmap f inputs). What is there to gain by including the mapping into the traversal *in the implementation of traverse itself*? It seems you're reinventing 'sequenceA': λ> import Data.Traversable λ> :t traverse id traverse id :: (Applicative f, Traversable t) => t (f b) -> f (t b) λ> :t sequenceA sequenceA :: (Applicative f, Traversable t) => t (f a) -> f (t a) λ> :t traverse traverse :: (Applicative f, Traversable t) => (a -> f b) -> t a -> f (t b) λ> :t ((sequenceA .) . fmap) ((sequenceA .) . fmap) :: (Applicative f, Traversable t) => (a1 -> f a) -> t a1 -> f (t a) Each of 'traverse' and 'sequenceA' can be defined in terms of the other. The choice of one vs. the other is a matter of convenience: sequenceA = traverse id traverse f = sequenceA . fmap f -- Viktor. From doaitse at swierstra.net Wed Sep 25 19:00:20 2019 From: doaitse at swierstra.net (Doaitse Swierstra) Date: Wed, 25 Sep 2019 21:00:20 +0200 Subject: [Haskell-cafe] Stack overflow with ReadP In-Reply-To: <23947.32768.327363.40968@gargle.gargle.HOWL> References: <23947.32768.327363.40968@gargle.gargle.HOWL> Message-ID: <72BD66A0-6D8B-434F-8B8E-C71A52EEECC2@swierstra.net> Dear Nadine, apparently you are new to parser combinators. I am attaching some code I have used in the past for our first year students as part of our lecture notes on FP. They use the applicatiev style, which I think is to be preferred. I hope you find them instructive. We build a pocket calculator in a numer of steps. In daily life I use my uu-parsinglib, since it comes with fewer surprises for beginning users. If you have any questions do not hesitate to ask me. Succes, Doaitse Swierstra -------------- next part -------------- A non-text attachment was scrubbed... Name: ParseLib.hs Type: application/octet-stream Size: 2812 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PocketCalculators.hs Type: application/octet-stream Size: 8722 bytes Desc: not available URL: -------------- next part -------------- > On 25 Sep 2019, at 16:56, Henry Laxen wrote: > > > Dear Haskell gurus, > > There has to be something very simple that I am misunderstanding here. I have > tried sticking in trace statement, using the ghci debugger, but it just makes > no sense to me. Please tell me what I am missing. > > Best wishes, > Henry Laxen > -------------------------------------------------------------------------------- > > module S where > > import Text.ParserCombinators.ReadP > import Data.Char > > data Exp = Num Int | Add Exp Exp > deriving (Eq, Show) > > expr :: ReadP Exp > expr = do > e <- (parseNumber +++ parseAdd) > return e > > parseAdd :: ReadP Exp > parseAdd = do > e1 <- expr > _ <- char '+' > e2 <- expr > return (Add e1 e2) > > parseNumber :: ReadP Exp > parseNumber = do > ds <- (munch1 isDigit) > return . Num . read $ ds > > parse s = let parses = (readP_to_S expr) s in > case parses of > (p : _) -> fst (last parses) > _ -> error "parse error" > main = do > print $ parse "1" > > λ> main > *** Exception: stack overflow > λ> parse "1+2" > *** Exception: stack overflow > > -------------------------------------------------------------------------------- > > -- > Nadine and Henry Laxen The rest is silence > Villa Alta #6 > Calle Gaviota #10 Never try to teach a pig to sing > Chapala It wastes your time > +52 (376) 765-3181 And it annoys the pig > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 frederic-emmanuel.picca at synchrotron-soleil.fr Fri Sep 27 08:30:45 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 27 Sep 2019 08:30:45 +0000 Subject: [Haskell-cafe] how to profile my code Message-ID: Hello, I would like to profile my code in order to find what is wrong with it. When I run it , I have a lot's of time took by the GC. 13,374,664,736 bytes allocated in the heap 16,149,779,248 bytes copied during GC 8,449,239,784 bytes maximum residency (617 sample(s)) 52,988,816 bytes maximum slop 15265 MB total memory in use (6808 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 7281 colls, 7281 par 80.304s 3.389s 0.0005s 0.0279s Gen 1 617 colls, 616 par 2508.056s 105.538s 0.1711s 0.6128s Parallel GC work balance: 32.20% (serial 0%, perfect 100%) TASKS: 51 (1 bound, 50 peak workers (50 total), using -N24) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.013s ( 0.030s elapsed) MUT time 927.150s (101.039s elapsed) GC time 2349.743s ( 98.933s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 238.618s ( 9.993s elapsed) EXIT time 0.007s ( 0.001s elapsed) Total time 3515.531s (209.997s elapsed) Alloc rate 14,425,560 bytes per MUT second Productivity 26.4% of total user, 48.1% of total elapsed gc_alloc_block_sync: 524769 whitehole_spin: 2 gen[0].sync: 1375 gen[1].sync: 2139389 But If I use the Strict Extension in one of my file[1], this amount of time reduce drastically (the first run was done with a cold cache) This is why the MUT time is different. 13,364,299,032 bytes allocated in the heap 6,460,918,752 bytes copied during GC 8,423,062,112 bytes maximum residency (294 sample(s)) 55,571,872 bytes maximum slop 15265 MB total memory in use (6813 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 7455 colls, 7455 par 54.623s 2.330s 0.0003s 0.0279s Gen 1 294 colls, 293 par 782.773s 33.293s 0.1132s 0.5003s Parallel GC work balance: 61.24% (serial 0%, perfect 100%) TASKS: 51 (1 bound, 50 peak workers (50 total), using -N24) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.013s ( 0.026s elapsed) MUT time 340.862s ( 64.620s elapsed) GC time 749.604s ( 31.920s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 87.791s ( 3.703s elapsed) EXIT time 0.011s ( 0.002s elapsed) Total time 1178.282s (100.271s elapsed) Alloc rate 39,207,331 bytes per MUT second Productivity 28.9% of total user, 64.4% of total elapsed gc_alloc_block_sync: 439663 whitehole_spin: 11 gen[0].sync: 922 gen[1].sync: 1129310 It is nice, but I would like to understand the real problem. I used hp2ps in order to monitor the memory usage, but my code is dominated by PINNED values (attached file) so I do not know where to start ? thanks for your advices. Frederic [1] https://repo.or.cz/hkl.git/blob/4cff5145d095683a40bc93cf8a0c0076f308244b:/contrib/haskell/src/Hkl/Projects/Sixs.hs -------------- next part -------------- A non-text attachment was scrubbed... Name: hkl3d.ps Type: application/postscript Size: 19240 bytes Desc: hkl3d.ps URL: From leah at vuxu.org Fri Sep 27 14:41:11 2019 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 27 Sep 2019 16:41:11 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2019-09-30 @ 19:30 Message-ID: <87v9tdpzso.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 30 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2019/ Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From ruben.astud at gmail.com Sun Sep 29 04:31:45 2019 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sun, 29 Sep 2019 01:31:45 -0300 Subject: [Haskell-cafe] how to profile my code In-Reply-To: References: Message-ID: Hi On 27-09-19 05:30, PICCA Frederic-Emmanuel wrote: > [...] > It is nice, but I would like to understand the real problem. > > I used hp2ps in order to monitor the memory usage, but my code is > dominated by PINNED values (attached file) I'll admit I am not an expert, but I've found some space leaks on haskell projects (and fixes) so I'll take a stab. The info on [1] for profiling memory usage is good, but usually doesn't tell you what to use. If you profile with `+RTS -h --RTS` that actually means `-hc` which profiles by cost centre. Those are defined at compile time, so if you don't know where the leak is, compiling with `ghc -prof -fprof-auto` or `cabal --enable-profiling` should do the trick. But on your .ps you see lots of PINNED values, AFAIK those are usually C-style buffers as used underlying for example by the Bytestring library or FFI. I don't know how to further break them down via cost centres. You have at your disposal other types of profiling (by types, by modules), you could try any of those. One that I like is by retainer sets info (-hr), check [1]. The basic idea is that memory leaks can be break down on "set of cost centers". You can get lucky and see that lots of memory are only held alive because a single retainer set of cost center have those references, so `seq` some thunks solves the problem. Finally I recommend to use the hp2pretty package for generating the graphs as it has more options to organize info and to use `+RTS -L200 --RTS` when generating profiling info to include namespaces info for the closures you're studying. Good luck. [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD From frederic-emmanuel.picca at synchrotron-soleil.fr Mon Sep 30 15:55:29 2019 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Mon, 30 Sep 2019 15:55:29 +0000 Subject: [Haskell-cafe] how to profile my code In-Reply-To: References: , Message-ID: Hello Ruben, thanks for your advices. I used -hr and now I have this (attached) and this i snot clear to me :)) Fred -------------- next part -------------- A non-text attachment was scrubbed... Name: hkl3d.ps Type: application/postscript Size: 25802 bytes Desc: hkl3d.ps URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon Sep 30 18:34:48 2019 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 30 Sep 2019 19:34:48 +0100 Subject: [Haskell-cafe] how to profile my code In-Reply-To: References: Message-ID: <20190930183448.wtxzxn5yx7ajwk5v@weber> On Fri, Sep 27, 2019 at 08:30:45AM +0000, PICCA Frederic-Emmanuel wrote: > Hello, I would like to profile my code in order to find what is wrong with it. > > But If I use the Strict Extension in one of my file[1], this amount of > time reduce drastically Have you tried the StrictData extensions instead? That will help you discover whether it's just your data types that need strict fields or whether something else worse is going on. Tom From magnus at therning.org Mon Sep 30 20:06:02 2019 From: magnus at therning.org (Magnus Therning) Date: Mon, 30 Sep 2019 22:06:02 +0200 Subject: [Haskell-cafe] Hedgehog: returning a list from `commandExecute` and getting to the items in an update function Message-ID: <87pnjhwnv9.fsf@therning.org> Hello, I'm trying to use Hedgehog to test a web app at work. Yesterday I ran into an issue with getting to the value returned from my `commandExecute` in an `Update` `Callback`. Basically my model looks like this ~~~ newtype State (v :: * -> *) = State (M.Map (Var UUID v) DataPerItem) deriving (Eq, Show) ~~~ and I have an action, `Command gen exec [Update update]` where ~~~ exec :: action -> m [UUID] ~~~ which results in ~~~ update :: State v -> action -> Var [UUID] v -> State v ~~~ AFAICS I need to, in order to actually update my model, turn that `Var [UUID] v` into `[Var UUID v]`. I've been staring at the functions in Hedgehog for a while now but nothing jumps out... or am I, once again, thinking about it all wrong? :) /M I also asked at stackoverflow: https://stackoverflow.com/questions/58157292/returning-a-list-and-getting-to-the-items-in-hedgehog-state-machine This is just to widen the net a bit... -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org twitter: magthe http://magnus.therning.org/ Ah, good taste! What a dreadful thing! Taste is the enemy of creativeness. — Pablo Picasso -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From richard.james.senington at his.se Mon Sep 30 20:05:12 2019 From: richard.james.senington at his.se (Richard Senington) Date: Mon, 30 Sep 2019 20:05:12 +0000 Subject: [Haskell-cafe] hackage issues Message-ID: <41A1E33EC96C0E4DB3F34B94E130044253666DAE@HSMSMBX2.hs.local> Hi list, I have been trying to set up an account on Hackage to upload a project. I have created the account, but cannot get in contact with trustees to enable uploading. My mail servers (a university server) says that it cannot deliver the messages. Can anyone advise or assist? Richard