From evan at evanrutledgeborden.dreamhosters.com Thu Mar 1 14:59:05 2018 From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com) Date: Thu, 1 Mar 2018 09:59:05 -0500 Subject: [Haskell-cafe] ANN: network-2.6.3.4 Message-ID: Announcing network-2.6.3.4 * Don't touch IPv6Only when running on OpenBSD [#227](https://github.com/haskell/network/pull/227) * Do not closeFd within sendFd [#271](https://github.com/haskell/network/pull/271) * Updating examples and docs. A big thanks to the network contributors. http://hackage.haskell.org/package/network-2.6.3.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat Mar 3 22:26:23 2018 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 03 Mar 2018 23:26:23 +0100 Subject: [Haskell-cafe] cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse Message-ID: L.S., I am trying to get wxHaskell compiled with GHC 8.4.0.20180224 and cabal-install 2.1.0.0; compilation fails with the message: wxcore-0.93.0.0-1L9rVktyK3zIYrrLxBiCr9 failed during the final install step. The exception was: dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse "license" 5 ) I am using Windows 8.1. Can anybody tell me what to do about this? Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From ben.franksen at online.de Sun Mar 4 09:32:50 2018 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 4 Mar 2018 10:32:50 +0100 Subject: [Haskell-cafe] missing optimization for (++) Message-ID: I found that in base [1] we have (++) [] ys = ys (++) (x:xs) ys = x : xs ++ ys I had expected there to be a clause (++) xs [] = xs at the top, which would avoid the list traversal in this common case. Is this somehow magically taken care of by the {-# RULES "++" [~1] forall xs ys. xs ++ ys = augment (\c n -> foldr c n xs) ys #-} ? No, inlining @augment g xs = g (:) xs@ gives me (\c n -> foldr c n xs) (:) ys = foldr (:) ys xs which still traverses xs even if ys=[]. Any thoughts? [1] http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Base.html#%2B%2B Cheers Ben From clintonmead at gmail.com Sun Mar 4 09:42:17 2018 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 4 Mar 2018 20:42:17 +1100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: Adding that case will require one to evaluate the second argument to check it's empty before allowing one to examine the result. Consider `x ++ some_list_that_takes_a_long_time_to_produce_its_first_element`. In this case your proposal will not be an optimisation. On Sun, Mar 4, 2018 at 8:32 PM, Ben Franksen wrote: > I found that in base [1] we have > > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > I had expected there to be a clause > > (++) xs [] = xs > > at the top, which would avoid the list traversal in this common case. > > Is this somehow magically taken care of by the > > {-# RULES > "++" [~1] forall xs ys. xs ++ ys = augment (\c n -> foldr c n xs) ys > #-} > > ? No, inlining @augment g xs = g (:) xs@ gives me > > (\c n -> foldr c n xs) (:) ys > > = foldr (:) ys xs > > which still traverses xs even if ys=[]. > > Any thoughts? > > [1] > http://hackage.haskell.org/package/base-4.10.1.0/docs/ > src/GHC.Base.html#%2B%2B > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 lysxia at gmail.com Sun Mar 4 15:21:54 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Sun, 4 Mar 2018 10:21:54 -0500 Subject: [Haskell-cafe] Haskell memory model Message-ID: <33b35ca3-6a4a-3289-57c4-cf0a8513d3cc@gmail.com> Hello café, What guarantees are there about shared memory concurrency in Haskell? In particular, I'm wondering how to correctly and efficiently synchronize mutable operations from the vector package, using stm or atomic-primops. - Are reads/writes on vectors sequentially consistent? As a concrete example, can the following program (a common test for relaxed memory models) print anything? import qualified Data.Vector.Mutable as MV import Control.Concurrent main :: IO () main = do v <- MV.replicate 2 0 t <- newEmptyMVar forkIO $ do MV.write v 0 1 x <- MV.read v 1 putMVar t x forkIO $ do MV.write v 1 1 x <- MV.read v 0 putMVar t x a <- takeMVar t b <- takeMVar t if a == 0 && b == 0 then putStrLn "Relaxed!" else return () - Do atomic operations (via stm or atomic-primops) imply some constraints between vector operations? As another concrete example, can the snippet linked below ever throw an exception? One thread writes to a vector, and another reads from it, and they communicate via stm to guess whether the read value is safe to evaluate (in one test case the first thread overwrites a defined value with undefined, and in the other case it overwrites undefined with a defined value). http://lpaste.net/362596 Regards, Li-yao From ietf-dane at dukhovni.org Sun Mar 4 20:23:08 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 4 Mar 2018 15:23:08 -0500 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: > On Mar 4, 2018, at 4:32 AM, Ben Franksen wrote: > > I found that in base [1] we have > > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > I had expected there to be a clause > > (++) xs [] = xs > > at the top, which would avoid the list traversal in this common case. > > [...] > > which still traverses xs even if ys=[]. > > Any thoughts? Haskell is lazy, the traversal of x happens only when the combined list is actually traversed, and only for as many elements as requested, so the construction of the concatenated list carries little additional cost. And as pointed out, needlessly forcing the first element of y can have unintended consequences. For example: GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> let x = [1..] Prelude> let y = [1..] Prelude> let z = x ++ y Prelude> take 20 z [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] -- Viktor. From markus.l2ll at gmail.com Sun Mar 4 21:28:12 2018 From: markus.l2ll at gmail.com (=?UTF-8?B?TWFya3VzIEzDpGxs?=) Date: Sun, 4 Mar 2018 22:28:12 +0100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: Hi Viktor What I think the OP is asking for is a case where the original list would be returned immediately if the second is empty -- keeping the original spine. Since that case is missing then the list is pattern-matched and then reconstructed. Whether this actually happens after compilation is the real question. On Mar 4, 2018 21:24, "Viktor Dukhovni" wrote: > On Mar 4, 2018, at 4:32 AM, Ben Franksen wrote: > > I found that in base [1] we have > > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > I had expected there to be a clause > > (++) xs [] = xs > > at the top, which would avoid the list traversal in this common case. > > [...] > > which still traverses xs even if ys=[]. > > Any thoughts? Haskell is lazy, the traversal of x happens only when the combined list is actually traversed, and only for as many elements as requested, so the construction of the concatenated list carries little additional cost. And as pointed out, needlessly forcing the first element of y can have unintended consequences. For example: GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Prelude> let x = [1..] Prelude> let y = [1..] Prelude> let z = x ++ y Prelude> take 20 z [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20] -- Viktor. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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 josef.svenningsson at gmail.com Sun Mar 4 21:40:30 2018 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Sun, 04 Mar 2018 21:40:30 +0000 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: The rule "foldr/id" will replace 'foldr (:) [] xs' with 'xs'. Cheers, Josef On Sun, Mar 4, 2018 at 10:34 AM Ben Franksen wrote: > I found that in base [1] we have > > (++) [] ys = ys > (++) (x:xs) ys = x : xs ++ ys > > I had expected there to be a clause > > (++) xs [] = xs > > at the top, which would avoid the list traversal in this common case. > > Is this somehow magically taken care of by the > > {-# RULES > "++" [~1] forall xs ys. xs ++ ys = augment (\c n -> foldr c n xs) ys > #-} > > ? No, inlining @augment g xs = g (:) xs@ gives me > > (\c n -> foldr c n xs) (:) ys > > = foldr (:) ys xs > > which still traverses xs even if ys=[]. > > Any thoughts? > > [1] > > http://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.Base.html#%2B%2B > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Mar 4 22:32:11 2018 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 4 Mar 2018 23:32:11 +0100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: Am 04.03.2018 um 22:40 schrieb Josef Svenningsson: > The rule "foldr/id" will replace 'foldr (:) [] xs' with 'xs'. Ah, thanks a lot. That was the missing piece. And good to know, too, this means I can avoid a number of case distinctions I thought I needed for optimum performance. Cheers Ben From svenpanne at gmail.com Mon Mar 5 08:02:00 2018 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 5 Mar 2018 09:02:00 +0100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: 2018-03-04 10:42 GMT+01:00 Clinton Mead : > Adding that case will require one to evaluate the second argument to check > it's empty before allowing one to examine the result. > > Consider `x ++ some_list_that_takes_a_long_time_to_produce_its_first_ > element`. > In the extreme, evaluating the 2nd argument might not even terminate or it could throw an exception. > In this case your proposal will not be an optimisation. > I would go even a step further: The proposed additional case would not just be worse for some cases, it would be completely wrong: The Prelude part of the Haskell Report specifies among other things the strictness of function arguments. Changing an argument from non-strict to strict could have very severe consequences, e.g. non-terminaton, throwing exceptions where no exceptions would be thrown in the original definition, etc. For (++), the Prelude says that it is strict in its first argument, but non-strict in its second: https://www.haskell.org/onlinereport/haskell2010/haskellch9.html#verbatim-243 Very similar functions in this respect are (&&) and (||), and I guess people would be a bit upset if they suddenly forced evaluation of their second argument... :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Mon Mar 5 09:24:36 2018 From: benl at ouroborus.net (Ben Lippmeier) Date: Mon, 5 Mar 2018 20:24:36 +1100 Subject: [Haskell-cafe] Haskell memory model In-Reply-To: <33b35ca3-6a4a-3289-57c4-cf0a8513d3cc@gmail.com> References: <33b35ca3-6a4a-3289-57c4-cf0a8513d3cc@gmail.com> Message-ID: > On 5 Mar 2018, at 2:21 am, Li-yao Xia wrote: > > What guarantees are there about shared memory concurrency in Haskell? In particular, I'm wondering how to correctly and efficiently synchronize mutable operations from the vector package, using stm or atomic-primops. > > - Are reads/writes on vectors sequentially consistent? As a concrete example, can the following program (a common test for relaxed memory models) print anything? Read/Writes for single elements of a vector compile down to single machine instructions, which will be some sort of vanilla MOV on x86. The x86 architecture is free to reorder stores after writes. AIUI this is due to the write buffer [2] which holds writes before they are committed to main memory. The x86 instruction set has an MFENCE operation to force loads and stores to be visible to global memory before others, but this isn’t inserted for read/writes to mutable vectors. [1] https://en.wikipedia.org/wiki/Memory_ordering [2] https://en.wikipedia.org/wiki/Write_buffer > - Do atomic operations (via stm or atomic-primops) imply some constraints between vector operations? I think the answer to this is “probably, but only incidentally”. The MFENCE instruction on x86 applies to all deferred load/store actions in the physical thread. If you can cause an MFENCE to be emitted into the instruction stream then this will also cause vector operations to be sequentialised. See: https://stackoverflow.com/questions/21506748/reasoning-about-ioref-operation-reordering-in-concurrent-programs http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/ Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Mon Mar 5 12:13:48 2018 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 5 Mar 2018 13:13:48 +0100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: Am 05.03.2018 um 09:02 schrieb Sven Panne: > 2018-03-04 10:42 GMT+01:00 Clinton Mead : > >> Adding that case will require one to evaluate the second argument to check >> it's empty before allowing one to examine the result. >> >> Consider `x ++ some_list_that_takes_a_long_time_to_produce_its_first_ >> element`. >> > > In the extreme, evaluating the 2nd argument might not even terminate or it > could throw an exception. > > >> In this case your proposal will not be an optimisation. >> > > I would go even a step further: The proposed additional case would not just > be worse for some cases, it would be completely wrong: The Prelude part of > the Haskell Report specifies among other things the strictness of function > arguments. [...] Okay, okay, I got it. I did not think about strictness when I asked. The funny thing is that the two fusion rules combined, as explained by Josef, seem to cause this shortcut to be taken. But that can't be true because (++) really is non-strict, I tested that, with -O2. How do you explain that? Cheers Ben From lysxia at gmail.com Mon Mar 5 12:17:52 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 5 Mar 2018 07:17:52 -0500 Subject: [Haskell-cafe] Haskell memory model In-Reply-To: References: <33b35ca3-6a4a-3289-57c4-cf0a8513d3cc@gmail.com> Message-ID: <4089c69e-0222-1c75-aa99-b7456e6f01d5@gmail.com> Thanks Ben! Your answer and links are very helpful. I'll study them carefully. Li-yao On 03/05/2018 04:24 AM, Ben Lippmeier wrote: > >> On 5 Mar 2018, at 2:21 am, Li-yao Xia > > wrote: >> >> What guarantees are there about shared memory concurrency in Haskell? >> In particular, I'm wondering how to correctly and efficiently >> synchronize mutable operations from the vector package, using stm or >> atomic-primops. >> >> - Are reads/writes on vectors sequentially consistent? As a concrete >> example, can the following program (a common test for relaxed memory >> models) print anything? > > Read/Writes for single elements of a vector compile down to single > machine instructions, which will be some sort of vanilla MOV on x86. The > x86 architecture is free to reorder stores after writes. AIUI this is > due to the write buffer [2] which holds writes before they are committed > to main memory. The x86 instruction set has an MFENCE operation to force > loads and stores to be visible to global memory before others, but this > isn’t inserted for read/writes to mutable vectors. > > [1] https://en.wikipedia.org/wiki/Memory_ordering > [2] https://en.wikipedia.org/wiki/Write_buffer > > >> - Do atomic operations (via stm or atomic-primops) imply some >> constraints between vector operations? > > I think the answer to this is “probably, but only incidentally”. The > MFENCE instruction on x86 applies to all deferred load/store actions in > the physical thread. If you can cause an MFENCE to be emitted into the > instruction stream then this will also cause vector operations to be > sequentialised. > > See: > https://stackoverflow.com/questions/21506748/reasoning-about-ioref-operation-reordering-in-concurrent-programs > http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/ > > Ben. > From lysxia at gmail.com Mon Mar 5 12:40:48 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 5 Mar 2018 07:40:48 -0500 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: Message-ID: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> On 03/05/2018 07:13 AM, Ben Franksen wrote: > Okay, okay, I got it. I did not think about strictness when I asked. The > funny thing is that the two fusion rules combined, as explained by > Josef, seem to cause this shortcut to be taken. But that can't be true > because (++) really is non-strict, I tested that, with -O2. How do you > explain that? Rewrite rules apply at compile time and don't force any computation. The second rule fires only if the second argument of (++) is syntactically []. Otherwise the code doesn't change, and strictness is preserved. Cheers, Li-yao From ben.franksen at online.de Mon Mar 5 22:18:12 2018 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 5 Mar 2018 23:18:12 +0100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> References: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> Message-ID: Am 05.03.2018 um 13:40 schrieb Li-yao Xia: > On 03/05/2018 07:13 AM, Ben Franksen wrote: >> Okay, okay, I got it. I did not think about strictness when I asked. The >> funny thing is that the two fusion rules combined, as explained by >> Josef, seem to cause this shortcut to be taken. But that can't be true >> because (++) really is non-strict, I tested that, with -O2. How do you >> explain that? > > Rewrite rules apply at compile time and don't force any computation. > The second rule fires only if the second argument of (++) is > syntactically []. Otherwise the code doesn't change, and strictness is > preserved. Thanks, yet another thing learned. So let ys = [] in xs ++ ys will traverse the spine of xs but xs ++ [] will not. Interesting. (But who writes something like "xs ++ []" in a real program?) Cheers Ben From allbery.b at gmail.com Mon Mar 5 22:24:35 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Mar 2018 17:24:35 -0500 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> Message-ID: Generated code, sometimes including "deriving"-generated code. On Mon, Mar 5, 2018 at 5:18 PM, Ben Franksen wrote: > Am 05.03.2018 um 13:40 schrieb Li-yao Xia: > > On 03/05/2018 07:13 AM, Ben Franksen wrote: > >> Okay, okay, I got it. I did not think about strictness when I asked. The > >> funny thing is that the two fusion rules combined, as explained by > >> Josef, seem to cause this shortcut to be taken. But that can't be true > >> because (++) really is non-strict, I tested that, with -O2. How do you > >> explain that? > > > > Rewrite rules apply at compile time and don't force any computation. > > The second rule fires only if the second argument of (++) is > > syntactically []. Otherwise the code doesn't change, and strictness is > > preserved. > > Thanks, yet another thing learned. So > > let ys = [] in xs ++ ys > > will traverse the spine of xs but > > xs ++ [] > > will not. Interesting. > > (But who writes something like "xs ++ []" in a real program?) > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Mon Mar 5 22:25:43 2018 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Mon, 5 Mar 2018 17:25:43 -0500 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: References: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> Message-ID: <7B963558-27C1-4013-9F3C-4F90F56A0040@gmail.com> Actually, it is likely that neither of the examples you gave will end up traversing the spine of the list. The definition of ys would almost certainly be inlined, and then the rule would fire. Sent from my iPhone > On Mar 5, 2018, at 5:18 PM, Ben Franksen wrote: > >> Am 05.03.2018 um 13:40 schrieb Li-yao Xia: >>> On 03/05/2018 07:13 AM, Ben Franksen wrote: >>> Okay, okay, I got it. I did not think about strictness when I asked. The >>> funny thing is that the two fusion rules combined, as explained by >>> Josef, seem to cause this shortcut to be taken. But that can't be true >>> because (++) really is non-strict, I tested that, with -O2. How do you >>> explain that? >> >> Rewrite rules apply at compile time and don't force any computation. >> The second rule fires only if the second argument of (++) is >> syntactically []. Otherwise the code doesn't change, and strictness is >> preserved. > > Thanks, yet another thing learned. So > > let ys = [] in xs ++ ys > > will traverse the spine of xs but > > xs ++ [] > > will not. Interesting. > > (But who writes something like "xs ++ []" in a real program?) > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 hyarion at iinet.net.au Mon Mar 5 23:17:50 2018 From: hyarion at iinet.net.au (Ben) Date: Tue, 06 Mar 2018 10:17:50 +1100 Subject: [Haskell-cafe] missing optimization for (++) In-Reply-To: <7B963558-27C1-4013-9F3C-4F90F56A0040@gmail.com> References: <06200c5e-d4de-c7e5-76a7-04b22cfc8298@gmail.com> <7B963558-27C1-4013-9F3C-4F90F56A0040@gmail.com> Message-ID: <8382AE85-7C68-4607-90DB-782133412279@iinet.net.au> On 6 March 2018 9:25:43 am AEDT, Andrew Martin wrote: >Actually, it is likely that neither of the examples you gave will end >up traversing the spine of the list. The definition of ys would almost >certainly be inlined, and then the rule would fire. > >Sent from my iPhone > >> On Mar 5, 2018, at 5:18 PM, Ben Franksen >wrote: >> >>> Am 05.03.2018 um 13:40 schrieb Li-yao Xia: >>>> On 03/05/2018 07:13 AM, Ben Franksen wrote: >>>> Okay, okay, I got it. I did not think about strictness when I >asked. The >>>> funny thing is that the two fusion rules combined, as explained by >>>> Josef, seem to cause this shortcut to be taken. But that can't be >true >>>> because (++) really is non-strict, I tested that, with -O2. How do >you >>>> explain that? >>> >>> Rewrite rules apply at compile time and don't force any computation. >>> The second rule fires only if the second argument of (++) is >>> syntactically []. Otherwise the code doesn't change, and strictness >is >>> preserved. >> >> Thanks, yet another thing learned. So >> >> let ys = [] in xs ++ ys >> >> will traverse the spine of xs but >> >> xs ++ [] >> >> will not. Interesting. >> >> (But who writes something like "xs ++ []" in a real program?) >> >> Cheers >> Ben >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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. For determining whether xs is traversed, it doesn't really matter whether or not the rule fires and replaces zs = xs ++ ys with just zs = xs. In either case if you traverse the spine of zs to a given depth, it'll force the spine of xs to the same depth. Just having xs ++ ys in the code doesn't traverse the spine of xs, and even evaluating it to WHNF only evaluates xs to the same degree as evaluating xs to WHNF directly. The question is whether it's allocating a new list spine as it goes on top of evaluating the spine of xs, but there shouldn't be any impact on what is evaluated when. From andrei.paskevich at lri.fr Tue Mar 6 13:26:21 2018 From: andrei.paskevich at lri.fr (Andrei Paskevich) Date: Tue, 6 Mar 2018 14:26:21 +0100 Subject: [Haskell-cafe] VerifyThis 2018: Call for Participation and Travel Grants Message-ID: <20180306132621.GA23052@tikki.lri.fr> ******************************************************************************** VerifyThis Verification Competition 2018 CALL FOR PARTICIPATION -- TRAVEL GRANTS Competition to be held at ETAPS 2018 http://verifythis.ethz.ch ******************************************************************************** IMPORTANT DATES Grant application deadline: March 12, 2018 Competition: April 14 and 15, 2018 ABOUT VerifyThis 2018 is a program verification competition taking place as part of the European Joint Conferences on Theory and Practice of Software (ETAPS 2018) on April 14-15, 2018 in Thessaloniki, Greece. It is the 7th event in the VerifyThis competition series. The competition will offer a number of challenges presented in natural language and pseudo code. Participants have to formalize the requirements, implement a solution, and formally verify the implementation for adherence to the specification. There are no restrictions on the programming language and verification technology used. The correctness properties posed in problems will have the input-output behaviour of programs in focus. Solutions will be judged for correctness, completeness, and elegance. PARTICIPATION: Participation is open for anybody interested. Teams of up to two people are allowed. Registration for ETAPS workshops and physical presence on site is required. We particularly encourage participation of: - student teams (this includes PhD students) - non-developer teams using a tool someone else developed - several teams using the same tool TRAVEL GRANTS: The competition has funds for a limited number of travel grants. A grant covers the incurred travel and accommodation costs up to a certain limit. The expected limit is EUR 350 for those coming from Europe and EUR 600 for those coming from outside Europe. To apply for a travel grant, send an email to verifythis at cs.nuim.ie by March 12, 2018. The application should include: - your name - your affiliation - the verification system(s) you plan to use at the competition - the planned composition of your team - a short letter of motivation explaining your involvement with formal verification so far - if you are a student, please state the academic degree you are seeking and have your supervisor send a brief letter of support to verifythis at cs.nuim.ie ORGANIZERS * Marieke Huisman, University of Twente, the Netherlands * Rosemary Monahan, Maynooth University, Ireland * Peter Müller, ETH Zürich, Switzerland * Andrei Paskevich, Paris-Sud University, France * Gidon Ernst, National Institute of Informatics Tokyo, Japan CONTACT Email: verifythis at cs.nuim.ie Web: http://verifythis.ethz.ch From tonymorris at gmail.com Tue Mar 6 22:13:42 2018 From: tonymorris at gmail.com (Tony Morris) Date: Wed, 7 Mar 2018 08:13:42 +1000 Subject: [Haskell-cafe] sv library for your csv|psv|tsv Message-ID: Hi everyone, The Queensland Functional Programming Lab has released the sv library for parsing, editing and calculating results based on * separated value file formats such as CSV, PSV and TSV. https://hackage.haskell.org/package/sv This first release of the library is 6 months of work by the FP lab. If you are familiar with the original argonaut[^1] library in scala or purescript, you will know of the idea of codecs for converting a syntax tree into your user-defined values. For example, taking a JSON data type to your own Person data type. Some of these ideas have been adapted to the aeson library. The sv library implements these same original ideas, with corrections to a few of the original mistakes that we made in argonaut. The sv library also retains the inverse law to parsing (write . parse = id), so you can use the library for editing CSV|PSV|TSV files. Characters such as whitespace, quotes, etc are retained in the syntax tree. If there are any questions, please feel free to contact us http://qfpl.io/contact [^1]: http://argonaut.io/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From leonidasbo at gmail.com Tue Mar 6 22:46:44 2018 From: leonidasbo at gmail.com (leonidasbo .) Date: Wed, 7 Mar 2018 00:46:44 +0200 Subject: [Haskell-cafe] Fwd: Monad Transformers stack with variable depth In-Reply-To: References: Message-ID: Hello, I am a beginner with Haskell and the last few days I am troubled on how to form a stack of Monad Transformers. The following example demonstrates the use of multiple State monads without the use of Monad Transformers: data Item = Item { rCounter :: Int } increaseCounter :: State Item () increaseCounter = do val <- gets rCounter modify (\i -> i { rCounter = val + 1 }) data ItemManager = ItemManager { rItems :: [Item] } addItem :: Item -> State ItemManager () addItem item = do items <- gets rItems modify (\mgr -> mgr { rItems = items ++ [item] }) increaseCounterInItems :: State ItemManager () increaseCounterInItems = do items <- gets rItems let items' = map *(execState increaseCounter)* items modify (\mgr -> mgr { rItems = items' }) main :: IO () main = $ do let itemMgrState = do addItem $ Item 0 addItem $ Item 10 increaseCounterInItems let itemMgr = execState itemMgrState $ ItemManager [] let items = rItems itemMgr putStrLn rCounter (items !! 0) -- prints 1 putStrLn rCounter (items !! 1) -- prints 11 In the above implementation calls *execState, *inside functions of ItemManager, for updating Items. I have read about MonadTransformers and that they give you the ability to use monads inside the context of another monad. So I would like to use StateT in signatures of ItemManager's functions and avoid calling *execState, *something like this: increaseCounterInltems :: StateT ItemManager (State Item) () But I cannot find a way to implement the above function. The root cause of the difficulty seems to be that ItemManager contains multiple Items. The Monad Transformer stack contains a single State Item. So it seems to me that I am following the wrong approach. How could I use Monad Transformers in order to avoid calling *execState* for modifying Items in ItemManager? Thanks in advance, Leonidas Virus-free. www.avast.com <#m_-5826819471182298913_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Wed Mar 7 11:36:25 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Wed, 7 Mar 2018 06:36:25 -0500 Subject: [Haskell-cafe] Fwd: Monad Transformers stack with variable depth In-Reply-To: References: Message-ID: Hi Leonidas This is an interesting example. If I understand you correctly, what you want to do is to focus on one particular item, apply a (State) monadic computation that modifies it, replace that in the main list, as part of a larger monadic computation (also in a State monad / StateT transformer). The first part, focusing on a sub-element, is fine. You could have an operation on a State monad that allows you to focus on a substate. But the problem is merging the result back into the main state: that would not happen automatically. (Note for other readers: reminds me of lenses. Maybe StateT and Lens can be combined?) It seems to me that, in this case, what you are already doing would be roughly the way to do it (if you want to use State also to modify the inner items). Example of state transformers: Imagine that you have an additional, distinguished Item, that you need to keep apart (apart is the keyword, not the fact that it's only one). Then the monad you would be handling would be like: State (ItemManager, Item) No matter how many Items you have in the ItemManager (may be zero), you always have a distinguished Item separated. But that means that, to manipulate this, you'd have to extract the ItemManager, modify it, put it back in the tuple, etc. So, you can also do: StateT ItemManager (State Item) Which means that you can modify ItemManager and Item independently, and manipulate both with: op :: StateT ItemManager (State Item) () op = do modify f -- computation that affects item manager lift (modify g) -- computation that affects single item ... You would then define your operations to be more flexible: increaseCounterInItems :: StateT ItemManager m () So, you could also do: op :: StateT ItemManager (State Item) () op = do increaseCounterIntItems -- adds one to every Item in ItemManager lift increaseCounter -- adds one to the single Item ... Hope that helps Best wishes Ivan On 6 March 2018 at 17:46, leonidasbo . wrote: > Hello, > > I am a beginner with Haskell and the last few days I am troubled on how to > form a stack of Monad Transformers. > The following example demonstrates the use of multiple State monads > without the use of Monad Transformers: > > data Item = Item { rCounter :: Int } > > increaseCounter :: State Item () > increaseCounter = do > val <- gets rCounter > modify (\i -> i { rCounter = val + 1 }) > > data ItemManager = ItemManager { rItems :: [Item] } > > addItem :: Item -> State ItemManager () > addItem item = do > items <- gets rItems > modify (\mgr -> mgr { rItems = items ++ [item] }) > > increaseCounterInItems :: State ItemManager () > increaseCounterInItems = do > items <- gets rItems > let items' = map *(execState increaseCounter)* items > modify (\mgr -> mgr { rItems = items' }) > > main :: IO () > main = $ do > let itemMgrState = do > addItem $ Item 0 > addItem $ Item 10 > increaseCounterInItems > > let itemMgr = execState itemMgrState $ ItemManager [] > > let items = rItems itemMgr > putStrLn rCounter (items !! 0) -- prints 1 > putStrLn rCounter (items !! 1) -- prints 11 > > In the above implementation calls *execState, *inside functions of > ItemManager, for updating Items. > I have read about MonadTransformers and that they give you the ability to > use monads inside the context of another monad. > So I would like to use StateT in signatures of ItemManager's functions and > avoid calling *execState, *something like this: > > increaseCounterInltems :: StateT ItemManager (State Item) () > > But I cannot find a way to implement the above function. The root cause of > the difficulty seems to be that ItemManager contains multiple Items. > The Monad Transformer stack contains a single State Item. So it seems to > me that I am following the wrong approach. > > How could I use Monad Transformers in order to avoid calling *execState* > for modifying Items in ItemManager? > > Thanks in advance, > Leonidas > > > Virus-free. > www.avast.com > > <#m_8570978510949558714_m_-5826819471182298913_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ollie at ocharles.org.uk Wed Mar 7 11:54:41 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 07 Mar 2018 11:54:41 +0000 Subject: [Haskell-cafe] Fwd: Monad Transformers stack with variable depth In-Reply-To: References: Message-ID: On Wed, Mar 7, 2018 at 11:42 AM Ivan Perez wrote: > > (Note for other readers: reminds me of lenses. Maybe StateT and Lens can > be combined?) > I've only skimmed the conversation, but I believe you're looking for zoom Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Mar 7 12:23:17 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 7 Mar 2018 07:23:17 -0500 Subject: [Haskell-cafe] Fwd: Monad Transformers stack with variable depth In-Reply-To: References: Message-ID: Doesn't lens already have StateT support? The operators with a '=' in them. On Wed, Mar 7, 2018 at 6:54 AM, Oliver Charles wrote: > > > On Wed, Mar 7, 2018 at 11:42 AM Ivan Perez > wrote: > >> >> (Note for other readers: reminds me of lenses. Maybe StateT and Lens can >> be combined?) >> > > I've only skimmed the conversation, but I believe you're looking for zoom > > > > Ollie > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Wed Mar 7 14:30:07 2018 From: P.Achten at cs.ru.nl (Peter Achten) Date: Wed, 7 Mar 2018 15:30:07 +0100 Subject: [Haskell-cafe] 1st call for papers: Trends in Functional Programming, 11-13 june 2018, Chalmers Campus Johanneberg, Gothenburg Message-ID: <4b2dc0e2-d131-f164-009e-683b6beb7c54@cs.ru.nl> ----------------------------- C A L L F O R P A P E R S ----------------------------- ======== TFP 2018 =========== 19th Symposium on Trends in Functional Programming 11-13 June, 2018 Chalmers Campus Johanneberg, Gothenburg http://www.cse.chalmers.se/~myreen/tfp2018/index.html The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2018 will be the main event of a pair of functional programming events. TFP 2018 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 14. == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: Leading-edge, previously unpublished research work Position Articles: On what new trends should or should not be Project Articles: Descriptions of recently started new projects Evaluation Articles: What lessons can be drawn from a finished project Overview Articles: Summarizing work with respect to a trendy subject. Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2018 program chairs, Michał Pałka and Magnus Myreen. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Paper Submissions == We use EasyChair for the refereeing process. The link to the submission page is: https://easychair.org/conferences/?conf=tfp2018 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. == Important Dates == Submission (pre-symposium review): March 26, 2018 Submission (draft, post-symposium review): April 26, 2018 Notification (pre- and post-symposium review): May 3, 2018 Registration: June 3, 2018 TFP Symposium: June 11-13, 2018 TFPIE Workshop: June 14, 2018 Student papers feedback: June 21, 2018 Submission (post-symposium review): August 14, 2018 Notification (post-symposium review): September 20, 2018 Camera-ready paper (pre- and post-symposium review): November 30, 2018 == Program Committee == Program Co-chairs Michał Pałka, Chalmers University of Technology (SE) Magnus Myreen, Chalmers University of Technology (SE) Program Committee Soichiro Hidaka, Hosei University (JP) Meng Wang, University of Bristol (UK) Sam Tobin-Hochstadt, Indiana University Bloomington (US) Tiark Rompf, Purdue University (US) Patricia Johann, Appalachian State University (US) Neil Sculthorpe, Nottingham Trent University (UK) Andres Löh, Well-Typed LLP (UK) Tarmo Uustalu, Tallinn University of Technology (EE) Cosmin E. Oancea, University of Copenhagen (DK) Mauro Jaskelioff, Universidad Nacional de Rosario (AR) Peter Achten, Radboud University (NL) Dimitrios Vytiniotis, Microsoft Research (UK) Alberto Pardo, Universidad de la República (UY) Natalia Chechina, University of Glasgow (UK) Peter Sestoft, IT University of Copenhagen (DK) Scott Owens, University of Kent (UK) From dave.laing.80 at gmail.com Thu Mar 8 01:03:20 2018 From: dave.laing.80 at gmail.com (David Laing) Date: Thu, 8 Mar 2018 11:03:20 +1000 Subject: [Haskell-cafe] QFPL is hiring 5 functional programmers Message-ID: Hi all, QFPL is the Queensland Functional Programming Lab (QFPL) - where I work - and we have 5 positions open in Brisbane, Australia. We're part of Data61, the Australia federal organization that does research and engineering in the data science / ICT space. Our main focus in the lab is on doing things that make it easier for software engineers to use functional programming. This involves: - creating and running courses - improving libraries, documentation and tools - writing libraries and tools to fill gaps in the ecosystem All of the things we create are open-source. You can look at the job description / apply here: https://jobs.csiro.au/job/Brisbane%2C-QLD-EOI-Functional-Programming-Software-Engineers/463348700/ As far as I know, we're not currently hiring remote workers, but relocation support is a possibility. If you have questions about the lab or the role, I'm happy to answer them. Cheers, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Thu Mar 8 13:02:16 2018 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 8 Mar 2018 14:02:16 +0100 Subject: [Haskell-cafe] do-notation for building monoid values Message-ID: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> Dear cafe, prompted by a discussion with the author of blaze-markup [1] I realized a pattern and would like to know whether other haskellers have exploited this/find this useful: For every monoid m, the types Writer m () and m are isomorphic as types via tell and execWriter. Moreover, Writer m is a monad if and only if m is a monoid. For every monad t, the type t () is a monoid with mempty = return () mappend = (>>). In the particular case of Writer m () and m, the isomorphism of Haskell types is in fact an isomorphism of monoids, that is, the functions tell and execWriter preserve the monoid operations. This enables us to use do-notation in building complicated values of any monoid type, e.g. Text or any other syntax. Instead of writing complicatedValue = component1 <> component2 <> modifier (component3 <> component4) one can write complicatedValue = execWriter $ do component1 component2 modifier $ do component3 component4 Should such an idiom be encouraged/discouraged? How do you handle the construction of monoid values (especially text-like) with interspersed function applications (e.g. show, prettyprint)? Regards, Olaf [1] https://github.com/jaspervdj/blaze-markup/issues/36 From merijn at inconsistent.nl Thu Mar 8 13:08:31 2018 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Thu, 8 Mar 2018 14:08:31 +0100 Subject: [Haskell-cafe] do-notation for building monoid values In-Reply-To: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> References: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> Message-ID: <7EE7560E-2497-438F-B1B1-09B5F1331FC2@inconsistent.nl> I always just use mconcat and lists, so instead of: > complicatedValue = execWriter $ do > component1 > component2 > modifier $ do > component3 > component4 I write: complicatedValue = mconcat [ component1 , component2 , modifier . mconcat $ [component3, component4] ] Alternatively, if component3 and component4 are really long or lots of them linewrap those too: complicatedValue = mconcat [ component1 , component2 , modifier . mconcat $ [ component3 , component4 ] ] Cheers, Merijn > On 8 Mar 2018, at 14:02, Olaf Klinke wrote: > > Dear cafe, > > prompted by a discussion with the author of blaze-markup [1] I realized a pattern and would like to know whether other haskellers have exploited this/find this useful: > > For every monoid m, the types Writer m () and m are isomorphic as types via tell and execWriter. Moreover, Writer m is a monad if and only if m is a monoid. For every monad t, the type t () is a monoid with > mempty = return () > mappend = (>>). > In the particular case of Writer m () and m, the isomorphism of Haskell types is in fact an isomorphism of monoids, that is, the functions tell and execWriter preserve the monoid operations. > > This enables us to use do-notation in building complicated values of any monoid type, e.g. Text or any other syntax. Instead of writing > > complicatedValue = component1 <> > component2 <> > modifier (component3 <> component4) > > one can write > > complicatedValue = execWriter $ do > component1 > component2 > modifier $ do > component3 > component4 > > Should such an idiom be encouraged/discouraged? How do you handle the construction of monoid values (especially text-like) with interspersed function applications (e.g. show, prettyprint)? > > Regards, > Olaf > > [1] https://github.com/jaspervdj/blaze-markup/issues/36 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 874 bytes Desc: Message signed with OpenPGP URL: From andrew.thaddeus at gmail.com Thu Mar 8 13:48:38 2018 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Thu, 8 Mar 2018 08:48:38 -0500 Subject: [Haskell-cafe] do-notation for building monoid values In-Reply-To: <7EE7560E-2497-438F-B1B1-09B5F1331FC2@inconsistent.nl> References: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> <7EE7560E-2497-438F-B1B1-09B5F1331FC2@inconsistent.nl> Message-ID: I do the same thing that Merijn does. It works really well. On Thu, Mar 8, 2018 at 8:08 AM, Merijn Verstraaten wrote: > I always just use mconcat and lists, so instead of: > > complicatedValue = execWriter $ do > > component1 > > component2 > > modifier $ do > > component3 > > component4 > > I write: > > complicatedValue = mconcat > [ component1 > , component2 > , modifier . mconcat $ [component3, component4] > ] > > Alternatively, if component3 and component4 are really long or lots of > them linewrap those too: > > complicatedValue = mconcat > [ component1 > , component2 > , modifier . mconcat $ > [ component3 > , component4 > ] > ] > > Cheers, > Merijn > > > On 8 Mar 2018, at 14:02, Olaf Klinke wrote: > > > > Dear cafe, > > > > prompted by a discussion with the author of blaze-markup [1] I realized > a pattern and would like to know whether other haskellers have exploited > this/find this useful: > > > > For every monoid m, the types Writer m () and m are isomorphic as types > via tell and execWriter. Moreover, Writer m is a monad if and only if m is > a monoid. For every monad t, the type t () is a monoid with > > mempty = return () > > mappend = (>>). > > In the particular case of Writer m () and m, the isomorphism of Haskell > types is in fact an isomorphism of monoids, that is, the functions tell and > execWriter preserve the monoid operations. > > > > This enables us to use do-notation in building complicated values of any > monoid type, e.g. Text or any other syntax. Instead of writing > > > > complicatedValue = component1 <> > > component2 <> > > modifier (component3 <> component4) > > > > one can write > > > > complicatedValue = execWriter $ do > > component1 > > component2 > > modifier $ do > > component3 > > component4 > > > > Should such an idiom be encouraged/discouraged? How do you handle the > construction of monoid values (especially text-like) with interspersed > function applications (e.g. show, prettyprint)? > > > > Regards, > > Olaf > > > > [1] https://github.com/jaspervdj/blaze-markup/issues/36 > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Mar 8 16:57:45 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 11:57:45 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released Message-ID: <87h8pq33p8.fsf@smart-cactus.org> The GHC developers are very happy to announce the 8.4.1 release of Glasgow Haskell Compiler. Binary and source distributions can be found at https://downloads.haskell.org/~ghc/8.4.1/ This is the third major release in the GHC 8 series. As such, the focus of this release is performance, stability, and consolidation. Consequently numerous cleanups can be seen throughout the compiler including, * Further refinement of TypeInType, including significant improvements in error messages. * Improvements in code generation resulting in noticable performance improvements in some types of programs. * Core library improvements, including phase 2 of the Semigroup/Monoid proposal * Many improvements to instance deriving * The resolution of nearly 300 other tickets A more thorough list of the changes in this release can be found in the release notes, https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html There are a few changes in release-engineering matters that should be noted, * This is GHC's first release on it's new, accelerated release schedule. From now on GHC will produce one release every six months. * While we typically strive to produce OpenBSD builds, the gcc shipped with OpenBSD 6.1 is unfortunately too old to compile this release. * FreeBSD builds are still in progress This release has been the result of approximately six months of work by over one hundred code contributors. Thanks to everyone who has helped in writing patches, testing, reporting bugs, and offering feedback over the last year. As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From danburton.email at gmail.com Thu Mar 8 18:17:26 2018 From: danburton.email at gmail.com (Dan Burton) Date: Thu, 8 Mar 2018 10:17:26 -0800 Subject: [Haskell-cafe] BayHac 2018: Call for Proposals Message-ID: https://goo.gl/forms/TZbFNIZu4Q1dEh2g2 We are looking to fill out the BayHac 2018 schedule with talks and workshops. Last year we had many wonderful (and lengthy) talks, thanks! This year we are cutting down on the length of talks, as well as the overall time dedicated to them. This will leave more time for hacking. While we hope to accommodate everyone who desires to present, we are asking for proposals this year, which may be rejected if we get more than our limited schedule will allow. Propose a talk: 10 mins to present, 5 mins for questions. Talks will be recorded and uploaded to YouTube as they were last year. Propose a workshop: looser time constraints, smaller audiences. Workshops are interactive, guided lectures. Those in attendence will follow your guidance to write and run Haskell code on their own machine. Workshops will not be recorded. If we have difficulty fitting all talks and workshops into the schedule, note that workshops will be strongly preferred. Propose a set of exercises: no presentation necessary. We would like to have recommended sets of exercises for BayHac attendees to try out and discuss amongst themselves at their leisure. These can be pre-existing sets of exercises, or novel ones that you create. To make a proposal, please fill out this google form: https://goo.gl/forms/TZbFNIZu4Q1dEh2g2 Thank you for helping us make BayHac a delightful, educational event for all in attendance. -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Thu Mar 8 20:09:05 2018 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Thu, 08 Mar 2018 12:09:05 -0800 Subject: [Haskell-cafe] Final Call for Papers: PACMPL issue ICFP 2018 Message-ID: <5aa1986123f4f_a4e93fdb36057bec22153@landin.local.mail> PACMPL Volume 2, Issue ICFP 2018 Call for Papers accepted papers to be invited for presentation at The 23rd ACM SIGPLAN International Conference on Functional Programming St. Louis, Missouri, USA http://icfp18.sigplan.org/ ### Important dates Submissions due: 16 March 2018 (Friday) Anywhere on Earth https://icfp18.hotcrp.com Author response: 2 May (Wednesday) - 4 May (Friday) 14:00 UTC Notification: 18 May (Friday) Final copy due: 22 June (Friday) Conference: 24 September (Monday) - 26 September (Wednesday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL ) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2018 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * *Implementation*: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * *Software-Development Techniques*: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * *Analysis and Transformation*: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * *Applications*: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * *Education*: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2018 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is Friday, March 16, 2018, Anywhere on Earth (). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from . For authors using LaTeX, a lighter-weight package, including only the essential files, is available from . There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL's Information and Guidelines for Authors at . **Submission**: Submissions will be accepted at Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on Wednesday, May 2, 2018, to read reviews and respond to them. **Supplementary Materials**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at . **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at . **Resubmitted Papers**: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2018. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2018 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on May 18, 2018. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After five weeks (June 22, 2018), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within five weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2018 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limits for final versions of papers will be increased to ensure that authors have space to respond to reviewer comments and mandatory revisions. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from . * PACMPL is a Gold Open Access journal. It will be archived in ACM’s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit to learn how to create links for free downloads from the ACM DL. * At least one author of each accepted submissions will be expected to attend and present their paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. Further information about the motivations and expectations for Artifact Evaluation can be found at . ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report" followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better off submitted it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Robby Findler (Northwestern University, USA) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Ryan R. Newton (Indiana University, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Matthew Fluet (Rochester Institute of Technology, USA) Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) Student Research Competition Chair: Ilya Sergey (University College London, UK) Video Co-Chairs: Jose Calderon (Galois, Inc., USA) Nicolas Wu (University of Bristol, UK) Workshops Co-Chair: David Christiansen (Indiana University, USA) Christophe Scholliers (Universiteit Gent, Belgium) ### PACMPL Volume 2, Issue ICFP 2018 Principal Editor: Matthew Flatt (Univesity of Utah, USA) Review Committee: Sandrine Blazy (IRISA, University of Rennes 1, France) David Christiansen (Indiana University, USA) Martin Elsman (University of Copenhagen, Denmark) Marco Gaboardi (University at Buffalo, CUNY, USA) Sam Lindley (University of Edinburgh, UK) Heather Miller (Northweastern University, USA / EPFL, Switzerland) J. Garrett Morris (University of Kansas, USA) Henrik Nilsson (University of Nottingham, UK) François Pottier (Inria, France) Alejandro Russo (Chalmers University of Technology, Sweden) Ilya Sergey (University College London, UK) Michael Sperber (Active Group GmbH, Germany) Wouter Swierstra (Utrecht University, UK) Éric Tanter (University of Chile, Chile) Katsuhiro Ueno (Tohoku University, Japan) Niki Vazou (University of Maryland, USA) Jeremy Yallop (University of Cambridge, UK) External Review Committee: Michael D. Adams (University of Utah, USA) Amal Ahmed (Northeastern University, USA) Nada Amin (University of Cambridge, USA) Zena Ariola (University of Oregon) Lars Bergstrom (Mozilla Research) Lars Birkedal (Aarhus University, Denmark) Edwin Brady ( University of St. Andrews, UK) William Byrd (University of Alabama at Birmingham, USA) Giuseppe Castagna (CRNS / University of Paris Diderot, France) Sheng Chen (University of Louisiana at Lafayette, USA) Koen Claessen (Chalmers University ot Technology, Sweden) Ugo Dal Lago (University of Bologna, Italy / Inria, France) David Darais (University of Vermont, USA) Joshua Dunfield (Queen’s University, Canada) Richard Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Nate Foster (Cornell University, USA) Jurriaan Hage (Utrecht University, Netherlands) David Van Horn (University of Maryland, USA) Zhenjiang Hu (National Institute of Informatics, Japan) Suresh Jagannathan (Purdue University, USA) Simon Peyton Jones (Microsoft Research, UK) Naoki Kobayashi (University of Tokyo, Japan) Neelakantan Krishnaswami (University of Cambridge, UK) Kazutaka Matsuda (Tohoku University, Japan) Trevor McDonell (University of New South Wales, Australia) Hernan Melgratti (University of Buenos Aires, Argentina) Akimasa Morihata (University of Tokyo, Japan) Aleksandar Nanevski (IMDEA Software Institute, Spain) Kim Nguyễn (University of Paris-Sud, France) Cosmin Oancea (DIKU, University of Copenhagen, Denmark) Bruno C. d. S. Oliveira (University of Hong Kong, China) Tomas Petricek (University of Cambridge, UK) Benjamin Pierce (University of Pennsylvania, USA) Christine Rizkallah (University of Pennsylvania, USA) Tom Schrijvers (KU Leuven, Belgium) Manuel Serrano (Inria, France) Jeremy Siek (Indiana University, USA) Josef Svenningsson (Chalmers University of Technology, Sweden) Nicolas Tabareau (Inria, France) Dimitrios Vytiniotis (Microsoft Research, UK) Philip Wadler (University of Edinburgh, UK) Meng Wang (University of Kent, UK) From ben at well-typed.com Thu Mar 8 20:27:39 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 08 Mar 2018 15:27:39 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> References: <16206ca353f-179b-7363a@webjas-vaa099.srv.aolmail.net> Message-ID: <878tb22tzb.fsf@smart-cactus.org> Apostolos Syropoulos via Glasgow-haskell-users writes: > Hello, > > I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and > compilation never starts because: > Can you try applying the attached patch? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-configure-Accept-version-suffix-in-solaris-name.patch Type: text/x-patch Size: 1295 bytes Desc: not available URL: From allbery.b at gmail.com Fri Mar 9 00:48:25 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Mar 2018 19:48:25 -0500 Subject: [Haskell-cafe] do-notation for building monoid values In-Reply-To: References: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> <7EE7560E-2497-438F-B1B1-09B5F1331FC2@inconsistent.nl> Message-ID: The mconcat method is also how xmonad handles its ManageHooks, which are basically Endo Monoids. On Thu, Mar 8, 2018 at 8:48 AM, Andrew Martin wrote: > I do the same thing that Merijn does. It works really well. > > On Thu, Mar 8, 2018 at 8:08 AM, Merijn Verstraaten > wrote: > >> I always just use mconcat and lists, so instead of: >> > complicatedValue = execWriter $ do >> > component1 >> > component2 >> > modifier $ do >> > component3 >> > component4 >> >> I write: >> >> complicatedValue = mconcat >> [ component1 >> , component2 >> , modifier . mconcat $ [component3, component4] >> ] >> >> Alternatively, if component3 and component4 are really long or lots of >> them linewrap those too: >> >> complicatedValue = mconcat >> [ component1 >> , component2 >> , modifier . mconcat $ >> [ component3 >> , component4 >> ] >> ] >> >> Cheers, >> Merijn >> >> > On 8 Mar 2018, at 14:02, Olaf Klinke wrote: >> > >> > Dear cafe, >> > >> > prompted by a discussion with the author of blaze-markup [1] I realized >> a pattern and would like to know whether other haskellers have exploited >> this/find this useful: >> > >> > For every monoid m, the types Writer m () and m are isomorphic as types >> via tell and execWriter. Moreover, Writer m is a monad if and only if m is >> a monoid. For every monad t, the type t () is a monoid with >> > mempty = return () >> > mappend = (>>). >> > In the particular case of Writer m () and m, the isomorphism of Haskell >> types is in fact an isomorphism of monoids, that is, the functions tell and >> execWriter preserve the monoid operations. >> > >> > This enables us to use do-notation in building complicated values of >> any monoid type, e.g. Text or any other syntax. Instead of writing >> > >> > complicatedValue = component1 <> >> > component2 <> >> > modifier (component3 <> component4) >> > >> > one can write >> > >> > complicatedValue = execWriter $ do >> > component1 >> > component2 >> > modifier $ do >> > component3 >> > component4 >> > >> > Should such an idiom be encouraged/discouraged? How do you handle the >> construction of monoid values (especially text-like) with interspersed >> function applications (e.g. show, prettyprint)? >> > >> > Regards, >> > Olaf >> > >> > [1] https://github.com/jaspervdj/blaze-markup/issues/36 >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > -Andrew Thaddeus Martin > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Fri Mar 9 09:23:18 2018 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 9 Mar 2018 10:23:18 +0100 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: 2018-03-08 17:57 GMT+01:00 Ben Gamari : > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. [...] Just a few tiny remarks regarding "base": * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries says that the shipped "base" has version 2.1, I guess that should be 4.11.0.0. * https://wiki.haskell.org/Base_package needs an update. * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. Yes, there is https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, but Hackage is somehow the more canonical place to look up the package docs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Fri Mar 9 09:24:30 2018 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 09 Mar 2018 09:24:30 +0000 Subject: [Haskell-cafe] do-notation for building monoid values In-Reply-To: References: <41F2D50E-438D-4768-88DF-68CBF3B1BA0E@aatal-apotheke.de> <7EE7560E-2497-438F-B1B1-09B5F1331FC2@inconsistent.nl> Message-ID: Another mconcat user here. The only place it does fall down a bit is when you want something to be optional. In a monad we have `when`, but I don't know of any similar combinator for monoids. Of course, it's just `if x then y else mempty`, but I always end up defining a when-like function over and over again. On Fri, Mar 9, 2018 at 12:53 AM Brandon Allbery wrote: > The mconcat method is also how xmonad handles its ManageHooks, which are > basically Endo Monoids. > > On Thu, Mar 8, 2018 at 8:48 AM, Andrew Martin > wrote: > >> I do the same thing that Merijn does. It works really well. >> >> On Thu, Mar 8, 2018 at 8:08 AM, Merijn Verstraaten < >> merijn at inconsistent.nl> wrote: >> >>> I always just use mconcat and lists, so instead of: >>> > complicatedValue = execWriter $ do >>> > component1 >>> > component2 >>> > modifier $ do >>> > component3 >>> > component4 >>> >>> I write: >>> >>> complicatedValue = mconcat >>> [ component1 >>> , component2 >>> , modifier . mconcat $ [component3, component4] >>> ] >>> >>> Alternatively, if component3 and component4 are really long or lots of >>> them linewrap those too: >>> >>> complicatedValue = mconcat >>> [ component1 >>> , component2 >>> , modifier . mconcat $ >>> [ component3 >>> , component4 >>> ] >>> ] >>> >>> Cheers, >>> Merijn >>> >>> > On 8 Mar 2018, at 14:02, Olaf Klinke wrote: >>> > >>> > Dear cafe, >>> > >>> > prompted by a discussion with the author of blaze-markup [1] I >>> realized a pattern and would like to know whether other haskellers have >>> exploited this/find this useful: >>> > >>> > For every monoid m, the types Writer m () and m are isomorphic as >>> types via tell and execWriter. Moreover, Writer m is a monad if and only if >>> m is a monoid. For every monad t, the type t () is a monoid with >>> > mempty = return () >>> > mappend = (>>). >>> > In the particular case of Writer m () and m, the isomorphism of >>> Haskell types is in fact an isomorphism of monoids, that is, the functions >>> tell and execWriter preserve the monoid operations. >>> > >>> > This enables us to use do-notation in building complicated values of >>> any monoid type, e.g. Text or any other syntax. Instead of writing >>> > >>> > complicatedValue = component1 <> >>> > component2 <> >>> > modifier (component3 <> component4) >>> > >>> > one can write >>> > >>> > complicatedValue = execWriter $ do >>> > component1 >>> > component2 >>> > modifier $ do >>> > component3 >>> > component4 >>> > >>> > Should such an idiom be encouraged/discouraged? How do you handle the >>> construction of monoid values (especially text-like) with interspersed >>> function applications (e.g. show, prettyprint)? >>> > >>> > Regards, >>> > Olaf >>> > >>> > [1] https://github.com/jaspervdj/blaze-markup/issues/36 >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > To (un)subscribe, modify options or view archives go to: >>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> > Only members subscribed via the mailman list are allowed to post. >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> >> -- >> -Andrew Thaddeus Martin >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > brandon s allbery kf8nh sine nomine > associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Mar 9 13:47:30 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:47:30 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87k1ul1hu8.fsf@smart-cactus.org> Sven Panne writes: > 2018-03-08 17:57 GMT+01:00 Ben Gamari : > >> The GHC developers are very happy to announce the 8.4.1 release of >> Glasgow Haskell Compiler. [...] > > > Just a few tiny remarks regarding "base": > > * https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries > > says that the shipped "base" has version 2.1, I guess that should be > 4.11.0.0. > Good catch; in principle this should now be automatically generated. I'll need to look at what has gone wrong here. I've opened #14906 to track this. > * https://wiki.haskell.org/Base_package needs an update. > Ahh, thanks; I've added this to the MakingReleases protocol [1] to ensure that this is done in the future. > * Hackage has no 4.11.0.0 yet, that would be very helpful for the docs. > Yes, there is > https://downloads.haskell.org/~ghc/8.4.1/docs/html/libraries/index.html, > but Hackage is somehow the more canonical place to look up the package docs. Yes, the Hackage uploads have historically not been handled by me but rather Herbert. He know about the release and am certain has the task on his queue. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Mar 9 13:50:25 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 08:50:25 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: <87h8pp1hpd.fsf@smart-cactus.org> Niklas Larsson writes: > Hi! > > It says on the download page that the Windows versions is “excluding > the Windows 10 Creator’s Update”. I’m assuming that is a copy-paste > error from the release that fixed the Windows 10 CU bug. > Oh dear, yes. Thank you for noticing this. 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 Fri Mar 9 15:30:20 2018 From: david.feuer at gmail.com (David Feuer) Date: Fri, 9 Mar 2018 10:30:20 -0500 Subject: [Haskell-cafe] Dropping containers support for old GHC versions Message-ID: It's that time again. I'd very much like to drop containers support for GHC version 7.0 (so I can increase the lower bound on array to 0.4 for Safe Haskell-related reasons). I'd also prefer to drop support for GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not to. What do you all think? David From lemming at henning-thielemann.de Fri Mar 9 15:42:21 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Mar 2018 16:42:21 +0100 (CET) Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: On Fri, 9 Mar 2018, David Feuer wrote: > It's that time again. I'd very much like to drop containers support > for GHC version 7.0 (so I can increase the lower bound on array to 0.4 > for Safe Haskell-related reasons). I'd also prefer to drop support for > GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not > to. What do you all think? I am still mainly using GHC-7.4.2. From andrew.thaddeus at gmail.com Fri Mar 9 15:58:34 2018 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Fri, 9 Mar 2018 10:58:34 -0500 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: I'm +1 on this. I do not use any of those versions of GHC. On Fri, Mar 9, 2018 at 10:30 AM, David Feuer wrote: > It's that time again. I'd very much like to drop containers support > for GHC version 7.0 (so I can increase the lower bound on array to 0.4 > for Safe Haskell-related reasons). I'd also prefer to drop support for > GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not > to. What do you all think? > > David > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Mar 9 16:00:28 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Mar 2018 17:00:28 +0100 (CET) Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: On Fri, 9 Mar 2018, Daniel Cartwright wrote: > I am +1 on this. > GHC 7.0 is 8 years old > GHC 7.2 is 7 years old > GHC 7.4 is 6 years old > > On a related note, I find it strange when looking through source code for 'containers'/other Haskell libraries > and still see notes about supporting non-GHC Haskell compilers (e.g. Hugs) Recently we got to install Hugs on a Lego machine - installation required several minutes. I would not try to install GHC there. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Mar 9 16:02:00 2018 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 9 Mar 2018 16:02:00 +0000 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: <20180309160200.GI2948@weber> On Fri, Mar 09, 2018 at 04:42:21PM +0100, Henning Thielemann wrote: > On Fri, 9 Mar 2018, David Feuer wrote: > > >It's that time again. I'd very much like to drop containers support > >for GHC version 7.0 (so I can increase the lower bound on array to 0.4 > >for Safe Haskell-related reasons). I'd also prefer to drop support for > >GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not > >to. What do you all think? > > I am still mainly using GHC-7.4.2. I'm rather curious why! From david.feuer at gmail.com Fri Mar 9 16:08:22 2018 From: david.feuer at gmail.com (David Feuer) Date: Fri, 9 Mar 2018 11:08:22 -0500 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: On Mar 9, 2018 10:55 AM, "Daniel Cartwright" wrote: On a related note, I find it strange when looking through source code for 'containers'/other Haskell libraries and still see notes about supporting non-GHC Haskell compilers (e.g. Hugs) I believe we've stripped all references to Hugs and nhc98 from containers. If you find any, let us know. I'd be interested in adding support for Frege, but the way it deals with numeric literals could be problematic. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri Mar 9 16:12:40 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 9 Mar 2018 11:12:40 -0500 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: <20180309160200.GI2948@weber> References: <20180309160200.GI2948@weber> Message-ID: Because not everyone has access to the latest and greatest hardware? (Which attitude is showing just a bit of privilege.) At CMU I got to ride herd on a rather astonishing collection of ancient hardware; I wouldn't be looking to install ghc8 on much of it either, since usually upgrading the OS is no-go and I'd have to backport a lot of stuff to get it --- and, even more so, packages using it --- to build at all. On Fri, Mar 9, 2018 at 11:02 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, Mar 09, 2018 at 04:42:21PM +0100, Henning Thielemann wrote: > > On Fri, 9 Mar 2018, David Feuer wrote: > > > > >It's that time again. I'd very much like to drop containers support > > >for GHC version 7.0 (so I can increase the lower bound on array to 0.4 > > >for Safe Haskell-related reasons). I'd also prefer to drop support for > > >GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not > > >to. What do you all think? > > > > I am still mainly using GHC-7.4.2. > > I'm rather curious why! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Mar 9 16:14:17 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Mar 2018 17:14:17 +0100 (CET) Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: <20180309160200.GI2948@weber> References: <20180309160200.GI2948@weber> Message-ID: On Fri, 9 Mar 2018, Tom Ellis wrote: > On Fri, Mar 09, 2018 at 04:42:21PM +0100, Henning Thielemann wrote: >> On Fri, 9 Mar 2018, David Feuer wrote: >> >> >It's that time again. I'd very much like to drop containers support >> >for GHC version 7.0 (so I can increase the lower bound on array to 0.4 >> >for Safe Haskell-related reasons). I'd also prefer to drop support for >> >GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not >> >to. What do you all think? >> >> I am still mainly using GHC-7.4.2. > > I'm rather curious why! GHC-7.8.4 is the last compiler that prevents me from "length (1,2)" but it has a bug in the optimizer that leads to a compiler crash. So I have the choice between GHC-7.6.3 and GHC-7.4.2. From david.feuer at gmail.com Fri Mar 9 16:28:13 2018 From: david.feuer at gmail.com (David Feuer) Date: Fri, 9 Mar 2018 11:28:13 -0500 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: <20180309160200.GI2948@weber> Message-ID: How would you feel about switching to 7.6.3? That would definitely make my life easier. I have to warn you, however, that we will not support 7.6 or 7.8 forever. We'll probably drop 7.6 in another year or two, and 7.8 in another two or three. On Mar 9, 2018 11:15 AM, "Henning Thielemann" wrote: > > On Fri, 9 Mar 2018, Tom Ellis wrote: > > On Fri, Mar 09, 2018 at 04:42:21PM +0100, Henning Thielemann wrote: >> >>> On Fri, 9 Mar 2018, David Feuer wrote: >>> >>> >It's that time again. I'd very much like to drop containers support >>> >for GHC version 7.0 (so I can increase the lower bound on array to 0.4 >>> >for Safe Haskell-related reasons). I'd also prefer to drop support for >>> >GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not >>> >to. What do you all think? >>> >>> I am still mainly using GHC-7.4.2. >>> >> >> I'm rather curious why! >> > > GHC-7.8.4 is the last compiler that prevents me from "length (1,2)" but it > has a bug in the optimizer that leads to a compiler crash. So I have the > choice between GHC-7.6.3 and GHC-7.4.2. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Mar 9 16:29:13 2018 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 9 Mar 2018 16:29:13 +0000 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: <20180309160200.GI2948@weber> Message-ID: <20180309162913.GJ2948@weber> On Fri, Mar 09, 2018 at 11:12:40AM -0500, Brandon Allbery wrote: > Because not everyone has access to the latest and greatest hardware? (Which > attitude is showing just a bit of privilege.) > [...] I think you may be reading something into my message that I didn't say. From moritz.kiefer at purelyfunctional.org Fri Mar 9 16:31:44 2018 From: moritz.kiefer at purelyfunctional.org (Moritz Kiefer) Date: Fri, 9 Mar 2018 17:31:44 +0100 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: <20180309160200.GI2948@weber> Message-ID: <1f40cfd2-f26c-dc5c-c308-336c45f55435@purelyfunctional.org> That’s fair enough but couldn’t you just keep using an older version of `containers` on this hardware? Obviously, newer versions will contain bugfixes and new features but the same can be said for new releases of GHC (and probably a ton of other software on those systems) and missing out on those is apparently not a deal-breaker either. Cheers Moritz On 03/09/2018 05:12 PM, Brandon Allbery wrote: > Because not everyone has access to the latest and greatest hardware? > (Which attitude is showing just a bit of privilege.) At CMU I got to > ride herd on a rather astonishing collection of ancient hardware; I > wouldn't be looking to install ghc8 on much of it either, since usually > upgrading the OS is no-go and I'd have to backport a lot of stuff to get > it --- and, even more so, packages using it --- to build at all. > > On Fri, Mar 9, 2018 at 11:02 AM, Tom Ellis > > wrote: > > On Fri, Mar 09, 2018 at 04:42:21PM +0100, Henning Thielemann wrote: > > On Fri, 9 Mar 2018, David Feuer wrote: > > > > >It's that time again. I'd very much like to drop containers support > > >for GHC version 7.0 (so I can increase the lower bound on array to 0.4 > > >for Safe Haskell-related reasons). I'd also prefer to drop support for > > >GHC versions 7.2 and 7.4, but I'm somewhat open to being convinced not > > >to. What do you all think? > > > > I am still mainly using GHC-7.4.2. > > I'm rather curious why! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > > -- > brandon s allbery kf8nh                               sine nomine associates > allbery.b at gmail.com                         >          ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lemming at henning-thielemann.de Fri Mar 9 16:32:49 2018 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 9 Mar 2018 17:32:49 +0100 (CET) Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: <20180309160200.GI2948@weber> Message-ID: On Fri, 9 Mar 2018, David Feuer wrote: > How would you feel about switching to 7.6.3? That would definitely make > my life easier. I have to warn you, however, that we will not support > 7.6 or 7.8 forever. We'll probably drop 7.6 in another year or two, and > 7.8 in another two or three. I am happy to switch to any new GHC if there will be at least a warning for "length (1,2)": https://ghc.haskell.org/trac/ghc/ticket/11796 From adam at bergmark.nl Fri Mar 9 16:35:10 2018 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 09 Mar 2018 16:35:10 +0000 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: I appreciate that it may be hard/undesirable for some to use the latest GHC, but overall I don't think we should need to maintain backwards compatibility indefinitely because of that. Older versions of containers will still work with older GHCs, and other libraries depending on containers will still work as well as long as they support older container versions. But nevertheless, at least it seems there are no objections to dropping 7.0 and 7.2.2 support so far? :) Cheers, Adam On Fri, 9 Mar 2018 at 17:20 Daniel Cartwright wrote: > David, I just checked and you're correct - I believe I was remembering > some other library(ies), though I can't recall which ones. > > On Fri, Mar 9, 2018 at 11:08 AM, David Feuer > wrote: > >> On Mar 9, 2018 10:55 AM, "Daniel Cartwright" >> wrote: >> >> >> On a related note, I find it strange when looking through source code for >> 'containers'/other Haskell libraries and still see notes about supporting >> non-GHC Haskell compilers (e.g. Hugs) >> >> >> I believe we've stripped all references to Hugs and nhc98 from >> containers. If you find any, let us know. I'd be interested in adding >> support for Frege, but the way it deals with numeric literals could be >> problematic. >> >> > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Mar 9 17:15:13 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Mar 2018 12:15:13 -0500 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: References: <87h8pq33p8.fsf@smart-cactus.org> <87h8pp1hpd.fsf@smart-cactus.org> Message-ID: <871sgt1883.fsf@smart-cactus.org> Vassil Ognyanov Keremidchiev writes: > I saw there is ARM Aarch64 build, which is pretty cool! But will there be a > ARMv7 (32bit build) as well? > I do hope so. There have been a number of false-starts but hopefully the build that is currently running will finish. Unfortunately getting a working ARMv7 build is rather tricky due to a number of linker bugs that bite under various circumstances. 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 takenobu.hs at gmail.com Sat Mar 10 02:57:59 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 10 Mar 2018 11:57:59 +0900 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Hi, Before exploring Cardano's virtual machine, I explored Ethereum virtual machine (EVM). I'm sharing some figures I wrote for my self-study. Ethereum EVM illustrated http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf https://github.com/takenobu-hs/ethereum-evm-illustrated Haskell fits very well to DApps/Smart contracts :) Regards, Takenobu 2018-01-27 11:27 GMT+09:00 Takenobu Tani : > Hi Gregory, > > Thank you for much information. > I have heard Cardano, but I did not know the details. > > It's amazing! > > Although Ethereum VM is stack based virtual machine, > Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! > In addition, it is protected by semantics. > > Umm, High-level safety abstructed language (Haskell based) + register > based VM (IELE) ! > It's amazing. > > Thank you for telling me details. > I will explore this. > > Thank you very much, > Takenobu > > > 2018-01-27 10:22 GMT+09:00 Gregory Popovitch : > >> Probably you are aware of Cardano (https://www.cardanohub.org/en/home/), >> a new generation blockchain platform which uses languages inspired from >> Haskell. From the whitepaper at https://whycardano.com/: >> >> "Systems such as Bitcoin provide an extremely inflexible and draconian >> scripting language that is difficult to program bespoke transactions in, >> and to read and understand. Yet the general programmability of languages >> such as Solidity introduce an extraordinary amount of complexity into the >> system and are useful to only a much smaller set of actors. >> >> Therefore, we have chosen to design a new language called Simon6 >> in honor of its creator Simon >> Thompson and the creator of the concepts that inspired it, Simon Peyton >> Jones. Simon is a domain-specific language that is based upon *Composing >> contracts: an adventure in financial engineering >> *. >> >> The principal idea is that financial transactions are generally composed >> from a collection of foundational elements7 >> . If one assembles a financial >> periodic table of elements, then one can provide support for an arbitrarily >> large set of compound transactions that will cover most, if not all, common >> transaction types without requiring general programmability. >> >> The primary advantage is that security and execution can be extremely >> well understood. Proofs can be written to show correctness of templates and >> exhaust the execution space of problematic transaction events, such as the >> creation of new money out of thin air >> or transaction >> malleability . >> Second, one can leave in extensions to add more elements by way of soft >> forks if new functionality is required. >> >> That said, there will always be a need to connect CSL to overlay >> protocols, legacy financial systems, and special purpose servers. Thus we >> have developed Plutus >> as both a general >> purpose smart contract language and also a special purpose DSL for >> interoperability. >> >> Plutus is a typed functional language based on concepts from Haskell, >> which can be used to write custom transaction scripts. For CSL, it will be >> used for complex transactions required to add support for other layers we >> need to connect, such as our sidechains scheme." >> >> ------------------------------ >> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On >> Behalf Of *Takenobu Tani >> *Sent:* Friday, January 26, 2018 8:05 PM >> *To:* Patrick Mylund Nielsen >> *Cc:* haskell-cafe >> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >> >> Hi Carter, Patrick, >> >> Thank you for reply. >> Quorum is interesting! >> It would be very nice to be able to describe Ethereum's contract with >> Haskell DSL. >> The characteristics about immutable and type will fit DApps. >> >> Thank you very much, >> Takenobu >> >> >> >> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen : >> >>> The Quorum[1] team has been dreaming about such a >>> Haskell-beginner-friendly bytecode-generating DSL for a very long time. >>> The user experience of writing applications in a language where pitfalls >>> are so non-obvious is one of the biggest pain points of Ethereum in >>> general. >>> >>> We would warmly welcome something like this, and would definitely look >>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>> >>> [1]: A permissioned/non-PoW version of Ethereum with high throughput and >>> privacy - https://github.com/jpmorganchase/quorum/ >>> >>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>> > Hello Takenobu, >>> > while theres definitely a lot of haskell code out there that deals with >>> > ethereum (or implementing it!), i'm not aware of anything targeting the >>> > evm isa from haskell or any other mature functional programming >>> language >>> > >>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani >> > > wrote: >>> > >>> > Hi cafe, >>> > >>> > Does anyone know about the code generator from Haskell's syntax to >>> > Ethereum VM language (bytecode)? >>> > That is, what corresponds to Solidity in Haskell. >>> > >>> > Although Solidity is interesting, it's difficult for me to achieve >>> > quality and safety. >>> > Does such a project already exist? >>> > >>> > Regards, >>> > Takenobu >>> > >>> > >>> > >>> > _______________________________________________ >>> > Haskell-Cafe mailing list >>> > To (un)subscribe, modify options or view 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 wjmartino at gmail.com Sat Mar 10 06:51:49 2018 From: wjmartino at gmail.com (William Martino) Date: Sat, 10 Mar 2018 06:51:49 +0000 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Hi, You may also want to look at another (formerly) JPM project https://github.com/kadena-io/masala -- standalone pure EVM. When it was up to date it was pretty close to bug for bug compatible... yes, the EVM unit tests checked for at least one bug's existence. FYI the degree to/ways in which the EVM is hilariously broken were large influences on [disclosure: am co-founder] Kadena's smart contract language Pact https://github.com/kadena-io/pact. I wouldn't say that Pact is a competitor to Cardano's Plutus so much as a fundamentally different approach. -Will  - Will ---------- Will Martino WJMartino at gmail.com 203.887.6964 Sent via Superhuman ( https://sprh.mn/?vip=wjmartino at gmail.com ) On Fri, Mar 09, 2018 at 9:57 PM, Takenobu Tani < takenobu.hs at gmail.com > wrote: > > Hi, > > Before exploring Cardano's virtual machine, I explored Ethereum virtual > machine (EVM). > I'm sharing some figures I wrote for my self-study. > >   Ethereum EVM illustrated >  http:/ / takenobu-hs. github. io/ downloads/ ethereum_evm_illustrated. pdf > ( http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf ) >  https:/ / github. com/ takenobu-hs/ ethereum-evm-illustrated ( > https://github.com/takenobu-hs/ethereum-evm-illustrated ) > > Haskell fits very well to DApps/Smart contracts :) > > Regards, > Takenobu > > > > 2018-01-27 11:27 GMT+09:00 Takenobu Tani < takenobu. hs@ gmail. com ( > takenobu.hs at gmail.com ) > : > >> Hi Gregory, >> >> Thank you for much information. >> I have heard Cardano, but I did not know the details. >> >> It's amazing! >> >> Although Ethereum VM is stack based virtual machine, >> Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! >> In addition, it is protected by semantics. >> >> Umm, High-level safety abstructed language (Haskell based) + register >> based VM (IELE) ! >> It's amazing. >> >> Thank you for telling me details. >> I will explore this. >> >> Thank you very much, >> Takenobu >> >> >> >> 2018-01-27 10:22 GMT+09:00 Gregory Popovitch < greg7mdp@ gmail. com ( >> greg7mdp at gmail.com ) > : >> >>> Probably you are aware of Cardano ( https://www.cardanohub.org/en /home/ ( >>> https://www.cardanohub.org/en/home/ ) ), a new generation blockchain >>> platform which uses languages inspired from Haskell. From the whitepaper >>> at https:/ / whycardano. com/ ( https://whycardano.com/ ) : >>>   >>> "Systems such as Bitcoin provide an extremely inflexible and draconian >>> scripting language that is difficult to program bespoke transactions in, >>> and to read and understand. Yet the general programmability of languages >>> such as Solidity introduce an extraordinary amount of complexity into the >>> system and are useful to only a much smaller set of actors. >>> >>> Therefore, we have chosen to design a new language called Simon 6 ( >>> https://whycardano.com/#footnote6 ) in honor of its creator Simon Thompson >>> and the creator of the concepts that inspired it, Simon Peyton Jones. >>> Simon is a domain-specific language that is based upon Composing >>> contracts: an adventure in financial engineering ( >>> https://www.lexifi.com/files/resources/MLFiPaper.pdf ). >>> >>> >>> >>> The principal idea is that financial transactions are generally composed >>> from a collection of foundational elements 7 ( >>> https://whycardano.com/#footnote7 ). If one assembles a financial periodic >>> table of elements, then one can provide support for an arbitrarily large >>> set of compound transactions that will cover most, if not all, common >>> transaction types without requiring general programmability. >>> >>> >>> >>> The primary advantage is that security and execution can be extremely well >>> understood. Proofs can be written to show correctness of templates and >>> exhaust the execution space of problematic transaction events, such as the >>> creation of new money out of thin air ( >>> https://en.bitcoin.it/wiki/Value_overflow_incident ) or transaction >>> malleability ( https://en.bitcoin.it/wiki/Transaction_Malleability ). >>> Second, one can leave in extensions to add more elements by way of soft >>> forks if new functionality is required. >>> >>> >>> >>> That said, there will always be a need to connect CSL to overlay >>> protocols, legacy financial systems, and special purpose servers. Thus we >>> have developed Plutus ( https://github.com/input-output-hk/plutus-prototype >>> ) as both a general purpose smart contract language and also a special >>> purpose DSL for interoperability. >>> >>> >>> >>> Plutus is a typed functional language based on concepts from Haskell, >>> which can be used to write custom transaction scripts. For CSL, it will be >>> used for complex transactions required to add support for other layers we >>> need to connect, such as our sidechains scheme. " >>> >>> >>> >>> *From:* Haskell-Cafe [mailto: haskell-cafe-bounces at h askell.org ( >>> haskell-cafe-bounces at haskell.org ) ] *On Behalf Of* Takenobu Tani >>> *Sent:* Friday, January 26, 2018 8:05 PM >>> *To:* Patrick Mylund Nielsen >>> *Cc:* haskell-cafe >>> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >>> >>> >>> >>> Hi Carter, Patrick, >>> >>> Thank you for reply. >>> Quorum is interesting! >>> It would be very nice to be able to describe Ethereum's contract with >>> Haskell DSL. >>> The characteristics about immutable and type will fit DApps. >>> >>> Thank you very much, >>> Takenobu >>> >>> >>> >>> >>> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen < haskell@ patrickmn. com >>> ( haskell at patrickmn.com ) > : >>> >>>> The Quorum[1] team has been dreaming about such a >>>> Haskell-beginner-friendly bytecode-generating DSL for a very long time. >>>> The user experience of writing applications in a language where pitfalls >>>> are so non-obvious is one of the biggest pain points of Ethereum in >>>> general. >>>> >>>> We would warmly welcome something like this, and would definitely look >>>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>>> >>>> [1]: A permissioned/non-PoW version of Ethereum with high throughput and >>>> privacy - https://github.com/jpmorgancha se/quorum/ ( >>>> https://github.com/jpmorganchase/quorum/ ) >>>> >>>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>>> > Hello Takenobu,  >>>> > while theres definitely a lot of haskell code out there that deals with >>>> > ethereum (or implementing it!), i'm not aware of anything targeting the >>>> > evm isa from haskell or any other mature functional programming language >>>> >>>> > >>>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani < takenobu. hs@ gmail. com >>>> ( takenobu.hs at gmail.com ) >>>> > > wrote: >>>> > >>>> >     Hi cafe, >>>> > >>>> >     Does anyone know about the code generator from Haskell's syntax to >>>> >     Ethereum VM language (bytecode)? >>>> >     That is, what corresponds to Solidity in Haskell. >>>> > >>>> >     Although Solidity is interesting, it's difficult for me to achieve >>>> >     quality and safety. >>>> >     Does such a project already exist? >>>> > >>>> >     Regards, >>>> >     Takenobu >>>> > >>>> > >>>> > >>>> >     _____________________________ __________________ >>>> >     Haskell-Cafe mailing list >>>> >     To (un)subscribe, modify options or view archives go to: >>>> >     http://mail.haskell.org/cgi-b in/mailman/listinfo/haskell-ca fe ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) >>>> >     < http://mail.haskell.org/cgi- bin/mailman/listinfo/haskell-c afe ( >>>> 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-bi n/mailman/listinfo/haskell-caf e ( >>>> 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 ( > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only > members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat Mar 10 09:25:49 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 10 Mar 2018 18:25:49 +0900 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Hi Will, Thank you for the information. There are various smart contract environments using Haskell. I will explore various projects. Thanks, Takenobu 2018-03-10 15:51 GMT+09:00 William Martino : > Hi, > > You may also want to look at another (formerly) JPM project > https://github.com/kadena-io/masala -- standalone pure EVM. When it was > up to date it was pretty close to bug for bug compatible... yes, the EVM > unit tests checked for at least one bug's existence. > > FYI the degree to/ways in which the EVM is hilariously broken were large > influences on [disclosure: am co-founder] Kadena's smart contract language > Pact https://github.com/kadena-io/pact. I wouldn't say that Pact is a > competitor to Cardano's Plutus so much as a fundamentally different > approach. > > -Will > > > - Will > > ---------- > Will Martino > WJMartino at gmail.com > 203.887.6964 <(203)%20887-6964> > > Sent via Superhuman > > > On Fri, Mar 09, 2018 at 9:57 PM, Takenobu Taniwro > te: > >> Hi, >> >> Before exploring Cardano's virtual machine, I explored Ethereum virtual >> machine (EVM). >> I'm sharing some figures I wrote for my self-study. >> >> Ethereum EVM illustrated >> http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf >> https://github.com/takenobu-hs/ethereum-evm-illustrated >> >> Haskell fits very well to DApps/Smart contracts :) >> >> Regards, >> Takenobu >> >> >> 2018-01-27 11:27 GMT+09:00 Takenobu Tani : >> >>> Hi Gregory, >>> >>> Thank you for much information. >>> I have heard Cardano, but I did not know the details. >>> >>> It's amazing! >>> >>> Although Ethereum VM is stack based virtual machine, >>> Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! >>> In addition, it is protected by semantics. >>> >>> Umm, High-level safety abstructed language (Haskell based) + register >>> based VM (IELE) ! >>> It's amazing. >>> >>> Thank you for telling me details. >>> I will explore this. >>> >>> Thank you very much, >>> Takenobu >>> >>> >>> 2018-01-27 10:22 GMT+09:00 Gregory Popovitch : >>> >>>> Probably you are aware of Cardano (https://www.cardanohub.org/en/home/), >>>> a new generation blockchain platform which uses languages inspired from >>>> Haskell. From the whitepaper at https://whycardano.com/: >>>> >>>> "Systems such as Bitcoin provide an extremely inflexible and draconian >>>> scripting language that is difficult to program bespoke transactions in, >>>> and to read and understand. Yet the general programmability of languages >>>> such as Solidity introduce an extraordinary amount of complexity into the >>>> system and are useful to only a much smaller set of actors. >>>> >>>> Therefore, we have chosen to design a new language called Simon6 >>>> in honor of its creator Simon >>>> Thompson and the creator of the concepts that inspired it, Simon Peyton >>>> Jones. Simon is a domain-specific language that is based upon *Composing >>>> contracts: an adventure in financial engineering >>>> *. >>>> >>>> The principal idea is that financial transactions are generally >>>> composed from a collection of foundational elements7 >>>> . If one assembles a financial >>>> periodic table of elements, then one can provide support for an arbitrarily >>>> large set of compound transactions that will cover most, if not all, common >>>> transaction types without requiring general programmability. >>>> >>>> The primary advantage is that security and execution can be extremely >>>> well understood. Proofs can be written to show correctness of templates and >>>> exhaust the execution space of problematic transaction events, such as the >>>> creation of new money out of thin air >>>> or transaction >>>> malleability . >>>> Second, one can leave in extensions to add more elements by way of soft >>>> forks if new functionality is required. >>>> >>>> That said, there will always be a need to connect CSL to overlay >>>> protocols, legacy financial systems, and special purpose servers. Thus we >>>> have developed Plutus >>>> as both a >>>> general purpose smart contract language and also a special purpose DSL for >>>> interoperability. >>>> >>>> Plutus is a typed functional language based on concepts from Haskell, >>>> which can be used to write custom transaction scripts. For CSL, it will be >>>> used for complex transactions required to add support for other layers we >>>> need to connect, such as our sidechains scheme." >>>> >>>> ------------------------------ >>>> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On >>>> Behalf Of *Takenobu Tani >>>> *Sent:* Friday, January 26, 2018 8:05 PM >>>> *To:* Patrick Mylund Nielsen >>>> *Cc:* haskell-cafe >>>> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >>>> >>>> Hi Carter, Patrick, >>>> >>>> Thank you for reply. >>>> Quorum is interesting! >>>> It would be very nice to be able to describe Ethereum's contract with >>>> Haskell DSL. >>>> The characteristics about immutable and type will fit DApps. >>>> >>>> Thank you very much, >>>> Takenobu >>>> >>>> >>>> >>>> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen >>> >: >>>> >>>>> The Quorum[1] team has been dreaming about such a >>>>> Haskell-beginner-friendly bytecode-generating DSL for a very long time. >>>>> The user experience of writing applications in a language where >>>>> pitfalls >>>>> are so non-obvious is one of the biggest pain points of Ethereum in >>>>> general. >>>>> >>>>> We would warmly welcome something like this, and would definitely look >>>>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>>>> >>>>> [1]: A permissioned/non-PoW version of Ethereum with high throughput >>>>> and >>>>> privacy - https://github.com/jpmorganchase/quorum/ >>>>> >>>>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>>>> > Hello Takenobu, >>>>> > while theres definitely a lot of haskell code out there that deals >>>>> with >>>>> > ethereum (or implementing it!), i'm not aware of anything targeting >>>>> the >>>>> > evm isa from haskell or any other mature functional programming >>>>> language >>>>> > >>>>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani < >>>>> takenobu.hs at gmail.com >>>>> > > wrote: >>>>> > >>>>> > Hi cafe, >>>>> > >>>>> > Does anyone know about the code generator from Haskell's syntax >>>>> to >>>>> > Ethereum VM language (bytecode)? >>>>> > That is, what corresponds to Solidity in Haskell. >>>>> > >>>>> > Although Solidity is interesting, it's difficult for me to >>>>> achieve >>>>> > quality and safety. >>>>> > Does such a project already exist? >>>>> > >>>>> > Regards, >>>>> > Takenobu >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > Haskell-Cafe mailing list >>>>> > To (un)subscribe, modify options or view 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 leiva.steven at gmail.com Sat Mar 10 16:20:24 2018 From: leiva.steven at gmail.com (Steven Leiva) Date: Sat, 10 Mar 2018 10:20:24 -0600 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Fantastic write-up Takenobu. On Sat, Mar 10, 2018 at 3:25 AM, Takenobu Tani wrote: > Hi Will, > > Thank you for the information. > There are various smart contract environments using Haskell. > I will explore various projects. > > Thanks, > Takenobu > > 2018-03-10 15:51 GMT+09:00 William Martino : > >> Hi, >> >> You may also want to look at another (formerly) JPM project >> https://github.com/kadena-io/masala -- standalone pure EVM. When it was >> up to date it was pretty close to bug for bug compatible... yes, the EVM >> unit tests checked for at least one bug's existence. >> >> FYI the degree to/ways in which the EVM is hilariously broken were large >> influences on [disclosure: am co-founder] Kadena's smart contract language >> Pact https://github.com/kadena-io/pact. I wouldn't say that Pact is a >> competitor to Cardano's Plutus so much as a fundamentally different >> approach. >> >> -Will >> >> >> - Will >> >> ---------- >> Will Martino >> WJMartino at gmail.com >> 203.887.6964 <(203)%20887-6964> >> >> Sent via Superhuman >> >> >> On Fri, Mar 09, 2018 at 9:57 PM, Takenobu Taniwro >> te: >> >>> Hi, >>> >>> Before exploring Cardano's virtual machine, I explored Ethereum virtual >>> machine (EVM). >>> I'm sharing some figures I wrote for my self-study. >>> >>> Ethereum EVM illustrated >>> http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf >>> https://github.com/takenobu-hs/ethereum-evm-illustrated >>> >>> Haskell fits very well to DApps/Smart contracts :) >>> >>> Regards, >>> Takenobu >>> >>> >>> 2018-01-27 11:27 GMT+09:00 Takenobu Tani : >>> >>>> Hi Gregory, >>>> >>>> Thank you for much information. >>>> I have heard Cardano, but I did not know the details. >>>> >>>> It's amazing! >>>> >>>> Although Ethereum VM is stack based virtual machine, >>>> Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! >>>> In addition, it is protected by semantics. >>>> >>>> Umm, High-level safety abstructed language (Haskell based) + register >>>> based VM (IELE) ! >>>> It's amazing. >>>> >>>> Thank you for telling me details. >>>> I will explore this. >>>> >>>> Thank you very much, >>>> Takenobu >>>> >>>> >>>> 2018-01-27 10:22 GMT+09:00 Gregory Popovitch : >>>> >>>>> Probably you are aware of Cardano (https://www.cardanohub.org/en/home/), >>>>> a new generation blockchain platform which uses languages inspired from >>>>> Haskell. From the whitepaper at https://whycardano.com/: >>>>> >>>>> "Systems such as Bitcoin provide an extremely inflexible and draconian >>>>> scripting language that is difficult to program bespoke transactions in, >>>>> and to read and understand. Yet the general programmability of languages >>>>> such as Solidity introduce an extraordinary amount of complexity into the >>>>> system and are useful to only a much smaller set of actors. >>>>> >>>>> Therefore, we have chosen to design a new language called Simon6 >>>>> in honor of its creator Simon >>>>> Thompson and the creator of the concepts that inspired it, Simon Peyton >>>>> Jones. Simon is a domain-specific language that is based upon *Composing >>>>> contracts: an adventure in financial engineering >>>>> *. >>>>> >>>>> The principal idea is that financial transactions are generally >>>>> composed from a collection of foundational elements7 >>>>> . If one assembles a financial >>>>> periodic table of elements, then one can provide support for an arbitrarily >>>>> large set of compound transactions that will cover most, if not all, common >>>>> transaction types without requiring general programmability. >>>>> >>>>> The primary advantage is that security and execution can be extremely >>>>> well understood. Proofs can be written to show correctness of templates and >>>>> exhaust the execution space of problematic transaction events, such as the >>>>> creation of new money out of thin air >>>>> or transaction >>>>> malleability . >>>>> Second, one can leave in extensions to add more elements by way of soft >>>>> forks if new functionality is required. >>>>> >>>>> That said, there will always be a need to connect CSL to overlay >>>>> protocols, legacy financial systems, and special purpose servers. Thus we >>>>> have developed Plutus >>>>> as both a >>>>> general purpose smart contract language and also a special purpose DSL for >>>>> interoperability. >>>>> >>>>> Plutus is a typed functional language based on concepts from Haskell, >>>>> which can be used to write custom transaction scripts. For CSL, it will be >>>>> used for complex transactions required to add support for other layers we >>>>> need to connect, such as our sidechains scheme." >>>>> >>>>> ------------------------------ >>>>> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On >>>>> Behalf Of *Takenobu Tani >>>>> *Sent:* Friday, January 26, 2018 8:05 PM >>>>> *To:* Patrick Mylund Nielsen >>>>> *Cc:* haskell-cafe >>>>> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >>>>> >>>>> Hi Carter, Patrick, >>>>> >>>>> Thank you for reply. >>>>> Quorum is interesting! >>>>> It would be very nice to be able to describe Ethereum's contract with >>>>> Haskell DSL. >>>>> The characteristics about immutable and type will fit DApps. >>>>> >>>>> Thank you very much, >>>>> Takenobu >>>>> >>>>> >>>>> >>>>> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen < >>>>> haskell at patrickmn.com>: >>>>> >>>>>> The Quorum[1] team has been dreaming about such a >>>>>> Haskell-beginner-friendly bytecode-generating DSL for a very long >>>>>> time. >>>>>> The user experience of writing applications in a language where >>>>>> pitfalls >>>>>> are so non-obvious is one of the biggest pain points of Ethereum in >>>>>> general. >>>>>> >>>>>> We would warmly welcome something like this, and would definitely look >>>>>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>>>>> >>>>>> [1]: A permissioned/non-PoW version of Ethereum with high throughput >>>>>> and >>>>>> privacy - https://github.com/jpmorganchase/quorum/ >>>>>> >>>>>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>>>>> > Hello Takenobu, >>>>>> > while theres definitely a lot of haskell code out there that deals >>>>>> with >>>>>> > ethereum (or implementing it!), i'm not aware of anything targeting >>>>>> the >>>>>> > evm isa from haskell or any other mature functional programming >>>>>> language >>>>>> > >>>>>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani < >>>>>> takenobu.hs at gmail.com >>>>>> > > wrote: >>>>>> > >>>>>> > Hi cafe, >>>>>> > >>>>>> > Does anyone know about the code generator from Haskell's syntax >>>>>> to >>>>>> > Ethereum VM language (bytecode)? >>>>>> > That is, what corresponds to Solidity in Haskell. >>>>>> > >>>>>> > Although Solidity is interesting, it's difficult for me to >>>>>> achieve >>>>>> > quality and safety. >>>>>> > Does such a project already exist? >>>>>> > >>>>>> > Regards, >>>>>> > Takenobu >>>>>> > >>>>>> > >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Haskell-Cafe mailing list >>>>>> > To (un)subscribe, modify options or view 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. >>> >> >> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Steven Leiva 305.528.6038 leiva.steven at gmail.com http://www.linkedin.com/in/stevenleiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sun Mar 11 01:37:37 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 11 Mar 2018 10:37:37 +0900 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Thanks :) 2018-03-11 1:20 GMT+09:00 Steven Leiva : > Fantastic write-up Takenobu. > > On Sat, Mar 10, 2018 at 3:25 AM, Takenobu Tani > wrote: > >> Hi Will, >> >> Thank you for the information. >> There are various smart contract environments using Haskell. >> I will explore various projects. >> >> Thanks, >> Takenobu >> >> 2018-03-10 15:51 GMT+09:00 William Martino : >> >>> Hi, >>> >>> You may also want to look at another (formerly) JPM project >>> https://github.com/kadena-io/masala -- standalone pure EVM. When it was >>> up to date it was pretty close to bug for bug compatible... yes, the EVM >>> unit tests checked for at least one bug's existence. >>> >>> FYI the degree to/ways in which the EVM is hilariously broken were large >>> influences on [disclosure: am co-founder] Kadena's smart contract language >>> Pact https://github.com/kadena-io/pact. I wouldn't say that Pact is a >>> competitor to Cardano's Plutus so much as a fundamentally different >>> approach. >>> >>> -Will >>> >>> >>> - Will >>> >>> ---------- >>> Will Martino >>> WJMartino at gmail.com >>> 203.887.6964 <(203)%20887-6964> >>> >>> Sent via Superhuman >>> >>> >>> On Fri, Mar 09, 2018 at 9:57 PM, Takenobu Taniwro >>> te: >>> >>>> Hi, >>>> >>>> Before exploring Cardano's virtual machine, I explored Ethereum virtual >>>> machine (EVM). >>>> I'm sharing some figures I wrote for my self-study. >>>> >>>> Ethereum EVM illustrated >>>> http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf >>>> https://github.com/takenobu-hs/ethereum-evm-illustrated >>>> >>>> Haskell fits very well to DApps/Smart contracts :) >>>> >>>> Regards, >>>> Takenobu >>>> >>>> >>>> 2018-01-27 11:27 GMT+09:00 Takenobu Tani : >>>> >>>>> Hi Gregory, >>>>> >>>>> Thank you for much information. >>>>> I have heard Cardano, but I did not know the details. >>>>> >>>>> It's amazing! >>>>> >>>>> Although Ethereum VM is stack based virtual machine, >>>>> Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! >>>>> In addition, it is protected by semantics. >>>>> >>>>> Umm, High-level safety abstructed language (Haskell based) + register >>>>> based VM (IELE) ! >>>>> It's amazing. >>>>> >>>>> Thank you for telling me details. >>>>> I will explore this. >>>>> >>>>> Thank you very much, >>>>> Takenobu >>>>> >>>>> >>>>> 2018-01-27 10:22 GMT+09:00 Gregory Popovitch : >>>>> >>>>>> Probably you are aware of Cardano (https://www.cardanohub.org/en >>>>>> /home/), a new generation blockchain platform which uses languages >>>>>> inspired from Haskell. From the whitepaper at https://whycardano.com/ >>>>>> : >>>>>> >>>>>> "Systems such as Bitcoin provide an extremely inflexible and >>>>>> draconian scripting language that is difficult to program bespoke >>>>>> transactions in, and to read and understand. Yet the general >>>>>> programmability of languages such as Solidity introduce an extraordinary >>>>>> amount of complexity into the system and are useful to only a much smaller >>>>>> set of actors. >>>>>> >>>>>> Therefore, we have chosen to design a new language called Simon6 >>>>>> in honor of its creator Simon >>>>>> Thompson and the creator of the concepts that inspired it, Simon Peyton >>>>>> Jones. Simon is a domain-specific language that is based upon *Composing >>>>>> contracts: an adventure in financial engineering >>>>>> *. >>>>>> >>>>>> The principal idea is that financial transactions are generally >>>>>> composed from a collection of foundational elements7 >>>>>> . If one assembles a financial >>>>>> periodic table of elements, then one can provide support for an arbitrarily >>>>>> large set of compound transactions that will cover most, if not all, common >>>>>> transaction types without requiring general programmability. >>>>>> >>>>>> The primary advantage is that security and execution can be extremely >>>>>> well understood. Proofs can be written to show correctness of templates and >>>>>> exhaust the execution space of problematic transaction events, such as the >>>>>> creation of new money out of thin air >>>>>> or transaction >>>>>> malleability . >>>>>> Second, one can leave in extensions to add more elements by way of soft >>>>>> forks if new functionality is required. >>>>>> >>>>>> That said, there will always be a need to connect CSL to overlay >>>>>> protocols, legacy financial systems, and special purpose servers. Thus we >>>>>> have developed Plutus >>>>>> as both a >>>>>> general purpose smart contract language and also a special purpose DSL for >>>>>> interoperability. >>>>>> >>>>>> Plutus is a typed functional language based on concepts from Haskell, >>>>>> which can be used to write custom transaction scripts. For CSL, it will be >>>>>> used for complex transactions required to add support for other layers we >>>>>> need to connect, such as our sidechains scheme." >>>>>> >>>>>> ------------------------------ >>>>>> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On >>>>>> Behalf Of *Takenobu Tani >>>>>> *Sent:* Friday, January 26, 2018 8:05 PM >>>>>> *To:* Patrick Mylund Nielsen >>>>>> *Cc:* haskell-cafe >>>>>> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >>>>>> >>>>>> Hi Carter, Patrick, >>>>>> >>>>>> Thank you for reply. >>>>>> Quorum is interesting! >>>>>> It would be very nice to be able to describe Ethereum's contract with >>>>>> Haskell DSL. >>>>>> The characteristics about immutable and type will fit DApps. >>>>>> >>>>>> Thank you very much, >>>>>> Takenobu >>>>>> >>>>>> >>>>>> >>>>>> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen < >>>>>> haskell at patrickmn.com>: >>>>>> >>>>>>> The Quorum[1] team has been dreaming about such a >>>>>>> Haskell-beginner-friendly bytecode-generating DSL for a very long >>>>>>> time. >>>>>>> The user experience of writing applications in a language where >>>>>>> pitfalls >>>>>>> are so non-obvious is one of the biggest pain points of Ethereum in >>>>>>> general. >>>>>>> >>>>>>> We would warmly welcome something like this, and would definitely >>>>>>> look >>>>>>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>>>>>> >>>>>>> [1]: A permissioned/non-PoW version of Ethereum with high throughput >>>>>>> and >>>>>>> privacy - https://github.com/jpmorganchase/quorum/ >>>>>>> >>>>>>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>>>>>> > Hello Takenobu, >>>>>>> > while theres definitely a lot of haskell code out there that deals >>>>>>> with >>>>>>> > ethereum (or implementing it!), i'm not aware of anything >>>>>>> targeting the >>>>>>> > evm isa from haskell or any other mature functional programming >>>>>>> language >>>>>>> > >>>>>>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani < >>>>>>> takenobu.hs at gmail.com >>>>>>> > > wrote: >>>>>>> > >>>>>>> > Hi cafe, >>>>>>> > >>>>>>> > Does anyone know about the code generator from Haskell's >>>>>>> syntax to >>>>>>> > Ethereum VM language (bytecode)? >>>>>>> > That is, what corresponds to Solidity in Haskell. >>>>>>> > >>>>>>> > Although Solidity is interesting, it's difficult for me to >>>>>>> achieve >>>>>>> > quality and safety. >>>>>>> > Does such a project already exist? >>>>>>> > >>>>>>> > Regards, >>>>>>> > Takenobu >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > Haskell-Cafe mailing list >>>>>>> > To (un)subscribe, modify options or view 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. >>>> >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > Steven Leiva > 305.528.6038 <(305)%20528-6038> > leiva.steven at gmail.com > http://www.linkedin.com/in/stevenleiva > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffersoncarpenter2 at gmail.com Sun Mar 11 07:15:42 2018 From: jeffersoncarpenter2 at gmail.com (Jefferson Carpenter) Date: Sun, 11 Mar 2018 01:15:42 -0600 Subject: [Haskell-cafe] A small milestone In-Reply-To: References: Message-ID: <1c563694-4d27-4282-cd98-301a6cd6b33d@gmail.com> Happy birthday, SPJ! Jefferson On 1/18/2018 11:14 AM, Simon Peyton Jones via Haskell-Cafe wrote: > Cherished friends > Today is my sixtieth birthday. > It is just over forty years since Phil and I called in at Yale on my way to FPCA, and floated the idea of Haskell with Paul Hudak. (It wasn't called Haskell then, of course.) Rather a lot of water has flowed under the bridge since then. GHC's bug tracker is up to 14,683 tickets; I have read every one of them. > But the best thing is Haskell's rich community of smart, motivated, passionate, and friendly colleagues. There was a time when I knew every Haskell programmer on the planet, but we are far, far beyond that point. Now it's beyond me even to keep up with the huge wave of elegant and creative ideas, tools, libraries, and blog posts that you generate. (Kudos to Taylor - and doubtless other colleagues -- for the Haskell Weekly News, which I love.) But despite its size, it's a community that is still characterised by a love of elegance, and a desire to distil the essence of an idea and encapsulate it in an abstraction, all tempered with respect and tolerance. We don't always live up to these ideals, but by and large we do. > Thank you all. Onward and upward! > Simon > PS: as birthday recreation I'm working on https://ghc.haskell.org/trac/ghc/wiki/QuantifiedContexts > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 mszamot at gmail.com Sun Mar 11 12:44:47 2018 From: mszamot at gmail.com (Marcin Szamotulski) Date: Sun, 11 Mar 2018 13:44:47 +0100 Subject: [Haskell-cafe] vim syntax file Message-ID: <20180311124447.GA19402@flying-circus> Hello, I am looking for the maintainer of the haskell vim syntax script. The header points to the haskell-cafe mailing lists. I added @Spell and @NoSpell groups so it's easier to spell check haskell in vim. I hope others will find it useful :) Best regards, Marcin Szamotulski -------------- next part -------------- " Vim syntax file " Language: Haskell " Maintainer: Haskell Cafe mailinglist " Last Change: 2017 Dec 16 " Original Author: John Williams " " Thanks to Ryan Crumley for suggestions and John Meacham for " pointing out bugs. Also thanks to Ian Lynagh and Donald Bruce Stewart " for providing the inspiration for the inclusion of the handling " of C preprocessor directives, and for pointing out a bug in the " end-of-line comment handling. " " Options-assign a value to these variables to turn the option on: " " hs_highlight_delimiters - Highlight delimiter characters--users " with a light-colored background will " probably want to turn this on. " hs_highlight_boolean - Treat True and False as keywords. " hs_highlight_types - Treat names of primitive types as keywords. " hs_highlight_more_types - Treat names of other common types as keywords. " hs_highlight_debug - Highlight names of debugging functions. " hs_allow_hash_operator - Don't highlight seemingly incorrect C " preprocessor directives but assume them to be " operators " " 2004 Feb 19: Added C preprocessor directive handling, corrected eol comments " cleaned away literate haskell support (should be entirely in " lhaskell.vim) " 2004 Feb 20: Cleaned up C preprocessor directive handling, fixed single \ " in eol comment character class " 2004 Feb 23: Made the leading comments somewhat clearer where it comes " to attribution of work. " 2008 Dec 15: Added comments as contained element in import statements " quit when a syntax file was already loaded if exists("b:current_syntax") finish endif " (Qualified) identifiers (no default highlighting) syn match ConId "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=\<[A-Z][a-zA-Z0-9_']*\>" contains=@NoSpell syn match VarId "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=\<[a-z][a-zA-Z0-9_']*\>" contains=@NoSpell " Infix operators--most punctuation characters and any (qualified) identifier " enclosed in `backquotes`. An operator starting with : is a constructor, " others are variables (e.g. functions). syn match hsVarSym "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[-!#$%&\*\+/<=>\?@\\^|~.][-!#$%&\*\+/<=>\?@\\^|~:.]*" syn match hsConSym "\(\<[A-Z][a-zA-Z0-9_']*\.\)\=:[-!#$%&\*\+./<=>\?@\\^|~:]*" syn match hsVarSym "`\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[a-z][a-zA-Z0-9_']*`" syn match hsConSym "`\(\<[A-Z][a-zA-Z0-9_']*\.\)\=[A-Z][a-zA-Z0-9_']*`" " Reserved symbols--cannot be overloaded. syn match hsDelimiter "(\|)\|\[\|\]\|,\|;\|_\|{\|}" " Strings and constants syn match hsSpecialChar contained "\\\([0-9]\+\|o[0-7]\+\|x[0-9a-fA-F]\+\|[\"\\'&\\abfnrtv]\|^[A-Z^_\[\\\]]\)" syn match hsSpecialChar contained "\\\(NUL\|SOH\|STX\|ETX\|EOT\|ENQ\|ACK\|BEL\|BS\|HT\|LF\|VT\|FF\|CR\|SO\|SI\|DLE\|DC1\|DC2\|DC3\|DC4\|NAK\|SYN\|ETB\|CAN\|EM\|SUB\|ESC\|FS\|GS\|RS\|US\|SP\|DEL\)" syn match hsSpecialCharError contained "\\&\|'''\+" syn region hsString start=+"+ skip=+\\\\\|\\"+ end=+"+ contains=hsSpecialChar, at NoSpell syn match hsCharacter "[^a-zA-Z0-9_']'\([^\\]\|\\[^']\+\|\\'\)'"lc=1 contains=hsSpecialChar,hsSpecialCharError syn match hsCharacter "^'\([^\\]\|\\[^']\+\|\\'\)'" contains=hsSpecialChar,hsSpecialCharError syn match hsNumber "\v<[0-9]%(_*[0-9])*>|<0[xX]_*[0-9a-fA-F]%(_*[0-9a-fA-F])*>|<0[oO]_*%(_*[0-7])*>|<0[bB]_*[01]%(_*[01])*>" syn match hsFloat "\v<[0-9]%(_*[0-9])*\.[0-9]%(_*[0-9])*%(_*[eE][-+]?[0-9]%(_*[0-9])*)?>|<[0-9]%(_*[0-9])*_*[eE][-+]?[0-9]%(_*[0-9])*>|<0[xX]_*[0-9a-fA-F]%(_*[0-9a-fA-F])*\.[0-9a-fA-F]%(_*[0-9a-fA-F])*%(_*[pP][-+]?[0-9]%(_*[0-9])*)?>|<0[xX]_*[0-9a-fA-F]%(_*[0-9a-fA-F])*_*[pP][-+]?[0-9]%(_*[0-9])*>" " Keyword definitions. These must be patterns instead of keywords " because otherwise they would match as keywords at the start of a " "literate" comment (see lhs.vim). syn match hsModule "\" syn match hsImport "\.*"he=s+6 contains=hsImportMod,hsLineComment,hsBlockComment, at NoSpell syn match hsImportMod contained "\<\(as\|qualified\|hiding\)\>" contains=@NoSpell syn match hsInfix "\<\(infix\|infixl\|infixr\)\>" syn match hsStructure "\<\(class\|data\|deriving\|instance\|default\|where\)\>" syn match hsTypedef "\<\(type\|newtype\)\>" syn match hsStatement "\<\(do\|case\|of\|let\|in\)\>" syn match hsConditional "\<\(if\|then\|else\)\>" " Not real keywords, but close. if exists("hs_highlight_boolean") " Boolean constants from the standard prelude. syn match hsBoolean "\<\(True\|False\)\>" endif if exists("hs_highlight_types") " Primitive types from the standard prelude and libraries. syn match hsType "\<\(Int\|Integer\|Char\|Bool\|Float\|Double\|IO\|Void\|Addr\|Array\|String\)\>" endif if exists("hs_highlight_more_types") " Types from the standard prelude libraries. syn match hsType "\<\(Maybe\|Either\|Ratio\|Complex\|Ordering\|IOError\|IOResult\|ExitCode\)\>" syn match hsMaybe "\" syn match hsExitCode "\<\(ExitSuccess\)\>" syn match hsOrdering "\<\(GT\|LT\|EQ\)\>" endif if exists("hs_highlight_debug") " Debugging functions from the standard prelude. syn match hsDebug "\<\(undefined\|error\|trace\)\>" endif " Comments syn match hsLineComment "---*\([^-!#$%&\*\+./<=>\?@\\^|~].*\)\?$" contains=@Spell syn region hsBlockComment start="{-" end="-}" contains=hsBlockComment, at Spell syn region hsPragma start="{-#" end="#-}" " C Preprocessor directives. Shamelessly ripped from c.vim and trimmed " First, see whether to flag directive-like lines or not if (!exists("hs_allow_hash_operator")) syn match cError display "^\s*\(%:\|#\).*$" endif " Accept %: for # (C99) syn region cPreCondit start="^\s*\(%:\|#\)\s*\(if\|ifdef\|ifndef\|elif\)\>" skip="\\$" end="$" end="//"me=s-1 contains=cComment,cCppString,cCommentError syn match cPreCondit display "^\s*\(%:\|#\)\s*\(else\|endif\)\>" syn region cCppOut start="^\s*\(%:\|#\)\s*if\s\+0\+\>" end=".\@=\|$" contains=cCppOut2 syn region cCppOut2 contained start="0" end="^\s*\(%:\|#\)\s*\(endif\>\|else\>\|elif\>\)" contains=cCppSkip syn region cCppSkip contained start="^\s*\(%:\|#\)\s*\(if\>\|ifdef\>\|ifndef\>\)" skip="\\$" end="^\s*\(%:\|#\)\s*endif\>" contains=cCppSkip syn region cIncluded display contained start=+"+ skip=+\\\\\|\\"+ end=+"+ syn match cIncluded display contained "<[^>]*>" syn match cInclude display "^\s*\(%:\|#\)\s*include\>\s*["<]" contains=cIncluded syn cluster cPreProcGroup contains=cPreCondit,cIncluded,cInclude,cDefine,cCppOut,cCppOut2,cCppSkip,cCommentStartError syn region cDefine matchgroup=cPreCondit start="^\s*\(%:\|#\)\s*\(define\|undef\)\>" skip="\\$" end="$" syn region cPreProc matchgroup=cPreCondit start="^\s*\(%:\|#\)\s*\(pragma\>\|line\>\|warning\>\|warn\>\|error\>\)" skip="\\$" end="$" keepend syn region cComment matchgroup=cCommentStart start="/\*" end="\*/" contains=cCommentStartError,cSpaceError contained syntax match cCommentError display "\*/" contained syntax match cCommentStartError display "/\*"me=e-1 contained syn region cCppString start=+L\="+ skip=+\\\\\|\\"\|\\$+ excludenl end=+"+ end='$' contains=cSpecial contained " Define the default highlighting. " Only when an item doesn't have highlighting yet hi def link hsModule hsStructure hi def link hsImport Include hi def link hsImportMod hsImport hi def link hsInfix PreProc hi def link hsStructure Structure hi def link hsStatement Statement hi def link hsConditional Conditional hi def link hsSpecialChar SpecialChar hi def link hsTypedef Typedef hi def link hsVarSym hsOperator hi def link hsConSym hsOperator hi def link hsOperator Operator if exists("hs_highlight_delimiters") " Some people find this highlighting distracting. hi def link hsDelimiter Delimiter endif hi def link hsSpecialCharError Error hi def link hsString String hi def link hsCharacter Character hi def link hsNumber Number hi def link hsFloat Float hi def link hsConditional Conditional hi def link hsLiterateComment hsComment hi def link hsBlockComment hsComment hi def link hsLineComment hsComment hi def link hsComment Comment hi def link hsPragma SpecialComment hi def link hsBoolean Boolean hi def link hsType Type hi def link hsMaybe hsEnumConst hi def link hsOrdering hsEnumConst hi def link hsEnumConst Constant hi def link hsDebug Debug hi def link cCppString hsString hi def link cCommentStart hsComment hi def link cCommentError hsError hi def link cCommentStartError hsError hi def link cInclude Include hi def link cPreProc PreProc hi def link cDefine Macro hi def link cIncluded hsString hi def link cError Error hi def link cPreCondit PreCondit hi def link cComment Comment hi def link cCppSkip cCppOut hi def link cCppOut2 cCppOut hi def link cCppOut Comment let b:current_syntax = "haskell" " Options for vi: ts=8 sw=2 sts=2 nowrap noexpandtab ft=vim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: Digital signature URL: From takenobu.hs at gmail.com Sun Mar 11 13:39:32 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sun, 11 Mar 2018 22:39:32 +0900 Subject: [Haskell-cafe] vim syntax file In-Reply-To: <20180311124447.GA19402@flying-circus> References: <20180311124447.GA19402@flying-circus> Message-ID: Hi Marcin, Is this usefull for you? https://mail.haskell.org/pipermail/haskell-cafe/2017-December/128309.html Regards, Takenobu 2018-03-11 21:44 GMT+09:00 Marcin Szamotulski : > Hello, > > I am looking for the maintainer of the haskell vim syntax script. The > header points to the haskell-cafe mailing lists. > > I added @Spell and @NoSpell groups so it's easier to spell check haskell > in vim. I hope others will find it useful :) > > Best regards, > Marcin Szamotulski > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Graham.Hutton at nottingham.ac.uk Mon Mar 12 10:43:00 2018 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 12 Mar 2018 10:43:00 +0000 Subject: [Haskell-cafe] Midlands Graduate School 2018 - final call for participation Message-ID: <2242ECA4-21E6-4563-9A0F-B6030F020110@exmail.nottingham.ac.uk> Dear all, There are just a few days left now to register for this years Midlands Graduate School (MGS) in Nottingham: eight fantastic courses on dependently typed programming, categories, lambda calculus, semantics, and more. Registration closes on Friday 16th March. Please share! http://tinyurl.com/MGS18NOTT Best wishes, Graham Hutton and Henrik Nilsson ========================================================== Midlands Graduate School 2018 9-13 April 2018, Nottingham, UK http://tinyurl.com/MGS18NOTT BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Eight courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Invited course - Type-Driven Development with Idris, Edwin Brady Introductory courses - Lambda Calculus, Venanzio Capretta - Category Theory, Roy Crole - Domain Theory and Denotational Semantics, Achim Jung Advanced courses - Univalent Foundations, Benedikt Ahrens - Coalgebra, Alexander Kurz - Separation Logic, Georg Struth - Machine Learning, Michel Valstar REGISTRATION: Registration is £550 for student, academic and independent participants, and £850 for industry participants. The fee includes 5 nights single en-suite accommodation (Sun-Thu), lunch and coffee breaks, and the conference dinner. The registration deadline is ** Friday 16th March **. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver, gold and platinum), each with specific benefits. Please see the website for further details. ========================================================== 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 Graham.Hutton at nottingham.ac.uk Mon Mar 12 10:43:17 2018 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 12 Mar 2018 10:43:17 +0000 Subject: [Haskell-cafe] Midlands Graduate School 2018 - final call for participation Message-ID: <91B58943-CADE-4A7D-9674-A1C30EE8FFC1@exmail.nottingham.ac.uk> Dear all, There are just a few days left now to register for this years Midlands Graduate School (MGS) in Nottingham: eight fantastic courses on dependently typed programming, categories, lambda calculus, semantics, and more. Registration closes on Friday 16th March. Please share! http://tinyurl.com/MGS18NOTT Best wishes, Graham Hutton and Henrik Nilsson ========================================================== Midlands Graduate School 2018 9-13 April 2018, Nottingham, UK http://tinyurl.com/MGS18NOTT BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Eight courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Invited course - Type-Driven Development with Idris, Edwin Brady Introductory courses - Lambda Calculus, Venanzio Capretta - Category Theory, Roy Crole - Domain Theory and Denotational Semantics, Achim Jung Advanced courses - Univalent Foundations, Benedikt Ahrens - Coalgebra, Alexander Kurz - Separation Logic, Georg Struth - Machine Learning, Michel Valstar REGISTRATION: Registration is £550 for student, academic and independent participants, and £850 for industry participants. The fee includes 5 nights single en-suite accommodation (Sun-Thu), lunch and coffee breaks, and the conference dinner. The registration deadline is ** Friday 16th March **. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver, gold and platinum), each with specific benefits. Please see the website for further details. ========================================================== 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 clintonmead at gmail.com Mon Mar 12 23:06:47 2018 From: clintonmead at gmail.com (Clinton Mead) Date: Tue, 13 Mar 2018 10:06:47 +1100 Subject: [Haskell-cafe] Serialising data between Haskell and C# Message-ID: Hi All I want to integrate Haskell into an existing C# project, initially by creating one C# class that basically does all it's "work" in Haskell (and just provides a C# interface). There will be a few types passed in and out of this Haskell module from/to C#. On the C# side, there are classes with members, who's types are probably going to be either Strings, Ints, or lists of Strings/Ints, or lists of other objects. I'd like to have the same types on the Haskell side. It would be nice if I could just magically pass one of these C# types to Haskell and on the Haskell side it will appear as a Haskell type I assume what I'll have to do is serialise the type on the C# side and deserialise on the Haskell side. C# allows one to serialise any data type to XML. Haskell has plenty of serialisation libraries as well. However, the problem I presume is that if I just serialise to XML on the C# side, and deserialise from XML on the Haskell side, if my types are just slightly different, or even if the exact serialisers/deserialises represent their data in different ways, it isn't going to work. It seems like passing complex data to/from Haskell may be a common problem other people experience, so I'm looking for any suggestions on a clean way of doing this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffersoncarpenter2 at gmail.com Mon Mar 12 23:12:35 2018 From: jeffersoncarpenter2 at gmail.com (Jefferson Carpenter) Date: Mon, 12 Mar 2018 18:12:35 -0500 Subject: [Haskell-cafe] Serialising data between Haskell and C# In-Reply-To: References: Message-ID: <266e6e33-1448-6e92-e971-4b98e895839e@gmail.com> I know this isn't Haskell OR C#, but XSLT comes to mind. That might be a cleaner alternative than affecting either the way Haskell or C# serializes or deserializes. On 3/12/2018 6:06 PM, Clinton Mead wrote: > Hi All > > I want to integrate Haskell into an existing C# project, initially by > creating one C# class that basically does all it's "work" in Haskell (and > just provides a C# interface). > > There will be a few types passed in and out of this Haskell module from/to > C#. On the C# side, there are classes with members, who's types are > probably going to be either Strings, Ints, or lists of Strings/Ints, or > lists of other objects. > > I'd like to have the same types on the Haskell side. > > It would be nice if I could just magically pass one of these C# types to > Haskell and on the Haskell side it will appear as a Haskell type > > I assume what I'll have to do is serialise the type on the C# side and > deserialise on the Haskell side. > > C# allows one to serialise any data type to XML. Haskell has plenty of > serialisation libraries as well. > > However, the problem I presume is that if I just serialise to XML on the C# > side, and deserialise from XML on the Haskell side, if my types are just > slightly different, or even if the exact serialisers/deserialises represent > their data in different ways, it isn't going to work. > > It seems like passing complex data to/from Haskell may be a common problem > other people experience, so I'm looking for any suggestions on a clean way > of doing this. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From neil_mayhew at users.sourceforge.net Mon Mar 12 23:19:25 2018 From: neil_mayhew at users.sourceforge.net (Neil Mayhew) Date: Mon, 12 Mar 2018 17:19:25 -0600 Subject: [Haskell-cafe] Serialising data between Haskell and C# In-Reply-To: References: Message-ID: Haskell has good capabilities for accessing "foreign" data structures (without serialization), and so does C#. A good common denominator is probably COM, because C# can treat COM objects almost like native objects. I see there's a package for the Haskell side. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Mon Mar 12 23:21:31 2018 From: chpatrick at gmail.com (Patrick Chilton) Date: Tue, 13 Mar 2018 00:21:31 +0100 Subject: [Haskell-cafe] Serialising data between Haskell and C# In-Reply-To: References: Message-ID: You could use protocol buffers: https://developers.google.com/protocol-buffers/docs/csharptutorial You would specify the data types you need in an independent language, then use a code generator to get C# classes and Haskell records, and serializers for free. On the Haskell side you can use https://hackage.haskell.org/package/proto-lens. Then you can send the serialized objects over FFI or the network as needed. On Tue, Mar 13, 2018 at 12:06 AM, Clinton Mead wrote: > Hi All > > I want to integrate Haskell into an existing C# project, initially by > creating one C# class that basically does all it's "work" in Haskell (and > just provides a C# interface). > > There will be a few types passed in and out of this Haskell module from/to > C#. On the C# side, there are classes with members, who's types are > probably going to be either Strings, Ints, or lists of Strings/Ints, or > lists of other objects. > > I'd like to have the same types on the Haskell side. > > It would be nice if I could just magically pass one of these C# types to > Haskell and on the Haskell side it will appear as a Haskell type > > I assume what I'll have to do is serialise the type on the C# side and > deserialise on the Haskell side. > > C# allows one to serialise any data type to XML. Haskell has plenty of > serialisation libraries as well. > > However, the problem I presume is that if I just serialise to XML on the > C# side, and deserialise from XML on the Haskell side, if my types are just > slightly different, or even if the exact serialisers/deserialises represent > their data in different ways, it isn't going to work. > > It seems like passing complex data to/from Haskell may be a common problem > other people experience, so I'm looking for any suggestions on a clean way > of doing this. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwotton at gmail.com Mon Mar 12 23:38:19 2018 From: mwotton at gmail.com (Mark Wotton) Date: Mon, 12 Mar 2018 19:38:19 -0400 Subject: [Haskell-cafe] Serialising data between Haskell and C# In-Reply-To: References: Message-ID: I haven't used it, but https://github.com/tim-m89/Salsa could be interesting. (found via https://wiki.haskell.org/Common_Language_Runtime) cheers mark On Mon, Mar 12, 2018 at 7:06 PM, Clinton Mead wrote: > Hi All > > I want to integrate Haskell into an existing C# project, initially by > creating one C# class that basically does all it's "work" in Haskell (and > just provides a C# interface). > > There will be a few types passed in and out of this Haskell module from/to > C#. On the C# side, there are classes with members, who's types are probably > going to be either Strings, Ints, or lists of Strings/Ints, or lists of > other objects. > > I'd like to have the same types on the Haskell side. > > It would be nice if I could just magically pass one of these C# types to > Haskell and on the Haskell side it will appear as a Haskell type > > I assume what I'll have to do is serialise the type on the C# side and > deserialise on the Haskell side. > > C# allows one to serialise any data type to XML. Haskell has plenty of > serialisation libraries as well. > > However, the problem I presume is that if I just serialise to XML on the C# > side, and deserialise from XML on the Haskell side, if my types are just > slightly different, or even if the exact serialisers/deserialises represent > their data in different ways, it isn't going to work. > > It seems like passing complex data to/from Haskell may be a common problem > other people experience, so I'm looking for any suggestions on a clean way > of doing this. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda From codygman.consulting at gmail.com Tue Mar 13 06:44:25 2018 From: codygman.consulting at gmail.com (Cody Goodman) Date: Tue, 13 Mar 2018 01:44:25 -0500 Subject: [Haskell-cafe] Append after index and update items after inserted item with lens Message-ID: Hello, I'm trying to insert a new elemnt into a list after a given index and increment the orderId accordingly with the lens library. I'm a bit confused at why this code isn't working: ``` import Control.Lens data A = A { _customOrderId :: Int } deriving Show things = [ A {_customOrderId = 0} , A {_customOrderId = 1} , A {_customOrderId = 2} , A {_customOrderId = 3} ] main = print $ things & ( (_drop 2 %~ ((A 22)<|)) . ((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1)) ) ``` The first portion works to insert where desired, but the second portion `((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1))` only increments the order id in indices 4. Any idea why this is happening? Thanks, Cody Goodman -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Tue Mar 13 07:48:41 2018 From: publicityifl at gmail.com (Jurriaan Hage) Date: Tue, 13 Mar 2018 00:48:41 -0700 Subject: [Haskell-cafe] 1st CfP: IFL 2018 (30th Symposium on Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the first call for papers for IFL 2018. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- ================================================================================ IFL 2018 30th Symposium on Implementation and Application of Functional Languages University of Massachusetts Lowell, MA, USA September 5th-7th, 2018 http://iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2018 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Submissions and peer-review Differently from previous editions of IFL, IFL 2018 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2018. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: May 25, 2018 Submission of draft papers: July 17, 2018 Regular and draft papers notification: July 20, 2018 Deadline for early registration: August 8, 2018 Submission of pre-proceedings version: August 29, 2018 IFL Symposium: September 5-7, 2018 Submission of papers for post-proceedings: November 7, 2018 Notification of acceptance: December 22, 2018 Camera-ready version: February 10, 2019 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2018 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jay McCarthy & Matteo Cimini, University of Massachusetts Lowell, USA Program Committee: * Arthur Chargu√©raud, Inria, FR * Ben Delaware, Purdue University, USA * Christos Dimoulas, Northwestern University, USA * David Darais, University of Vermont, USA * Dominic Orchard, University of Kent, UK * Ekaterina Komendantskaya, Heriot-Watt University, UK * Garrett Morris, University of Kansas, USA * Heather Miller, EPFL & Northeastern University, CH & USA * Jeremy Yallop, University of Cambridge, UK * Keiko Nakata, SAP Innovation Center Potsdam, DE * Laura Castro, University of A Coru√±a, ESP * Magnus Myreen, Chalmers University of Technology, SWE * Natalia Chechina, Bournemouth University, UK * Peter Achten, Radboud Universiteit Nijmegen, NL * Peter-Michael Osera, Grinnell College, USA * Richard Eisenberg, Bryn Mawr College, USA * Trevor McDonell, University of New South Wales, AUS * Yukiyoshi Kameyama, University of Tsukuba, JAP ### Venue The 30th IFL will take place at the UMass Lowell Inn & Conference Center in Lowell (MA), in association with the University of Massachusetts Lowell. The City of Lowell is located at the heart of the Merrimack Valley just 30 miles northwest of Boston. Lowell can be easily reached by train or taxi. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2018 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikivazou at gmail.com Tue Mar 13 10:13:35 2018 From: nikivazou at gmail.com (Niki Vazou) Date: Tue, 13 Mar 2018 11:13:35 +0100 Subject: [Haskell-cafe] Call for Contributions: Type-Driven Development 2018 Message-ID: Hello, The first call for contributions for TyDe is out. Forward it to anyone who might be interested. Best, Niki Vazou ============================================== CALL FOR CONTRIBUTIONS Type 2018: Type-Driven Development https://icfp18.sigplan.org/track/tyde-2018 23-29 Sep, 2018, St. Louis, Missouri (co-located with ICFP) ============================================== *Call for Contributions* We welcome all contributions, both theoretical and practical, on a range of topics including: dependently typed programming; generic programming; design and implementation of programming languages, exploiting types in novel ways; exploiting typed data, data dependent data, or type providers; static and dynamic analyses of typed programs; tools, IDEs, or testing tools exploiting type information; pearls, being elegant, instructive examples of types used in the derivation, calculation, or construction of programs. *Important Dates* Regular paper deadline: Wednesday, June 6, 2018 Extended abstract deadline: Wednesday, June 13, 2018 Author notification: Friday, June 29, 2018 Deadline for camera ready version: August 5, 2018 Workshop: Thursday, September 27, 2018 *Program Committee* - Guillaume Allais, Radboud University Nijmegen, Netherlands - Zena M. Ariola, University of Oregon, USA - David Darais, University of Vermont, USA - Richard Eisenberg, Bryn Mawr College, USA (co-chair) - Jennifer Hackett, University of Nottingham, UK - Shin-ya Katsumata, National Institute of Informatics, Japan - Daan Leijen, Microsoft Research, USA - Shin-Cheng Mu, Academia Sinica, Taiwan - Dominic Orchard, University of Kent, UK - Peter-Michael Osera, Grinnell College, USA - Zoe Paraskevopoulou, Princeton University, USA - Alberto Pardo, Universidad de la Republica, Uruguay - Matthieu Sozeau, University of Paris Diderot, Paris 7, France - Niki Vazou, University of Maryland, USA (co-chair) *Submission details* Submissions should fall into one of two categories: - Regular research papers (12 pages) - Extended abstracts (2 pages) The bibliography will not be counted against the page limits for either category. Regular research papers are expected to present novel and interesting research results, and will be included in the formal proceedings. Extended abstracts should report work in progress that the authors would like to present at the workshop. Extended abstracts will be distributed to workshop attendees but will not be published in the formal proceedings. We welcome submissions from PC members (with the exception of the two co-chairs), but these submissions will be held to a higher standard. Submission is handled through HotCRP: https://tyde18.hotcrp.com/ All submissions should be in portable document format (PDF) and formatted using the ACM SIGPLAN style guidelines: http://www.sigplan.org/Resources/Author/ Note that the ACM SIGPLAN style guidelines have changed from previous years! In particular, submissions should use the new ‘acmart’ format and the two-column ‘sigplan’ subformat (not to be confused with the one-column ‘acmlarge’ subformat!). Extended abstracts must be submitted with the label ‘Extended abstract’ clearly in the title. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Tue Mar 13 10:48:09 2018 From: lysxia at gmail.com (Li-yao Xia) Date: Tue, 13 Mar 2018 06:48:09 -0400 Subject: [Haskell-cafe] Append after index and update items after inserted item with lens In-Reply-To: References: Message-ID: The only item of index satisfying (> 2) in the list things is (A 3). Li-yao On 03/13/2018 02:44 AM, Cody Goodman wrote: > Hello, > > I'm trying to insert a new elemnt into a list after a given index and > increment the orderId accordingly with the lens library. > > I'm a bit confused at why this code isn't working: > > ``` > import Control.Lens > > data A = A { _customOrderId :: Int } deriving Show > > things = [ A {_customOrderId = 0} >          , A {_customOrderId = 1} >          , A {_customOrderId = 2} >          , A {_customOrderId = 3} >          ] > > main = print $ things & ( (_drop 2 %~ ((A 22)<|)) . ((traversed . > indices (> 2) . customerOrderIdLens) %~ (+ 1))  ) > ``` > The first portion works to insert where desired, but the second portion > `((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1))` only > increments the order id in indices 4. > > Any idea why this is happening? > > Thanks, > > Cody Goodman > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From codygman.consulting at gmail.com Tue Mar 13 13:56:10 2018 From: codygman.consulting at gmail.com (Cody Goodman) Date: Tue, 13 Mar 2018 08:56:10 -0500 Subject: [Haskell-cafe] Append after index and update items after inserted item with lens In-Reply-To: References: Message-ID: Hi Li-Yao, I made a mistake with my example. In my real world problem there are many elements after which need updated. On Mar 13, 2018 5:50 AM, "Li-yao Xia" wrote: > The only item of index satisfying (> 2) in the list things is (A 3). > > Li-yao > > > On 03/13/2018 02:44 AM, Cody Goodman wrote: > >> Hello, >> >> I'm trying to insert a new elemnt into a list after a given index and >> increment the orderId accordingly with the lens library. >> >> I'm a bit confused at why this code isn't working: >> >> ``` >> import Control.Lens >> >> data A = A { _customOrderId :: Int } deriving Show >> >> things = [ A {_customOrderId = 0} >> , A {_customOrderId = 1} >> , A {_customOrderId = 2} >> , A {_customOrderId = 3} >> ] >> >> main = print $ things & ( (_drop 2 %~ ((A 22)<|)) . ((traversed . indices >> (> 2) . customerOrderIdLens) %~ (+ 1)) ) >> ``` >> The first portion works to insert where desired, but the second portion >> `((traversed . indices (> 2) . customerOrderIdLens) %~ (+ 1))` only >> increments the order id in indices 4. >> >> Any idea why this is happening? >> >> Thanks, >> >> Cody Goodman >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 juhpetersen at gmail.com Wed Mar 14 09:51:48 2018 From: juhpetersen at gmail.com (Jens Petersen) Date: Wed, 14 Mar 2018 18:51:48 +0900 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.4.1 released In-Reply-To: <87h8pq33p8.fsf@smart-cactus.org> References: <87h8pq33p8.fsf@smart-cactus.org> Message-ID: On 9 March 2018 at 01:57, Ben Gamari wrote: > The GHC developers are very happy to announce the 8.4.1 release of > Glasgow Haskell Compiler. Thanks! I have built it for Fedora and EPEL7 in a copr repo: https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.4.1/ Cheers, Jens From dave.laing.80 at gmail.com Thu Mar 15 05:51:09 2018 From: dave.laing.80 at gmail.com (David Laing) Date: Thu, 15 Mar 2018 15:51:09 +1000 Subject: [Haskell-cafe] Using Backpack for initial and final encodings Message-ID: Hi everyone, Ed Kmett recently pointed me towards his usage of Backpack to write some code in the tagless final style, and I've been playing with it and riffing on it for a while. There's a solution to the expression problem in there involving classy Prisms (and now Backpacky Prisms) that seems pretty neat. I've written it up here: https://qfpl.io/posts/backpack-for-initial-and-final-encodings/ Hopefully some of you find it interesting. Cheers, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Thu Mar 15 13:23:02 2018 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Thu, 15 Mar 2018 06:23:02 -0700 Subject: [Haskell-cafe] Documenting Examples for a library Message-ID: Hello, I am close to releasing a new version of the https://hackage.haskell.org/package/pptable library I have been working on off late. I am a little confused on what approach I need to take regarding providing good documentation and working examples. Please, note that I am not referring to the API documentation attached to the code. For API documentation I will continue to use haddock and generate documentation as I build. The approaches I have in mind to provide clear examples are as follows: 1. Provide a README.md and document all usage examples in markdown format. Allow github to produce the HTML. 2. Create and ship an Example.hs file along with library. Using a .hs file allows haddock to build the documentation as part of the package. I took this approach for the previous release. Here is an example: https://hackage.haskell.org/package/pptable-0.2.0.0/docs/Text-PrettyPrint-Tabulate-Example.html. 3. Using Example.lhs. I like this approach since it lets me load the code in ghci and test out the examples seamlessly. But, I am hitting roadblocks with this, since I am not able to include this file as part of my stack project. `stack haddock` fails too. When I include .lhs file in a stack project, I get the following error File name does not match module name: Saw: ‘Main’ Expected: ‘Text.PrettyPrint.Tabulate.Example’ I like (3) because I can make sure my examples run successfully, (using stack ghci Example.lhs), before I publish them. With options (1) and (2), I need to manually copy/past code into ghci to make sure there are no errors. Is there a better way to do this? Please could the group provide any recommendations and guidance on what approach I should be taking and why. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From m at jaspervdj.be Thu Mar 15 23:51:09 2018 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Thu, 15 Mar 2018 19:51:09 -0400 Subject: [Haskell-cafe] [Google Summer of Code 2018] Student Applications are now open Message-ID: <20180315235109.GE16135@colony6.localdomain> Hey all, As we've previously announced through different channels, Haskell.org was accepted into Google Summer of Code 2018 [1]. Students application have now opened. Students can submit their proposal at the Summer of Code Dashboard [2]. We are also seeking mentors for possible projects. This year, we would like to assign a back-up mentor for each student. If you are interested in mentoring, please contact us [3] so we can add you to the mentor list directly. Having good mentors is an important factor in making the students feel welcome and guiding them to a succesful completion of their projects. If you would like to apply but you don't know how to start your proposal, have a look at our ideas list [4] and this great guide [5]. Lastly, we recognize that inclusion is an important part of our mission to promote Haskell. Therefore, we strongly encourage applications from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never taken part in similar programs before. Kind regards, Jasper Van der Jeugt & George Wilson on behalf of the Haskell.org Committee [1]: https://summerofcode.withgoogle.com/organizations/5706672807346176/ [2]: https://summerofcode.withgoogle.com/ [3]: https://summer.haskell.org/contact.html [4]: https://summer.haskell.org/ideas.html [5]: http://write.flossmanuals.net/gsocstudentguide/writing-a-proposal/ From ivan.miljenovic at gmail.com Fri Mar 16 02:04:12 2018 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 16 Mar 2018 13:04:12 +1100 Subject: [Haskell-cafe] Documenting Examples for a library In-Reply-To: References: Message-ID: On 16 March 2018 at 00:23, Guru Devanla wrote: > 3. Using Example.lhs. I like this approach since it lets me load the code in > ghci and test out the examples seamlessly. But, I am hitting roadblocks with > this, since I am not able to include this file as part of my stack project. > `stack haddock` fails too. One option is to have this as a separate executable but not marked as buildable by default; for example: https://github.com/ivan-m/testbench/blob/master/testbench.cabal#L39 (my .travis.yml enables the flag so I can be sure it still works). -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From gurudev.devanla at gmail.com Sat Mar 17 14:04:43 2018 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sat, 17 Mar 2018 07:04:43 -0700 Subject: [Haskell-cafe] Documenting Examples for a library In-Reply-To: References: Message-ID: Thanks Ivan. I did end up using the markdown-unlit library as suggested in this post: https://www.reddit.com/r/haskell/comments/84mirm/recommended_way_of_documenting_examples/?st=jevg0jg6&sh=bd7e6804 On Thu, Mar 15, 2018 at 7:04 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 16 March 2018 at 00:23, Guru Devanla wrote: > > 3. Using Example.lhs. I like this approach since it lets me load the > code in > > ghci and test out the examples seamlessly. But, I am hitting roadblocks > with > > this, since I am not able to include this file as part of my stack > project. > > `stack haddock` fails too. > > One option is to have this as a separate executable but not marked as > buildable by default; for example: > https://github.com/ivan-m/testbench/blob/master/testbench.cabal#L39 > (my .travis.yml enables the flag so I can be sure it still works). > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Sat Mar 17 14:12:09 2018 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Sat, 17 Mar 2018 07:12:09 -0700 Subject: [Haskell-cafe] [Announcement]: New release of ppTable: Pretty Print containers in a tabular format Message-ID: Hello Haskell-Cafe, I am happy to announce a new release of the ppTable library that lets you print records in list/vectors/maps in a pretty tabular format. https://hackage.haskell.org/package/pptable The new release also handles nested record structures by displaying the headers in a multi-hierarchical fashion. As they say in Python 'Flat is better than nested'. But for now, nested works too! I am willing and happy to get any feedback and suggestions on the library API and implementation itself. Thank you very much Guru -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Sun Mar 18 04:07:54 2018 From: icfp.publicity at googlemail.com (Lindsey Kuper) Date: Sat, 17 Mar 2018 21:07:54 -0700 Subject: [Haskell-cafe] Call for Tutorial Proposals: ICFP 2018 Message-ID: <5aade61ae9166_d12c3ffd2e057bf095741@landin.local.mail> CALL FOR TUTORIAL PROPOSALS ICFP 2018 23rd ACM SIGPLAN International Conference on Functional Programming September 23-29, 2018 St. Louis, Missouri, United States http://conf.researchr.org/home/icfp-2018 The 23rd ACM SIGPLAN International Conference on Functional Programming will be held in St. Louis, Missouri, United States on September 23-29, 2018. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". Tutorials may occur in parallel to both ICFP and its co-located workshops, from September 23 through September 29. Additionally, ICFP is co-located with Strange Loop this year, and this will be taken into account when scheduling tutorials. ---------------------------------------------------------------------- Submission details Deadline for submission: April 9, 2018 Notification of acceptance: April 16, 2018 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2018 workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com by April 9, 2018. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by April 16, 2018. The proposal form is available at: http://www.icfpconference.org/icfp2018-files/icfp18-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2018 organizing committee. Workshop Co-Chair: Christophe Scholliers (University of Ghent) Workshop Co-Chair: David Christiansen (Galois, Inc.) General Chair: Robby Findler (Northwestern University) Program Chair: Matthew Flatt (University of Utah) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Christophe Scholliers and David Christiansen), via email to icfp-workshops-2018 at googlegroups.com From ivanperezdominguez at gmail.com Sun Mar 18 05:39:40 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 18 Mar 2018 01:39:40 -0400 Subject: [Haskell-cafe] Vim + literal Haskell + dollar symbols Message-ID: Hi cafe, The lhaskell edit mode for lhs2tex documents in vim gets confused when a dollar is used in code. This also makes the spellchecker ignore text paragraphs (until a matching $ is found). Where should this be reported? This list is named as maintainer in the Ubuntu package vim-runtime's lhaskell.vim syntax file: " Maintainer: Haskell Cafe mailinglist " Original Author: Arthur van Leeuwen " Last Change: 2010 Apr 11 " Version: 1.04 Cheers Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mszamot at gmail.com Sun Mar 18 13:10:08 2018 From: mszamot at gmail.com (Marcin Szamotulski) Date: Sun, 18 Mar 2018 14:10:08 +0100 Subject: [Haskell-cafe] vim syntax file In-Reply-To: References: <20180311124447.GA19402@flying-circus> Message-ID: Hi Takenobu, Thanks for sharing this, I'll prepare a PR. Bram usually asks that patches for runtime files are send to him from the maintainer, is this an exception? Does anyone here on haskell-cafe, review the changes? Regards, Marcin On 11 March 2018 at 14:39, Takenobu Tani wrote: > Hi Marcin, > > Is this usefull for you? > > https://mail.haskell.org/pipermail/haskell-cafe/2017-December/128309.html > > Regards, > Takenobu > > > 2018-03-11 21:44 GMT+09:00 Marcin Szamotulski : > >> Hello, >> >> I am looking for the maintainer of the haskell vim syntax script. The >> header points to the haskell-cafe mailing lists. >> >> I added @Spell and @NoSpell groups so it's easier to spell check haskell >> in vim. I hope others will find it useful :) >> >> Best regards, >> Marcin Szamotulski >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 tjakway at nyu.edu Sun Mar 18 23:05:26 2018 From: tjakway at nyu.edu (Thomas Jakway) Date: Sun, 18 Mar 2018 16:05:26 -0700 Subject: [Haskell-cafe] Scala: Type synonyms for implicits? Message-ID: Posting this here since some of you are Scala programmers:https://stackoverflow.com/questions/49353695/type-synonyms-for-implicits A type-level question you won't encounter in Haskell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Sun Mar 18 23:53:33 2018 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 19 Mar 2018 09:53:33 +1000 Subject: [Haskell-cafe] Scala: Type synonyms for implicits? In-Reply-To: References: Message-ID: You'll find most of us threw Scala away quite some time ago. On 19 Mar. 2018 09:07, "Thomas Jakway" wrote: > > Posting this here since some of you are Scala programmers: > https://stackoverflow.com/questions/49353695/type-synonyms-for-implicits > > A type-level question you won't encounter in Haskell. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From parsonsmatt at gmail.com Sun Mar 18 23:56:46 2018 From: parsonsmatt at gmail.com (Matt) Date: Sun, 18 Mar 2018 17:56:46 -0600 Subject: [Haskell-cafe] Scala: Type synonyms for implicits? In-Reply-To: References: Message-ID: You might not encounter it, as ImplicitParams isn't common, but it has a nice answer. Note that `HasCallStack` is implemented as an implicit parameter: (?callstack :: CallStack). {-# LANGUAGE TypeOperators, LambdaCase, RankNTypes #-} import GHC.Stack type a ?-> b = HasCallStack => a -> b foo :: a ?-> a foo x = x map' :: (a ?-> b) -> [a] ?-> [b] map' f = \case [] -> [] (x:xs) -> f x : map f xs ohno :: Int ?-> String ohno 5 = error "Five is my least favorite number." ohno x = show x main = print $ map' ohno [1..10] This has the result: *Main> main ["1","2","3","4","*** Exception: Five is my least favorite number. CallStack (from HasCallStack): error, called at /home/matt/impl.hs:16:10 in main:Main ohno, called at /home/matt/impl.hs:19:21 in main:Main f, called at /home/matt/impl.hs:13:23 in main:Main map', called at /home/matt/impl.hs:19:16 in main:Main Matt Parsons On Sun, Mar 18, 2018 at 5:05 PM, Thomas Jakway wrote: > > Posting this here since some of you are Scala programmers: > https://stackoverflow.com/questions/49353695/type-synonyms-for-implicits > > A type-level question you won't encounter in Haskell. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.F.Berger at sussex.ac.uk Mon Mar 19 09:19:26 2018 From: M.F.Berger at sussex.ac.uk (Martin Berger) Date: Mon, 19 Mar 2018 09:19:26 +0000 Subject: [Haskell-cafe] S-REPLS 9: Call for talks Message-ID: <20180319091926.GA70932@m011319.inf.susx.ac.uk> ============================================================================ S-REPLS 9 (#srepls) South of England Regional Programming Language Seminar series Friday 25 May 2018, 10:00 - 19:00 University of Sussex, Brighton, Fulton building, Room A (FUL-A) http://users.sussex.ac.uk/~mfb21/srepls9 Call for talks ============================================================================ Overview S-REPLS is a regular, informal and friendly meeting for those based in the South of England with a professional interest - whether it be academic or commercial - in the semantics, implementation, and use of programming languages, and related areas. Attendance is free! Lunch and refreshments will be provided. Submitting a talk S-REPLS talks are typically 20-30 minutes long on any topic related to programming languages. We are currently requesting talk suggestions for S-REPLS 9 at the University of Sussex in Brighton. Submissions from industrial professionals and junior researchers (postdocs and students), as well as descriptions of work in progress, are especially welcome. Please email with the title "S-REPLS 9 talk suggestion", a draft title, and an abstract by 17:00 on April 25th 2018. From wolfgang-it at jeltsch.info Mon Mar 19 09:47:50 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Mon, 19 Mar 2018 11:47:50 +0200 Subject: [Haskell-cafe] Vim + literal Haskell + dollar symbols In-Reply-To: References: Message-ID: <1521452870.2379.6.camel@jeltsch.info> Hi, Ivan! Does this problem occur with code environments or only with spec environments? At least Vim 7.4 does not mention spec in syntax/lhaskell. vim. I have patched this file such that it does all the things with spec that it does with code, and it works just fine. The patch is as follows: > 78c78 > <     if search('\\documentclass\|\\begin{\(code}\)\@!\|\\\(sub\)*section\|\\chapter|\\part','W') != 0 > --- > >     if search('\\documentclass\|\\begin{\(code}\)\@!\|\\begin{\(spec}\)\@!\|\\\(sub\)*section\|\\chapter|\\part','W') != 0 > 110a111 > > syntax region lhsHaskellBeginEndBlock start="^\\begin{spec}\s*$" matchgroup=NONE end="\%(^\\end{spec}.*$\)\@=" contains=@haskellTop,beginCodeBegin containedin=@lhsTeXContainer All the best, Wolfgang Am Sonntag, den 18.03.2018, 01:39 -0400 schrieb Ivan Perez: > Hi cafe, > > The lhaskell edit mode for lhs2tex documents in vim gets confused when > a dollar is used in code. > > This also makes the spellchecker ignore text paragraphs (until a > matching $ is found). > > Where should this be reported? > > This list is named as maintainer in the Ubuntu package vim-runtime's > lhaskell.vim syntax file: > > " Maintainer:           Haskell Cafe mailinglist > .org> > " Original Author:      Arthur van Leeuwen > " Last Change:          2010 Apr 11 > " Version:              1.04 > > Cheers > > Ivan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Mon Mar 19 11:09:57 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Mon, 19 Mar 2018 07:09:57 -0400 Subject: [Haskell-cafe] Vim + literal Haskell + dollar symbols In-Reply-To: <1521452870.2379.6.camel@jeltsch.info> References: <1521452870.2379.6.camel@jeltsch.info> Message-ID: Hi Wolfgang, Thanks. That change does help, but it still gets confused. Screenshot: https://ibb.co/jD6mPc Could that change be made permanent though? Could it be added to vim's default lhaskell.vim? Cheers Ivan On 19 March 2018 at 05:47, Wolfgang Jeltsch wrote: > Hi, Ivan! > > Does this problem occur with code environments or only with spec > environments? At least Vim 7.4 does not mention spec in > syntax/lhaskell.vim. I have patched this file such that it does all the > things with spec that it does with code, and it works just fine. The > patch is as follows: > > 78c78 > > < if search('\\documentclass\|\\begin{\(code}\)\@!\|\\\(sub\)*section\|\\chapter|\\part','W') != 0 > > --- > > > if search('\\documentclass\|\\begin{\(code}\)\@!\|\\begin{\(spec}\)\@!\|\\\(sub\)*section\|\\chapter|\\part','W') != 0 > > 110a111 > > > syntax region lhsHaskellBeginEndBlock start="^\\begin{spec}\s*$" matchgroup=NONE end="\%(^\\end{spec}.*$\)\@=" contains=@haskellTop,beginCodeBegin containedin=@lhsTeXContainer > > > All the best, > Wolfgang > > Am Sonntag, den 18.03.2018, 01:39 -0400 schrieb Ivan Perez: > > Hi cafe, > > The lhaskell edit mode for lhs2tex documents in vim gets confused when a > dollar is used in code. > > This also makes the spellchecker ignore text paragraphs (until a matching > $ is found). > > Where should this be reported? > > This list is named as maintainer in the Ubuntu package vim-runtime's > lhaskell.vim syntax file: > > " Maintainer: Haskell Cafe mailinglist > > " Original Author: Arthur van Leeuwen > " Last Change: 2010 Apr 11 > " Version: 1.04 > > Cheers > > Ivan > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 takenobu.hs at gmail.com Mon Mar 19 12:41:57 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Mon, 19 Mar 2018 21:41:57 +0900 Subject: [Haskell-cafe] vim syntax file In-Reply-To: References: <20180311124447.GA19402@flying-circus> Message-ID: Hi Marcin, In my understanding, person other than the maintainer can also send patches. In the `Contributing to Vim` [1], it is mandatory only to contact the maintainer. I think the following procedure is appropriate: 1. Share the contents of the patch (file or URL) to haskell-cafe ML (maintainer). 2. Wait for several days (a week?) 3. It is considered good if there is no objection (no reaction). 4. Send pull-request to vim project on github. (Also add URL of cafe mail to PR) [1]: https://github.com/vim/vim/blob/master/CONTRIBUTING.md#syntax-indent-and-other-runtime-files Regards, Takenobu 2018-03-18 22:10 GMT+09:00 Marcin Szamotulski : > Hi Takenobu, > > Thanks for sharing this, I'll prepare a PR. > Bram usually asks that patches for runtime files are send to him from the > maintainer, is this an exception? > Does anyone here on haskell-cafe, review the changes? > > Regards, > Marcin > > On 11 March 2018 at 14:39, Takenobu Tani wrote: > >> Hi Marcin, >> >> Is this usefull for you? >> >> https://mail.haskell.org/pipermail/haskell-cafe/2017-December/128309.html >> >> Regards, >> Takenobu >> >> >> 2018-03-11 21:44 GMT+09:00 Marcin Szamotulski : >> >>> Hello, >>> >>> I am looking for the maintainer of the haskell vim syntax script. The >>> header points to the haskell-cafe mailing lists. >>> >>> I added @Spell and @NoSpell groups so it's easier to spell check haskell >>> in vim. I hope others will find it useful :) >>> >>> Best regards, >>> Marcin Szamotulski >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 mszamot at gmail.com Mon Mar 19 14:38:00 2018 From: mszamot at gmail.com (Marcin Szamotulski) Date: Mon, 19 Mar 2018 15:38:00 +0100 Subject: [Haskell-cafe] vim syntax file In-Reply-To: References: <20180311124447.GA19402@flying-circus> Message-ID: ok, thanks for the clarification. Regards, Marcin On 19 March 2018 at 13:41, Takenobu Tani wrote: > Hi Marcin, > > In my understanding, person other than the maintainer can also send > patches. > In the `Contributing to Vim` [1], it is mandatory only to contact the > maintainer. > > I think the following procedure is appropriate: > > 1. Share the contents of the patch (file or URL) to haskell-cafe ML > (maintainer). > 2. Wait for several days (a week?) > 3. It is considered good if there is no objection (no reaction). > 4. Send pull-request to vim project on github. > (Also add URL of cafe mail to PR) > > [1]: https://github.com/vim/vim/blob/master/CONTRIBUTING.md# > syntax-indent-and-other-runtime-files > > Regards, > Takenobu > > > 2018-03-18 22:10 GMT+09:00 Marcin Szamotulski : > >> Hi Takenobu, >> >> Thanks for sharing this, I'll prepare a PR. >> Bram usually asks that patches for runtime files are send to him from the >> maintainer, is this an exception? >> Does anyone here on haskell-cafe, review the changes? >> >> Regards, >> Marcin >> >> On 11 March 2018 at 14:39, Takenobu Tani wrote: >> >>> Hi Marcin, >>> >>> Is this usefull for you? >>> >>> https://mail.haskell.org/pipermail/haskell-cafe/2017-Decembe >>> r/128309.html >>> >>> Regards, >>> Takenobu >>> >>> >>> 2018-03-11 21:44 GMT+09:00 Marcin Szamotulski : >>> >>>> Hello, >>>> >>>> I am looking for the maintainer of the haskell vim syntax script. The >>>> header points to the haskell-cafe mailing lists. >>>> >>>> I added @Spell and @NoSpell groups so it's easier to spell check haskell >>>> in vim. I hope others will find it useful :) >>>> >>>> Best regards, >>>> Marcin Szamotulski >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wolfgang-it at jeltsch.info Mon Mar 19 15:00:41 2018 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Mon, 19 Mar 2018 17:00:41 +0200 Subject: [Haskell-cafe] Vim + literal Haskell + dollar symbols In-Reply-To: References: <1521452870.2379.6.camel@jeltsch.info> Message-ID: <1521471641.2379.10.camel@jeltsch.info> Hi, Ivan! Unfortunately, I cannot reproduce your problem. With my Vim configuration, I get this: https://ibb.co/e6RLKc. Interestingly, the syntax hightlighting I get generally looks quite different from the one you get. I don’t know how to get a change into Vim’s default syntax/lhaskell.vim. Also, my patch might not be optimal (it almost duplicates some code). All the best, Wolfgang Am Montag, den 19.03.2018, 07:09 -0400 schrieb Ivan Perez: > Hi Wolfgang, > > Thanks. > > That change does help, but it still gets confused. > > Screenshot: https://ibb.co/jD6mPc > > Could that change be made permanent though? Could it be added to vim's > default lhaskell.vim? > > Cheers > > Ivan > > On 19 March 2018 at 05:47, Wolfgang Jeltsch > wrote: > > Hi, Ivan! > > > > Does this problem occur with code environments or only with spec > > environments? At least Vim 7.4 does not mention spec in > > syntax/lhaskell.vim. I have patched this file such that it does all > > the things with spec that it does with code, and it works just fine. > > The patch is as follows: > > > > > 78c78 > > > <     if > > > search('\\documentclass\|\\begin{\(code}\)\@!\|\\\(sub\)*section\| > > > \\chapter|\\part','W') != 0 > > > --- > > > >     if > > > search('\\documentclass\|\\begin{\(code}\)\@!\|\\begin{\(spec}\)\@ > > > !\|\\\(sub\)*section\|\\chapter|\\part','W') != 0 > > > 110a111 > > > > syntax region lhsHaskellBeginEndBlock start="^\\begin{spec}\s*$" > > > matchgroup=NONE end="\%(^\\end{spec}.*$\)\@=" contains=@haskellTop > > > ,beginCodeBegin containedin=@lhsTeXContainer > > All the best, > > Wolfgang > > > > Am Sonntag, den 18.03.2018, 01:39 -0400 schrieb Ivan Perez: > > > Hi cafe, > > > > > > The lhaskell edit mode for lhs2tex documents in vim gets confused > > > when a dollar is used in code. > > > > > > This also makes the spellchecker ignore text paragraphs (until a > > > matching $ is found). > > > > > > Where should this be reported? > > > > > > This list is named as maintainer in the Ubuntu package vim- > > > runtime's lhaskell.vim syntax file: > > > > > > " Maintainer:           Haskell Cafe mailinglist > > > kell.org> > > > " Original Author:      Arthur van Leeuwen > > > " Last Change:          2010 Apr 11 > > > " Version:              1.04 > > > > > > Cheers > > > > > > Ivan > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view 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 samth at cs.indiana.edu Mon Mar 19 18:17:12 2018 From: samth at cs.indiana.edu (Sam Tobin-Hochstadt) Date: Mon, 19 Mar 2018 14:17:12 -0400 Subject: [Haskell-cafe] The Racket School 2018: Create your own language Message-ID: The Racket School 2018: Create your own language 9–13 July • Salt Lake City The Racket team has spent over thirty years developing and refining a coherent intellectual tradition for studying and building programming languages. This year’s school will introduce participants to Racket’s framework for language-oriented programming, which the summer school faculty recently spelled out in a a cover article in the Communications of the ACM. [https://tinyurl.com/RacketCACM] Concretely, the 2018 Racket Summer School will cover the following topics: • the spectrum of programming languages; • modules and syntax, or languages as libraries; • DrRacket’s support for language-oriented programming; • a domain-specific language for adding types to languages; • tools and techniques for implementing notational conveniences; and • research challenges in language-oriented programming. If these topics intrigue you, attend the Racket Summer School: http://summer-school.racket-lang.org/2018/ This is not your run-of-the-mill summer school. We will do our best to make it exciting, entertaining, and useful to a broad spectrum of attendees, both academic and industrial. P.S. We will send you your first problem set in June, a month before the summer school to whet your appetite. From kei at lanl.gov Mon Mar 19 18:27:39 2018 From: kei at lanl.gov (Kei Davis) Date: Mon, 19 Mar 2018 12:27:39 -0600 Subject: [Haskell-cafe] CfP: Workshop on Functional High-Performance Computing 2018 at ICFP In-Reply-To: References: Message-ID: <5ecfdefb-39a7-ac65-1344-123ef18ae3ab@lanl.gov>                              CALL FOR PAPERS   FHPC 2018    7th ACM SIGPLAN Workshop on Functional High-Performance Computing             September 29, 2018, St. Louis, Missouri, USA https://icfp18.sigplan.org/track/FHPC-2018-papers The 7th ACM SIGPLAN Workshop on Functional High-Performance Computing (FHPC’18) is being held as in previous years in conjunction with the International Conference on Functional Programming (ICFP’18) together with numerous other workshops/symposia, and as a first, colocated with Strange Loop, in St. Louis, Missouri, USA. Workshop Objectives The FHPC’18 workshop seeks to bring together researchers and practitioners exploring uses of functional (or more generally, declarative or high-level) programming systems or concepts in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented (low-level) imperative implementations. All aspects of performance-critical programming and parallel programming are in scope for the workshop, irrespective of hardware target. This includes both traditional large-scale distributed-memory scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. FHPC 2018 seeks to encourage a range of submissions, focusing on work in progress and facilitating early exchange of ideas and open discussion on innovative and/or emerging results. Original research, experience reports, case studies, and evaluations of programming systems are all welcome. Work on incorporation of functional programming concepts into more traditional (imperative) HPC applications is explicitly solicited. This year FHPC provides authors the opportunity to submit for evaluation any relevant artifacts that accompany their papers. The dissemination of artifacts promotes reproducibility, and enables authors to build on top of each others’ work, while it can also help to more unambiguously resolve questions about cases not considered by the original authors. For the purpose of FHPC, we plan to reward selected artifacts with additional presentation time in a dedicated slot during the workshop, for example, for demonstrating (i) reproducibility of results or (ii) practical usage of the framework (visualization, demos, etc). Artifact Details The artifact-evaluation committee (AEC) will accept any artifact that authors wish to submit. Obviously, the better the artifact is packaged, the more likely the AEC can actually work with it. We ask the authors to provide provide the title of the FHPC paper submission, together with three files: *     a .pdf file that provides detailed instructions to the reviewers about how to install the artifact and what to look for in the evaluations *     an archive .zip or .tar.gz containing the artifact *     the submitted FHPC’18 paper (.pdf file) The artifact evaluation process is intended to encourage an open and constructive communication (via HotCRP) between (anonymous) reviewers and authors. Submission of an artifact does not constitute tacit permission to make its content public. AEC members will be instructed that they may not publicise any part of your artifact during or after completing evaluation, nor retain any part of it after evaluation. Thus, you are free to include models, data files, proprietary binaries, and similar items in your artifact. The AEC organisers strongly encourage you to anonymise any data files that you submit. Publication The proceedings of FHPC’18 will be published by the ACM Digital Press. Important Dates *     Submission Deadline: June 8, 2018 anywhere on Earth. *     Notification: early July (TBD) *     Camera ready: late July (TBD) *     Final version of proceedings available: Sept. 9 *     FHPC 2018: Saturday Sept. 29, 2018. Official website, submissions, registration details https://icfp18.sigplan.org/track/FHPC-2018-papers Previous FHPC websites https://icfp17.sigplan.org/track/FHPC-2017-papers https://sites.google.com/site/fhpcworkshops/ ICFP and related workshops https://conf.researchr.org/home/icfp-2018 https://icfp18.sigplan.org Strange Loop https://www.thestrangeloop.com/ Questions or comments? fhpc18 at gmail.com Kei Davis and Mike Rainey, co-chairs From danburton.email at gmail.com Mon Mar 19 22:10:21 2018 From: danburton.email at gmail.com (Dan Burton) Date: Mon, 19 Mar 2018 15:10:21 -0700 Subject: [Haskell-cafe] Register for BayHac 2018 Message-ID: Registration form: https://goo.gl/forms/1gYlTQVNwPkKGgC02 All attendees are requested to register for the event via the registration form. Registration form: https://goo.gl/forms/1gYlTQVNwPkKGgC02 Propose a talk or workshop: https://goo.gl/forms/TZbFNIZu4Q1dEh2g2 More info: https://wiki.haskell.org/BayHac2018 -- Dan Burton -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BayHac-Blue.png Type: image/png Size: 251943 bytes Desc: not available URL: From sanyanegi99 at gmail.com Tue Mar 20 02:26:49 2018 From: sanyanegi99 at gmail.com (Sanya Negi) Date: Tue, 20 Mar 2018 07:56:49 +0530 Subject: [Haskell-cafe] GSoC project Message-ID: Hello! I am extremely interested in the project " offline mode for stack " for GSoC, for which I have learnt basic stack and have been learning more. Please guide me as to what other specific things I have to delve into and how to break this problem into pieces to form my proposal. I can't seem to get in touch with the projects mentor Emanuel Borsboom. And as the deadline is reaching, I really need to start forming my proposal now. Soliciting a prompt and positive response. Sanya Negi -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Tue Mar 20 09:54:29 2018 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 20 Mar 2018 05:54:29 -0400 Subject: [Haskell-cafe] Listing Yampa projects Message-ID: Dear all, I would like to facilitate transitioning to new versions of Yampa when there are breaking changes in the library. Also, when there is a proposal to deprecate a feature, this will help understand if it's still being used. I've created a github issue so that people can list their projects: https://github.com/ivanperez-keera/Yampa/issues/68 If you have a project, example, or paper that uses yampa and you want to keep it in a working state, please comment. If there's a project, maybe not your own, that you'd like to see working, please say so, even if there is no maintainer at the moment. Cheers Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Tue Mar 20 12:43:38 2018 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 20 Mar 2018 13:43:38 +0100 (CET) Subject: [Haskell-cafe] directory package copyFile error Message-ID: <2062598800.494778.1521549818496@webmail.strato.de> Dear cafe, not sure whether this is a bug or misusage on my part: I'm using stack lts-9.2, which entails directory-1.3.0.0. I have a file on a samba share, say /mnt/remote/foo. I read the file, modify its contents in my program and save a local copy, say /tmp/foo. Then I try to copy the modified file back to its original place using System.Directory.copyFile "/tmp/foo" "/mnt/remote/foo" Sometimes the copyFile command produces an error like this: /mnt/remote/.copyFile1804289383846930886.tmp: copyFile:atomicCopyFileContents:withReplacementFile:hClose: does not exist (Host is down) When I copy /tmp/foo to /mnt/remote/foo using the shell, everything works fine. Does anyone have an idea what goes wrong? Internally withReplacementFile is used which indeed creates a temporary file to not risk corrupting the original. Is this maybe due to a wrong ordering of IO actions? Thanks Olaf From nicolas.wu at bristol.ac.uk Tue Mar 20 12:46:36 2018 From: nicolas.wu at bristol.ac.uk (Nicolas Wu) Date: Tue, 20 Mar 2018 12:46:36 +0000 Subject: [Haskell-cafe] Call for Submissions: Haskell Symposium 2018 Message-ID: <6CCF0D40-1F18-4093-8A8D-990940E20473@bristol.ac.uk> ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2018 St. Louis, MO, United States 27--28 September, 2018 http://www.haskell.org/haskell-symposium/2018/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2018 will be co-located with the 2018 International Conference on Functional Programming (ICFP), in St. Louis, Missouri, USA. The Haskell Symposium aims to present original research on Haskell, discuss practical experience and future development of the language, and to promote other forms of denotative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts. * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. More advice is available via the Haskell wiki. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. Submission Details ================== Early and Regular Track ----------------------- The Haskell Symposium uses a two-track submission process so that some papers can gain early feedback. Strong papers submitted to the early track are accepted outright, and the others will be given their reviews and invited to resubmit to the regular track. Papers accepted via the early and regular tracks are considered of equal value and will not be distinguished in the proceedings. Although all papers may be submitted to the early track, authors of functional pearls and experience reports are particularly encouraged to use this mechanism. The success of these papers depends heavily on the way they are presented, and submitting early will give the program committee a chance to provide feedback and help draw out the key ideas. Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format Functional pearls, experience reports, and demo proposals should be labelled clearly as such. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. Deadlines --------- Early track: Submission deadline: 30 March 2018 (Fri) Notification: 18 May 2018 (Fri) Regular track and demos: Submission deadline: 8 June 2018 (Fri) Notification: 13 July 2018 (Fri) Deadlines are valid anywhere on Earth. Submission ---------- Submissions should adhere to SIGPLAN's republication policy, as explained on the web. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through easychair at: https://easychair.org/conferences/?conf=haskell2018 Travel Support ============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC program, see its web page (http://pac.sigplan.org). Proceedings =========== Accepted papers will be included in the ACM Digital Library. Authors must grant ACM publication rights upon acceptance (http://authors.acm.org/main.html). Authors are encouraged to publish auxiliary material with their paper (source code, test data, etc.); they retain copyright of auxiliary material. Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. All accepted papers and proposals will be posted on the conference website one week before the meeting. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Program Committee ================= Michael D. Adams University of Utah Patrick Bahr IT University of Copenhagen Olaf Chitil University of Kent Nils Anders Danielsson University of Gothenburg Graham Hutton University of Nottingham Mauro Jaskelioff CONICET/Universidad Nacional de Rosario Oleg Kiselyov Tohoku University Sam Lindley The University of Edinburgh Andres Löh Well-Typed LLP Bruno Oliveira The University of Hong Kong Maciej Piróg University of Wrocław Wren Romano Google Mark Shinwell Jane Street Niki Vazou University of California Marcos Viera Universidad de la República Nicolas Wu (Chair) University of Bristol Ryan Yates University of Rochester Brent Yorgey Hendrix College If you have questions, please contact the chair at: nicolas.wu at bristol.ac.uk ================================================================================ From sean.chalmers at data61.csiro.au Wed Mar 21 04:45:05 2018 From: sean.chalmers at data61.csiro.au (Sean Chalmers) Date: Wed, 21 Mar 2018 14:45:05 +1000 Subject: [Haskell-cafe] =?utf-8?q?=5BANN=5D_New_QFPL_Applied_Functional_Pr?= =?utf-8?b?b2dyYW1taW5nIENvdXJzZSDwn46JIPCfjok=?= Message-ID: <50fdb372-68bd-e7e1-554b-249fc4133e3d@data61.csiro.au> Hi everyone, After successful trials in Sydney, Melbourne, and Brisbane, we're pleased to present our new **Applied Functional Programming Course**. Designed for those of you beyond the intro stage and hungry for more. This is new course material that is targeted toward programmers who have become proficient with navigating Functional Programming concepts and would like to progress to building a complete application. This course material involves writing a REST application with a database backend. Topics covered include: * Hackage and the general Haskell ecosystem * Cabal files and project structure * Database integration * Configuration * Monad transformers * Testing * Type driven development The assumed Haskell knowledge for this course is that you are comfortable with Applicative, and you are able to write the definition for a function with the type:     Applicative f => [f a] -> f [a] As with all of our course material, we invite and encourage you to submit issues and pull-requests. We build these courses for you, so if things aren't working. With either the content or any of the moving parts, we want to know. These courses are run free of charge, in Australia. When and where we run them is based on demand. So if you or your team are keen, then let us know. We can also arrange to run them in-house. Our contact details are here: https://qfpl.io/contact/. More info about both of our current courses is available on our projects page: https://qfpl.io/projects/courses/. Cheers, Sean Chalmers Functional Programming Engineer Queensland FP Lab Data61 / CSIRO Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From whosekiteneverfly at gmail.com Wed Mar 21 09:50:59 2018 From: whosekiteneverfly at gmail.com (Yuji Yamamoto) Date: Wed, 21 Mar 2018 18:50:59 +0900 Subject: [Haskell-cafe] problem with stack behind proxy In-Reply-To: References: Message-ID: FYI. If your office's proxy server is authenticated with NTLM authentication, use CNTLM http://cntlm.sourceforge.net/ , a proxy of proxy for NTLM-authenticated server. Actually, my last office uses it :) 2018-03-21 18:46 GMT+09:00 Nikos Karagiannidis : > Thank you both for your help! > > I have tried to embed a URI encoded username and password in the > HTTP_PROXY setting but still did not work. > I have managed to find an alternative proxy by talking to the network > department that does not require authentication! > So now "stack upgrade" works for me too! > > I will continue with this workaround for now ... > > many thanks! > Nikos > > > On Wed, Mar 21, 2018 at 6:05 AM, Yuji Yamamoto < > whosekiteneverfly at gmail.com> wrote: > >> According to the error, you must set proxy user name and password to pass >> the authentication. >> >> Like this: >> >> HTTP_PROXY = http://username:password at proxy-host:8080 >> >> HTTPS_PROXY = http:// username:password@ >> proxy-host:8080 >> >> Note that you must URI-encode the username or password if they include >> some meta-characters like a colon or an at-sign. >> >> Besides, stack 1.3.2 is too old! >> >> 2018-03-21 2:00 GMT+09:00 Nikos Karagiannidis : >> >>> Hi all, >>> >>> I am trying to run stack build, or stack update behind the corporate web >>> proxy and I get the following error: >>> >>> $ stack build >>> Downloading lts-11.1 build plan ...HttpExceptionRequest Request { >>> host = "raw.githubusercontent.com" >>> port = 443 >>> secure = True >>> requestHeaders = [] >>> path = "/fpco/lts-haskell/master//lts-11.1.yaml" >>> queryString = "" >>> method = "GET" >>> proxy = Nothing >>> rawBody = False >>> redirectCount = 10 >>> responseTimeout = ResponseTimeoutDefault >>> requestVersion = HTTP/1.1 >>> } >>> (ProxyConnectException "raw.githubusercontent.com" 443 (Status >>> {statusCode = 407, statusMessage = "Proxy Authentication Required ( >>> Forefront TMG requires authorization to fulfill the request. Access to the >>> Web Proxy filter is denied. )"})) >>> >>> My stack version is: >>> >>> $ stack --version >>> Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 >>> x86_64 hpack-0.15.0 >>> >>> I have set the HTTP_PROXY and HTTPS_PROXY environment variables to a >>> value of: >>> HTTP_PROXY = http://proxy-host:8080 >>> HTTPS_PROXY = http://proxy-host:8080 >>> >>> Can you help me how to achieve proxy authentication via stack? >>> >>> thank you in advance! >>> >>> Nikos >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-stack" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-stack+unsubscribe at googlegroups.com. >>> To post to this group, send email to haskell-stack at googlegroups.com. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/haskell-stack/CAN0STeQPzM2SyxyYUiy3o2HS%2BDMw8sWmTcyWZHi >>> -LwLANjY%2BtQ%40mail.gmail.com >>> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> 山本悠滋 >> twitter: @igrep >> GitHub: https://github.com/igrep >> GitLab: https://gitlab.com/igrep >> Facebook: http://www.facebook.com/igrep >> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep >> > > -- 山本悠滋 twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Wed Mar 21 10:13:54 2018 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 21 Mar 2018 21:13:54 +1100 Subject: [Haskell-cafe] problem with stack behind proxy In-Reply-To: References: Message-ID: On 21 March 2018 at 20:50, Yuji Yamamoto wrote: > FYI. > > If your office's proxy server is authenticated with NTLM authentication, > use CNTLM http://cntlm.sourceforge.net/ , a proxy of proxy for > NTLM-authenticated server. > Actually, my last office uses it :) This works for me as well (though before that I had http[s]_proxy and HTTP[S]_PROXY all set and I think that also worked). > > 2018-03-21 18:46 GMT+09:00 Nikos Karagiannidis : >> >> Thank you both for your help! >> >> I have tried to embed a URI encoded username and password in the >> HTTP_PROXY setting but still did not work. >> I have managed to find an alternative proxy by talking to the network >> department that does not require authentication! >> So now "stack upgrade" works for me too! >> >> I will continue with this workaround for now ... >> >> many thanks! >> Nikos >> >> >> On Wed, Mar 21, 2018 at 6:05 AM, Yuji Yamamoto >> wrote: >>> >>> According to the error, you must set proxy user name and password to pass >>> the authentication. >>> >>> Like this: >>> >>> HTTP_PROXY = http://username:password at proxy-host:8080 >>> HTTPS_PROXY = http://username:password@ proxy-host:8080 >>> >>> Note that you must URI-encode the username or password if they include >>> some meta-characters like a colon or an at-sign. >>> >>> Besides, stack 1.3.2 is too old! >>> >>> 2018-03-21 2:00 GMT+09:00 Nikos Karagiannidis : >>>> >>>> Hi all, >>>> >>>> I am trying to run stack build, or stack update behind the corporate web >>>> proxy and I get the following error: >>>> >>>> $ stack build >>>> Downloading lts-11.1 build plan ...HttpExceptionRequest Request { >>>> host = "raw.githubusercontent.com" >>>> port = 443 >>>> secure = True >>>> requestHeaders = [] >>>> path = "/fpco/lts-haskell/master//lts-11.1.yaml" >>>> queryString = "" >>>> method = "GET" >>>> proxy = Nothing >>>> rawBody = False >>>> redirectCount = 10 >>>> responseTimeout = ResponseTimeoutDefault >>>> requestVersion = HTTP/1.1 >>>> } >>>> (ProxyConnectException "raw.githubusercontent.com" 443 (Status >>>> {statusCode = 407, statusMessage = "Proxy Authentication Required ( >>>> Forefront TMG requires authorization to fulfill the request. Access to the >>>> Web Proxy filter is denied. )"})) >>>> >>>> My stack version is: >>>> >>>> $ stack --version >>>> Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 >>>> x86_64 hpack-0.15.0 >>>> >>>> I have set the HTTP_PROXY and HTTPS_PROXY environment variables to a >>>> value of: >>>> HTTP_PROXY = http://proxy-host:8080 >>>> HTTPS_PROXY = http://proxy-host:8080 >>>> >>>> Can you help me how to achieve proxy authentication via stack? >>>> >>>> thank you in advance! >>>> >>>> Nikos >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "haskell-stack" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to haskell-stack+unsubscribe at googlegroups.com. >>>> To post to this group, send email to haskell-stack at googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/haskell-stack/CAN0STeQPzM2SyxyYUiy3o2HS%2BDMw8sWmTcyWZHi-LwLANjY%2BtQ%40mail.gmail.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> >>> -- >>> 山本悠滋 >>> twitter: @igrep >>> GitHub: https://github.com/igrep >>> GitLab: https://gitlab.com/igrep >>> Facebook: http://www.facebook.com/igrep >>> Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep >> >> > > > > -- > 山本悠滋 > twitter: @igrep > GitHub: https://github.com/igrep > GitLab: https://gitlab.com/igrep > Facebook: http://www.facebook.com/igrep > Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From makos999 at gmail.com Wed Mar 21 11:48:13 2018 From: makos999 at gmail.com (Mr. Akos) Date: Wed, 21 Mar 2018 12:48:13 +0100 Subject: [Haskell-cafe] GSoC project In-Reply-To: References: Message-ID: Hi Sanya, For breaking down the problem, have you seen this? https://github.com/AleXoundOS/haskell-stack-mirror-script Best, Akos Marton On Tue, Mar 20, 2018 at 3:26 AM, Sanya Negi wrote: > Hello! > > I am extremely interested in the project " offline mode for stack " for > GSoC, for which I have learnt basic stack and have been learning more. > > Please guide me as to what other specific things I have to delve into and > how to break this problem into pieces to form my proposal. > > I can't seem to get in touch with the projects mentor Emanuel Borsboom. > And as the deadline is reaching, I really need to start forming my > proposal now. > > Soliciting a prompt and positive response. > > Sanya Negi > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- People seldom notice clothes, if you wear a big smile. My grandmother uses Ubuntu, don't you think so?! OLVASD: http://www.xkcd.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke_lau at icloud.com Thu Mar 22 06:34:33 2018 From: luke_lau at icloud.com (Luke Lau) Date: Thu, 22 Mar 2018 02:34:33 -0400 Subject: [Haskell-cafe] Summer of Code projects Message-ID: Hello, I’m a beginner-intermediate Haskell programmer and would like to help out this summer with the SoC projects! I have a few questions about some of the project ideas: https://summer.haskell.org/ideas.html#format-preserving-yaml Would this new library aim to also use the C library behind the scenes, or would there be more interest in making a completely native Haskell version? (Do FFI calls in Haskell have any performance overhead?) https://github.com/haskell/haskell-ide-engine This seems really cool! There are a lot of cool goals on the list I would like to take a stab at. Sharing build cache between HaRe and GHC, to drastically improve refactoring speed. Are there any examples of this being done with any other IDE extensions or build tools? Rewriting the completion system/LSP tests Are there any parts of the LSP specification that are missing or could be implemented better? Also I was curious as to what libraries/tools are used for parsing and analysing, if any at all? I briefly looked through the repository and couldn’t find anything particularly low-level. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From manny at fpcomplete.com Thu Mar 22 12:31:07 2018 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Thu, 22 Mar 2018 05:31:07 -0700 Subject: [Haskell-cafe] Summer of Code projects In-Reply-To: References: Message-ID: <7DCE5D10-D8CF-4306-9A62-173D4446DC4C@fpcomplete.com> > On Mar 21, 2018, at 11:34 PM, Luke Lau wrote: > > https://summer.haskell.org/ideas.html#format-preserving-yaml > Would this new library aim to also use the C library behind the scenes, or would there be more interest in making a completely native Haskell version? (Do FFI calls in Haskell have any performance overhead?) If it's possible to do this using the C library behind the scenes then I don't see any reason not that. That said, my understanding is that the C library doesn't support this use case, so it's likely you'd have to write a pure Haskell implementation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Thu Mar 22 17:39:48 2018 From: codygman.consulting at gmail.com (Cody Goodman) Date: Thu, 22 Mar 2018 17:39:48 +0000 Subject: [Haskell-cafe] Summer of Code projects In-Reply-To: <7DCE5D10-D8CF-4306-9A62-173D4446DC4C@fpcomplete.com> References: <7DCE5D10-D8CF-4306-9A62-173D4446DC4C@fpcomplete.com> Message-ID: Ive had the idea to do this with json on the backburner. Inspiration being modifying json that follows no format and extra diffs annoy others. - Cody On Thu, Mar 22, 2018, 7:33 AM Emanuel Borsboom wrote: > > On Mar 21, 2018, at 11:34 PM, Luke Lau wrote: > > https://summer.haskell.org/ideas.html#format-preserving-yaml > Would this new library aim to also use the C library behind the scenes, or > would there be more interest in making a completely native Haskell version? > (Do FFI calls in Haskell have any performance overhead?) > > > If it's *possible* to do this using the C library behind the scenes then > I don't see any reason not that. That said, my understanding is that the C > library doesn't support this use case, so it's likely you'd have to write a > pure Haskell implementation. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 carter.schonwald at gmail.com Thu Mar 22 21:50:29 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 22 Mar 2018 17:50:29 -0400 Subject: [Haskell-cafe] Dropping containers support for old GHC versions In-Reply-To: References: Message-ID: agreed On Fri, Mar 9, 2018 at 11:35 AM, Adam Bergmark wrote: > I appreciate that it may be hard/undesirable for some to use the latest > GHC, but overall I don't think we should need to maintain backwards > compatibility indefinitely because of that. Older versions of containers > will still work with older GHCs, and other libraries depending on > containers will still work as well as long as they support older container > versions. > > But nevertheless, at least it seems there are no objections to dropping > 7.0 and 7.2.2 support so far? :) > > Cheers, > Adam > > > On Fri, 9 Mar 2018 at 17:20 Daniel Cartwright > wrote: > >> David, I just checked and you're correct - I believe I was remembering >> some other library(ies), though I can't recall which ones. >> >> On Fri, Mar 9, 2018 at 11:08 AM, David Feuer >> wrote: >> >>> On Mar 9, 2018 10:55 AM, "Daniel Cartwright" >>> wrote: >>> >>> >>> On a related note, I find it strange when looking through source code >>> for 'containers'/other Haskell libraries and still see notes about >>> supporting non-GHC Haskell compilers (e.g. Hugs) >>> >>> >>> I believe we've stripped all references to Hugs and nhc98 from >>> containers. If you find any, let us know. I'd be interested in adding >>> support for Frege, but the way it deals with numeric literals could be >>> problematic. >>> >>> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Fri Mar 23 01:01:24 2018 From: jclites at mac.com (Jeff Clites) Date: Thu, 22 Mar 2018 18:01:24 -0700 Subject: [Haskell-cafe] Summer of Code projects In-Reply-To: References: <7DCE5D10-D8CF-4306-9A62-173D4446DC4C@fpcomplete.com> Message-ID: I want this sort of thing for xml as well--preserving whitespace between (and ordering of) attributes, etc.--basically all of the things which are semantically irrelevant. JEff > On Mar 22, 2018, at 10:39 AM, Cody Goodman wrote: > > Ive had the idea to do this with json on the backburner. Inspiration being modifying json that follows no format and extra diffs annoy others. > > - Cody > >> On Thu, Mar 22, 2018, 7:33 AM Emanuel Borsboom wrote: >> >>> On Mar 21, 2018, at 11:34 PM, Luke Lau wrote: >>> >>> https://summer.haskell.org/ideas.html#format-preserving-yaml >>> Would this new library aim to also use the C library behind the scenes, or would there be more interest in making a completely native Haskell version? (Do FFI calls in Haskell have any performance overhead?) >> >> If it's possible to do this using the C library behind the scenes then I don't see any reason not that. That said, my understanding is that the C library doesn't support this use case, so it's likely you'd have to write a pure Haskell implementation. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 cb307 at st-andrews.ac.uk Fri Mar 23 15:55:38 2018 From: cb307 at st-andrews.ac.uk (Charles Blake) Date: Fri, 23 Mar 2018 15:55:38 +0000 Subject: [Haskell-cafe] GSoC Project Introduction: Accelerate Automatic Differentiation Message-ID: Dear all, I'm a student interested in the GSoC programme and I wanted to introduce myself and make contact with those involved in potentially mentoring for the 'Implementing Automatic Differentiation in Accelerate' project (https://summer.haskell.org/ideas.html#accelerate-automatic-differentiation). If it would be more appropriate for me to contact those individuals directly then please let me know. My name is Charlie Blake, and I'm currently coming to the end of my CS undergrad degree. Much of my study of late has been focused on functional programming and parallelism - so when I saw this project proposal it jumped out at me! I was expecting to be assisting research at my university (St Andrews University, Scotland) in this field over the summer, but this arrangement has recently fallen through. Hence why I'm unfortunately sending this message rather close to the deadline. Nevertheless, I'm now hoping very much to get on the GSoC program, to which I am very much committed. With regards to the project itself, I'm currently in the process of drawing up a proposal. Although I'm making every effort to read as much as I can about the 'ad' and 'accelerate' libraries, it's still quite hard to get a good sense of the scope of the project. Would, for instance, it be a reasonable goal to expect to be able to implement all of the core 'ad' functionality in my own parallel library in the time-frame? This seems like the natural objective, but I don't want to propose an unrealistically large project if this is not feasible. If anyone has answers to these questions and might further be willing to discuss a draft project proposal with me over the next few days that would be greatly appreciated. Many thanks, Charlie Blake -------------- next part -------------- An HTML attachment was scrubbed... URL: From callan.mcgill at gmail.com Fri Mar 23 19:22:04 2018 From: callan.mcgill at gmail.com (Callan McGill) Date: Fri, 23 Mar 2018 19:22:04 +0000 Subject: [Haskell-cafe] Oxford Haskell User Group Message-ID: Hi! I am interested in starting a Haskell user group (or functional programming meetup) in Oxford and would like to hear from anyone else wanting to help organise it. Please feel free to get in contact. Best, Callan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat Mar 24 13:48:56 2018 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 24 Mar 2018 14:48:56 +0100 Subject: [Haskell-cafe] Incorrect link to Haskell Summer of Code page on Reddit Message-ID: L.S., The Reddit forum haskell_proposals links to "Haskell Google Summer of Code site", which is https://ghc.haskell.org/trac/summer-of-code/wiki/WikiStart The linked page contains a suggestion for which shoes to buy for "running, casual wear, lifting". I suppose the subreddit should point to https://summer.haskell.org/ (The Haskell Summer of Code Trac also contains spam in the Tickets.) Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From aeroboy94 at gmail.com Sat Mar 24 14:45:12 2018 From: aeroboy94 at gmail.com (Arian van Putten) Date: Sat, 24 Mar 2018 14:45:12 +0000 Subject: [Haskell-cafe] Incorrect link to Haskell Summer of Code page on Reddit In-Reply-To: References: Message-ID: This seems to be wikispam. The page did have correct information at first On Sat, 24 Mar 2018, 14:50 Henk-Jan van Tuyl, wrote: > > L.S., > > The Reddit forum haskell_proposals links to "Haskell Google Summer of Code > site", which is > https://ghc.haskell.org/trac/summer-of-code/wiki/WikiStart > The linked page contains a suggestion for which shoes to buy for "running, > casual wear, lifting". I suppose the subreddit should point to > https://summer.haskell.org/ > > (The Haskell Summer of Code Trac also contains spam in the Tickets.) > > Regards, > Henk-Jan van Tuyl > > > -- > Message from Stanford University: > > Folding at home > > What if you could share your unused computer power to help find a cure? In > just 5 minutes you can join the world's biggest networked computer and get > us closer sooner. Watch the video. > http://foldingathome.stanford.edu/ > > -- > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 akhilses at gmail.com Sat Mar 24 16:16:29 2018 From: akhilses at gmail.com (Akhil Seshan) Date: Sat, 24 Mar 2018 21:46:29 +0530 Subject: [Haskell-cafe] I am interested in doing Offline mode for Stack as GSoC 2018 project Message-ID: Hi, I am Akhil Seshan, B.Tech Computer Science and Engineering Student. I would like to do Offline mode for Stack as the GSoC 2018 project. I have basic knowledge in Haskell/Functional programming but have an intermediate knowledge in Object oriented programming. I used Stack which is used for running Haskell programs. Kindly do let me know the details for moving forward with this as my project, -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Sat Mar 24 16:50:58 2018 From: gershomb at gmail.com (Gershom B) Date: Sat, 24 Mar 2018 12:50:58 -0400 Subject: [Haskell-cafe] Incorrect link to Haskell Summer of Code page on Reddit In-Reply-To: References: Message-ID: Thanks for the report. I updated the page to revert the spam and point to the right page. I  think we should probably just add a server-level redirect in the future. Cc: ben, haskell-admins —gershom On March 24, 2018 at 10:47:26 AM, Arian van Putten (aeroboy94 at gmail.com) wrote: This seems to be wikispam. The page did have correct information at first On Sat, 24 Mar 2018, 14:50 Henk-Jan van Tuyl, wrote: L.S., The Reddit forum haskell_proposals links to "Haskell Google Summer of Code site", which is    https://ghc.haskell.org/trac/summer-of-code/wiki/WikiStart The linked page contains a suggestion for which shoes to buy for "running, casual wear, lifting". I suppose the subreddit should point to    https://summer.haskell.org/ (The Haskell Summer of Code Trac also contains spam in the Tickets.) Regards, Henk-Jan van Tuyl -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://foldingathome.stanford.edu/ -- http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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 mgajda at mimuw.edu.pl Sat Mar 24 16:56:35 2018 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sat, 24 Mar 2018 16:56:35 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation Message-ID: Hi Charlie It certainly looks like exciting project, but the bar is currently placed very high. TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings Maybe Dominic suggests something too. Cheers Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb307 at st-andrews.ac.uk Sat Mar 24 17:20:03 2018 From: cb307 at st-andrews.ac.uk (Charles Blake) Date: Sat, 24 Mar 2018 17:20:03 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: Message-ID: Thanks for the response Michal, Yes, this did cross my mind - and I wouldn't be expecting to outperform those frameworks in the timeframe available! I assumed that the reason that this project was suggested was perhaps: a) there is some intrinsic value in implementing these algorithms natively in haskell (hence why the 'ad' library was developed in the first place), so that those who want to use parallel automatic differentiation / the machine learning algorithms built on top of it can do so without leaving the haskell ecosystem, and b) because the challenges involved in implementing parallel ad in a purely functional language are a little different to those involved in doing so in OO/imperative languages - so it might be interesting from that angle as well? So perhaps my aim would no be to do something unique, but rather to do something that has already done well in other languages, but has not yet been provided as a haskell library. Does this sound like a reasonable approach or do I need to find a slightly more unique angle? Thanks, Charlie ________________________________ From: Michal J Gajda Sent: 24 March 2018 16:56:35 To: Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; Charles Blake; haskell-cafe at haskell.org Subject: Re: Accelerating Automatic Differentiation Hi Charlie It certainly looks like exciting project, but the bar is currently placed very high. TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings Maybe Dominic suggests something too. Cheers Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sat Mar 24 18:32:20 2018 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sat, 24 Mar 2018 18:32:20 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: Message-ID: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> The list of mentors for this project looks great to me. I am not sure if I can add much other than I think this is a nice project. Perhaps it would be best to get the advice of some of the mentors? For some very simple tests with an ODE solver, I concluded that accelerate can perform at least as well as Julia. It would certainly be very helpful to be able to get Jacobians for ODE solving and for other applications. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com Twitter: @idontgetoutmuch > On 24 Mar 2018, at 17:20, Charles Blake wrote: > > Thanks for the response Michal, > > Yes, this did cross my mind - and I wouldn't be expecting to outperform those frameworks in the timeframe available! I assumed that the reason that this project was suggested was perhaps: > > a) there is some intrinsic value in implementing these algorithms natively in haskell (hence why the 'ad' library was developed in the first place), so that those who want to use parallel automatic differentiation / the machine learning algorithms built on top of it can do so without leaving the haskell ecosystem, > > and b) because the challenges involved in implementing parallel ad in a purely functional language are a little different to those involved in doing so in OO/imperative languages - so it might be interesting from that angle as well? > > So perhaps my aim would no be to do something unique, but rather to do something that has already done well in other languages, but has not yet been provided as a haskell library. Does this sound like a reasonable approach or do I need to find a slightly more unique angle? > > Thanks, > Charlie > From: Michal J Gajda > Sent: 24 March 2018 16:56:35 > To: Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; Charles Blake; haskell-cafe at haskell.org > Subject: Re: Accelerating Automatic Differentiation > > Hi Charlie > > It certainly looks like exciting project, but the bar is currently placed very high. > TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. > This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings > Maybe Dominic suggests something too. > Cheers > Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From quentin.liu.0415 at gmail.com Sat Mar 24 19:38:24 2018 From: quentin.liu.0415 at gmail.com (Quentin Liu) Date: Sun, 25 Mar 2018 03:38:24 +0800 Subject: [Haskell-cafe] GSoC Haddock project Message-ID: <6a5e3e87-7703-4cbf-b5f3-d59cad2918df@Spark> Hi all, I am Qingbo Liu, a cs student from Colby College, ME. I’m very interested in the Hi Haddock project and would like to work on it for the summer. Currently I have finished a draft proposal and I am revising it (Thank Alex Biehl here for his kind suggestions). If the project would help you and you are willing to spend some time improving the proposal, please take a look at [1]. Any comment is appreciated. [1] https://docs.google.com/document/d/1BcSeLu8X9QwiM5LzYq5UEU5jIFF7hogdDT3UByUjJiI/edit?usp=sharing Best Regards, Qingbo Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Sat Mar 24 22:32:28 2018 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sat, 24 Mar 2018 22:32:28 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: As a mentor I would say it is certainly possible to outperform exsting mega-solutions in some narrow domain. Just as I did with hPDB https://hackage.haskell.org/package/hPDB But it requires a lot of skill and patiece. Please proceed with this project with the current list of mentors. I think me and Dominic have already declared committment. You might also start by making a table of best competing solutions in other. languages, their respective strengths, and ways that we can possibly improve on them! Where do You keep Your application draft? Ideally it should be a shared space where you can add mentors as co-editors. — Cheers Michal On Sun, 25 Mar 2018 at 02:32, wrote: > The list of mentors for this project looks great to me. I am not sure if I > can add much other than I think this is a nice project. Perhaps it would be > best to get the advice of some of the mentors? > > For some very simple tests with an ODE solver, I concluded that accelerate > can perform at least as well as Julia. It would certainly be very helpful > to be able to get Jacobians for ODE solving and for other applications. > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > Twitter: @idontgetoutmuch > > > > On 24 Mar 2018, at 17:20, Charles Blake wrote: > > Thanks for the response Michal, > > Yes, this did cross my mind - and I wouldn't be expecting to outperform > those frameworks in the timeframe available! I assumed that the reason that > this project was suggested was perhaps: > > a) there is some intrinsic value in implementing these algorithms natively > in haskell (hence why the 'ad' library was developed in the first place), > so that those who want to use parallel automatic differentiation / the > machine learning algorithms built on top of it can do so without leaving > the haskell ecosystem, > > and b) because the challenges involved in implementing parallel ad in a > purely functional language are a little different to those involved in > doing so in OO/imperative languages - so it might be interesting from that > angle as well? > > So perhaps my aim would no be to do something unique, but rather to do > something that has already done well in other languages, but has not yet > been provided as a haskell library. Does this sound like a reasonable > approach or do I need to find a slightly more unique angle? > > Thanks, > Charlie > > ------------------------------ > *From:* Michal J Gajda > *Sent:* 24 March 2018 16:56:35 > *To:* Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; > Charles Blake; haskell-cafe at haskell.org > *Subject:* Re: Accelerating Automatic Differentiation > > > Hi Charlie > > It certainly looks like exciting project, but the bar is currently placed > very high. > TensorFlow package not only provides automatic differentiation for whole > programs, but also optimizes data processing both on GPU, and reading to > achieve large batches. > This field has a lot of hot developments, so You would either need to > propose something unique to Haskell, or You risk being outclassed by > PyTorch and TensorFlow bindings > Maybe Dominic suggests something too. > Cheers > Michal > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Sun Mar 25 05:11:23 2018 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sun, 25 Mar 2018 05:11:23 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: Given that Marco did not confirm, I am just now confirming that we can get you mentored by Mikhail Baikov as the third mentor (beside Dominic and me). Both me (Michal) and Mikhail are performance optimization experts (I am in parsers, and data analytics, Mikhail is in real-time systems, he has his own top-notch serialization library - Beamable that outperforms Cereal in both data size and speed). Dominic is expert in numerical computing (ODEs and Julia, among other things). I believe that with these three excellent mentors you have very good chance to make outstanding contribution. We just make sure that you prep application by 27th deadline. -- Cheers Michal On Sun, Mar 25, 2018 at 6:32 AM Michal J Gajda wrote: > As a mentor I would say it is certainly possible to outperform exsting > mega-solutions in some narrow domain. > Just as I did with hPDB https://hackage.haskell.org/package/hPDB > But it requires a lot of skill and patiece. > > Please proceed with this project with the current list of mentors. > I think me and Dominic have already declared committment. > > You might also start by making a table of best competing solutions in > other. languages, their respective strengths, and ways that we can possibly > improve on them! > > Where do You keep Your application draft? Ideally it should be a shared > space where you can add mentors as co-editors. > — > Cheers > Michal > On Sun, 25 Mar 2018 at 02:32, wrote: > >> The list of mentors for this project looks great to me. I am not sure if >> I can add much other than I think this is a nice project. Perhaps it would >> be best to get the advice of some of the mentors? >> >> For some very simple tests with an ODE solver, I concluded that >> accelerate can perform at least as well as Julia. It would certainly be >> very helpful to be able to get Jacobians for ODE solving and for other >> applications. >> >> Dominic Steinitz >> dominic at steinitz.org >> http://idontgetoutmuch.wordpress.com >> Twitter: @idontgetoutmuch >> >> >> >> On 24 Mar 2018, at 17:20, Charles Blake wrote: >> >> Thanks for the response Michal, >> >> Yes, this did cross my mind - and I wouldn't be expecting to outperform >> those frameworks in the timeframe available! I assumed that the reason that >> this project was suggested was perhaps: >> >> a) there is some intrinsic value in implementing these algorithms >> natively in haskell (hence why the 'ad' library was developed in the first >> place), so that those who want to use parallel automatic differentiation / >> the machine learning algorithms built on top of it can do so without >> leaving the haskell ecosystem, >> >> and b) because the challenges involved in implementing parallel ad in a >> purely functional language are a little different to those involved in >> doing so in OO/imperative languages - so it might be interesting from that >> angle as well? >> >> So perhaps my aim would no be to do something unique, but rather to do >> something that has already done well in other languages, but has not yet >> been provided as a haskell library. Does this sound like a reasonable >> approach or do I need to find a slightly more unique angle? >> >> Thanks, >> Charlie >> >> ------------------------------ >> *From:* Michal J Gajda >> *Sent:* 24 March 2018 16:56:35 >> *To:* Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; >> Charles Blake; haskell-cafe at haskell.org >> *Subject:* Re: Accelerating Automatic Differentiation >> >> >> Hi Charlie >> >> It certainly looks like exciting project, but the bar is currently placed >> very high. >> TensorFlow package not only provides automatic differentiation for whole >> programs, but also optimizes data processing both on GPU, and reading to >> achieve large batches. >> This field has a lot of hot developments, so You would either need to >> propose something unique to Haskell, or You risk being outclassed by >> PyTorch and TensorFlow bindings >> Maybe Dominic suggests something too. >> Cheers >> Michal >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sun Mar 25 07:17:03 2018 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sun, 25 Mar 2018 08:17:03 +0100 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: Hi Michal, I didn’t volunteer to be a mentor for this. The project already lists: > Mentor: Fritz Henglein, Gabriele Keller, Trevor McDonell, Edward Kmett, Sacha Sokoloski I doubt there is much I could add to such an illustrious list. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com Twitter: @idontgetoutmuch > On 25 Mar 2018, at 06:11, Michal J Gajda wrote: > > Given that Marco did not confirm, I am just now confirming that we can get you mentored by Mikhail Baikov as the third mentor (beside Dominic and me). > Both me (Michal) and Mikhail are performance optimization experts (I am in parsers, and data analytics, Mikhail is in real-time systems, he has his own top-notch serialization library - Beamable that outperforms Cereal in both data size and speed). Dominic is expert in numerical computing (ODEs and Julia, among other things). > > I believe that with these three excellent mentors you have very good chance to make outstanding contribution. > We just make sure that you prep application by 27th deadline. > -- > Cheers > Michal > > On Sun, Mar 25, 2018 at 6:32 AM Michal J Gajda > wrote: > As a mentor I would say it is certainly possible to outperform exsting mega-solutions in some narrow domain. > Just as I did with hPDB https://hackage.haskell.org/package/hPDB > But it requires a lot of skill and patiece. > > Please proceed with this project with the current list of mentors. > I think me and Dominic have already declared committment. > > You might also start by making a table of best competing solutions in other. languages, their respective strengths, and ways that we can possibly improve on them! > > Where do You keep Your application draft? Ideally it should be a shared space where you can add mentors as co-editors. > — > Cheers > Michal > On Sun, 25 Mar 2018 at 02:32, > wrote: > The list of mentors for this project looks great to me. I am not sure if I can add much other than I think this is a nice project. Perhaps it would be best to get the advice of some of the mentors? > > For some very simple tests with an ODE solver, I concluded that accelerate can perform at least as well as Julia. It would certainly be very helpful to be able to get Jacobians for ODE solving and for other applications. > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > Twitter: @idontgetoutmuch > > > >> On 24 Mar 2018, at 17:20, Charles Blake > wrote: >> >> Thanks for the response Michal, >> >> Yes, this did cross my mind - and I wouldn't be expecting to outperform those frameworks in the timeframe available! I assumed that the reason that this project was suggested was perhaps: >> >> a) there is some intrinsic value in implementing these algorithms natively in haskell (hence why the 'ad' library was developed in the first place), so that those who want to use parallel automatic differentiation / the machine learning algorithms built on top of it can do so without leaving the haskell ecosystem, >> >> and b) because the challenges involved in implementing parallel ad in a purely functional language are a little different to those involved in doing so in OO/imperative languages - so it might be interesting from that angle as well? >> >> So perhaps my aim would no be to do something unique, but rather to do something that has already done well in other languages, but has not yet been provided as a haskell library. Does this sound like a reasonable approach or do I need to find a slightly more unique angle? >> >> Thanks, >> Charlie >> From: Michal J Gajda > >> Sent: 24 March 2018 16:56:35 >> To: Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com ; Charles Blake; haskell-cafe at haskell.org >> Subject: Re: Accelerating Automatic Differentiation >> > >> Hi Charlie >> >> It certainly looks like exciting project, but the bar is currently placed very high. >> TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. >> This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings >> Maybe Dominic suggests something too. >> Cheers >> Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Sun Mar 25 08:08:54 2018 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sun, 25 Mar 2018 08:08:54 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: Great! If they all agreed, we can just add Mikhail, and done? On Sun, 25 Mar 2018 at 15:17, wrote: > Hi Michal, > > I didn’t volunteer to be a mentor for this. The project already lists: > > *Mentor*: Fritz Henglein, Gabriele Keller, Trevor McDonell, Edward Kmett, > Sacha Sokoloski > > > I doubt there is much I could add to such an illustrious list. > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > Twitter: @idontgetoutmuch > > > > On 25 Mar 2018, at 06:11, Michal J Gajda wrote: > > Given that Marco did not confirm, I am just now confirming that we can get > you mentored by Mikhail Baikov as the third mentor (beside Dominic and me). > Both me (Michal) and Mikhail are performance optimization experts (I am in > parsers, and data analytics, Mikhail is in real-time systems, he has his > own top-notch serialization library - Beamable that outperforms Cereal in > both data size and speed). Dominic is expert in numerical computing (ODEs > and Julia, among other things). > > I believe that with these three excellent mentors you have very good > chance to make outstanding contribution. > We just make sure that you prep application by 27th deadline. > -- > Cheers > Michal > > On Sun, Mar 25, 2018 at 6:32 AM Michal J Gajda > wrote: > >> As a mentor I would say it is certainly possible to outperform exsting >> mega-solutions in some narrow domain. >> Just as I did with hPDB https://hackage.haskell.org/package/hPDB >> But it requires a lot of skill and patiece. >> >> Please proceed with this project with the current list of mentors. >> I think me and Dominic have already declared committment. >> >> You might also start by making a table of best competing solutions in >> other. languages, their respective strengths, and ways that we can possibly >> improve on them! >> >> Where do You keep Your application draft? Ideally it should be a shared >> space where you can add mentors as co-editors. >> — >> Cheers >> Michal >> On Sun, 25 Mar 2018 at 02:32, wrote: >> >>> The list of mentors for this project looks great to me. I am not sure if >>> I can add much other than I think this is a nice project. Perhaps it would >>> be best to get the advice of some of the mentors? >>> >>> For some very simple tests with an ODE solver, I concluded that >>> accelerate can perform at least as well as Julia. It would certainly be >>> very helpful to be able to get Jacobians for ODE solving and for other >>> applications. >>> >>> Dominic Steinitz >>> dominic at steinitz.org >>> http://idontgetoutmuch.wordpress.com >>> Twitter: @idontgetoutmuch >>> >>> >>> >>> On 24 Mar 2018, at 17:20, Charles Blake wrote: >>> >>> Thanks for the response Michal, >>> >>> Yes, this did cross my mind - and I wouldn't be expecting to outperform >>> those frameworks in the timeframe available! I assumed that the reason that >>> this project was suggested was perhaps: >>> >>> a) there is some intrinsic value in implementing these algorithms >>> natively in haskell (hence why the 'ad' library was developed in the first >>> place), so that those who want to use parallel automatic differentiation / >>> the machine learning algorithms built on top of it can do so without >>> leaving the haskell ecosystem, >>> >>> and b) because the challenges involved in implementing parallel ad in a >>> purely functional language are a little different to those involved in >>> doing so in OO/imperative languages - so it might be interesting from that >>> angle as well? >>> >>> So perhaps my aim would no be to do something unique, but rather to do >>> something that has already done well in other languages, but has not yet >>> been provided as a haskell library. Does this sound like a reasonable >>> approach or do I need to find a slightly more unique angle? >>> >>> Thanks, >>> Charlie >>> >>> ------------------------------ >>> *From:* Michal J Gajda >>> *Sent:* 24 March 2018 16:56:35 >>> *To:* Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; >>> Charles Blake; haskell-cafe at haskell.org >>> *Subject:* Re: Accelerating Automatic Differentiation >>> >>> >>> Hi Charlie >>> >>> It certainly looks like exciting project, but the bar is currently >>> placed very high. >>> TensorFlow package not only provides automatic differentiation for whole >>> programs, but also optimizes data processing both on GPU, and reading to >>> achieve large batches. >>> This field has a lot of hot developments, so You would either need to >>> propose something unique to Haskell, or You risk being outclassed by >>> PyTorch and TensorFlow bindings >>> Maybe Dominic suggests something too. >>> Cheers >>> Michal >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb307 at st-andrews.ac.uk Sun Mar 25 12:35:57 2018 From: cb307 at st-andrews.ac.uk (Charles Blake) Date: Sun, 25 Mar 2018 12:35:57 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> , Message-ID: Thanks so much for the feedback - I really appreciate the attention you guys have given me. My draft proposal can be found here: https://docs.google.com/document/d/1bJqoqVsW5pvXJmdkfn3EXY1QKEiTXxQkl2BmREAtBsQ/edit?usp=sharing If you have the chance to look at it and are interested, any feedback would be valuable! In terms of mentors for the project, I'm not entirely familiar with the process involved. I've contacted the mentors originally listed for the project with a copy of my draft proposal, but of course I appreciate your input as well and if there is the option of others joining to mentor the project then that sounds fantastic. Charlie ________________________________ From: Michal J Gajda Sent: 25 March 2018 09:08:54 To: dominic at steinitz.org Cc: Charles Blake; Mikhail Baykov; haskell-cafe at haskell.org; accelerate-haskell at googlegroups.com Subject: Re: Accelerating Automatic Differentiation Great! If they all agreed, we can just add Mikhail, and done? On Sun, 25 Mar 2018 at 15:17, > wrote: Hi Michal, I didn’t volunteer to be a mentor for this. The project already lists: Mentor: Fritz Henglein, Gabriele Keller, Trevor McDonell, Edward Kmett, Sacha Sokoloski I doubt there is much I could add to such an illustrious list. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com Twitter: @idontgetoutmuch On 25 Mar 2018, at 06:11, Michal J Gajda > wrote: Given that Marco did not confirm, I am just now confirming that we can get you mentored by Mikhail Baikov as the third mentor (beside Dominic and me). Both me (Michal) and Mikhail are performance optimization experts (I am in parsers, and data analytics, Mikhail is in real-time systems, he has his own top-notch serialization library - Beamable that outperforms Cereal in both data size and speed). Dominic is expert in numerical computing (ODEs and Julia, among other things). I believe that with these three excellent mentors you have very good chance to make outstanding contribution. We just make sure that you prep application by 27th deadline. -- Cheers Michal On Sun, Mar 25, 2018 at 6:32 AM Michal J Gajda > wrote: As a mentor I would say it is certainly possible to outperform exsting mega-solutions in some narrow domain. Just as I did with hPDB https://hackage.haskell.org/package/hPDB But it requires a lot of skill and patiece. Please proceed with this project with the current list of mentors. I think me and Dominic have already declared committment. You might also start by making a table of best competing solutions in other. languages, their respective strengths, and ways that we can possibly improve on them! Where do You keep Your application draft? Ideally it should be a shared space where you can add mentors as co-editors. — Cheers Michal On Sun, 25 Mar 2018 at 02:32, > wrote: The list of mentors for this project looks great to me. I am not sure if I can add much other than I think this is a nice project. Perhaps it would be best to get the advice of some of the mentors? For some very simple tests with an ODE solver, I concluded that accelerate can perform at least as well as Julia. It would certainly be very helpful to be able to get Jacobians for ODE solving and for other applications. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com Twitter: @idontgetoutmuch On 24 Mar 2018, at 17:20, Charles Blake > wrote: Thanks for the response Michal, Yes, this did cross my mind - and I wouldn't be expecting to outperform those frameworks in the timeframe available! I assumed that the reason that this project was suggested was perhaps: a) there is some intrinsic value in implementing these algorithms natively in haskell (hence why the 'ad' library was developed in the first place), so that those who want to use parallel automatic differentiation / the machine learning algorithms built on top of it can do so without leaving the haskell ecosystem, and b) because the challenges involved in implementing parallel ad in a purely functional language are a little different to those involved in doing so in OO/imperative languages - so it might be interesting from that angle as well? So perhaps my aim would no be to do something unique, but rather to do something that has already done well in other languages, but has not yet been provided as a haskell library. Does this sound like a reasonable approach or do I need to find a slightly more unique angle? Thanks, Charlie ________________________________ From: Michal J Gajda > Sent: 24 March 2018 16:56:35 To: Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; Charles Blake; haskell-cafe at haskell.org Subject: Re: Accelerating Automatic Differentiation Hi Charlie It certainly looks like exciting project, but the bar is currently placed very high. TensorFlow package not only provides automatic differentiation for whole programs, but also optimizes data processing both on GPU, and reading to achieve large batches. This field has a lot of hot developments, so You would either need to propose something unique to Haskell, or You risk being outclassed by PyTorch and TensorFlow bindings Maybe Dominic suggests something too. Cheers Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: From hexagoxel at hexagoxel.de Sun Mar 25 16:11:43 2018 From: hexagoxel at hexagoxel.de (lennart spitzner) Date: Sun, 25 Mar 2018 18:11:43 +0200 Subject: [Haskell-cafe] [ANN] brittany-0.10.0.0 In-Reply-To: <6a0e1eca-ee47-8a8f-a904-0e52ea7bc248@hexagoxel.de> References: <3cb91c7e-3350-7560-e1de-c3b40ec4765e@hexagoxel.de> <6a0e1eca-ee47-8a8f-a904-0e52ea7bc248@hexagoxel.de> Message-ID: <52bd85d6-50db-7a10-87cc-85f3c2c915bd@hexagoxel.de> Contains one big new feature: - Implement module/exports/imports layouting (thanks to sniperrifle2004) See an example of how modules are layouted at https://github.com/lspitzner/brittany/blob/master/doc/showcases/Module.md or try it in the browser at https://hexagoxel.de/brittany/ further (since 0.9.0.1, which was not announced separately): - Support `TupleSections` (thanks to Matthew Piziak) - One important bugfix: Retain strictness patterns (!/~). This bug was a bit more serious as it did not lead to errors and had the potential to silently change source code. - ~10 other bugfixes and changes to the layouting. See the full changelog at https://hackage.haskell.org/package/brittany-0.10.0.0/changelog. This release does not bring compatibility with ghc-8.4 yet. As a consequence I believe that it will not land in stackage for the time being, so stackage users will either have to be patient or install manually by cloning the github repository (https://github.com/lspitzner/brittany). -- lennart From chneukirchen at gmail.com Sun Mar 25 16:41:51 2018 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 25 Mar 2018 18:41:51 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2018-03-28 @ 19:30 Message-ID: <87605kksz4.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 28 at Cafe Puck at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-mar-2018/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From trevor.mcdonell at gmail.com Sun Mar 25 23:57:53 2018 From: trevor.mcdonell at gmail.com (Trevor McDonell) Date: Sun, 25 Mar 2018 23:57:53 +0000 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: Regarding TensorFlow (and PyTorch, etc), it is important to note that TF is designed specifically for the deep-learning style of machine learning, but automatic differentiation itself is a much more generally useful and finds applications in physics, finance, optimisation... not just machine learning. So, I think there is value in implementing AD from a more general parallel array library like Accelerate. I'm generally happy to add mentors. If you don't want to sign up officially, I'm sure we can just add you to the discussion board / email thread / whatever, and you can still contribute to the discussion. Cheers, -Trev P.S. sorry for not replying sooner, I managed to lock myself out of my office on Friday evening, so didn't have my laptop over the weekend. On Sun, 25 Mar 2018 at 23:42 Charles Blake wrote: > Thanks so much for the feedback - I really appreciate the attention you > guys have given me. My draft proposal can be found here: > https://docs.google.com/document/d/1bJqoqVsW5pvXJmdkfn3EXY1QKEiTXxQkl2BmREAtBsQ/edit?usp=sharing > > If you have the chance to look at it and are interested, any feedback > would be valuable! > > > In terms of mentors for the project, I'm not entirely familiar with the > process involved. I've contacted the mentors originally listed for the > project with a copy of my draft proposal, but of course I appreciate your > input as well and if there is the option of others joining to mentor the > project then that sounds fantastic. > > > Charlie > ------------------------------ > *From:* Michal J Gajda > *Sent:* 25 March 2018 09:08:54 > *To:* dominic at steinitz.org > *Cc:* Charles Blake; Mikhail Baykov; haskell-cafe at haskell.org; > accelerate-haskell at googlegroups.com > > *Subject:* Re: Accelerating Automatic Differentiation > Great! If they all agreed, we can just add Mikhail, and done? > On Sun, 25 Mar 2018 at 15:17, wrote: > > Hi Michal, > > I didn’t volunteer to be a mentor for this. The project already lists: > > *Mentor*: Fritz Henglein, Gabriele Keller, Trevor McDonell, Edward Kmett, > Sacha Sokoloski > > > I doubt there is much I could add to such an illustrious list. > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > Twitter: @idontgetoutmuch > > > > On 25 Mar 2018, at 06:11, Michal J Gajda wrote: > > Given that Marco did not confirm, I am just now confirming that we can get > you mentored by Mikhail Baikov as the third mentor (beside Dominic and me). > Both me (Michal) and Mikhail are performance optimization experts (I am in > parsers, and data analytics, Mikhail is in real-time systems, he has his > own top-notch serialization library - Beamable that outperforms Cereal in > both data size and speed). Dominic is expert in numerical computing (ODEs > and Julia, among other things). > > I believe that with these three excellent mentors you have very good > chance to make outstanding contribution. > We just make sure that you prep application by 27th deadline. > -- > Cheers > Michal > > On Sun, Mar 25, 2018 at 6:32 AM Michal J Gajda > wrote: > > As a mentor I would say it is certainly possible to outperform exsting > mega-solutions in some narrow domain. > Just as I did with hPDB https://hackage.haskell.org/package/hPDB > But it requires a lot of skill and patiece. > > Please proceed with this project with the current list of mentors. > I think me and Dominic have already declared committment. > > You might also start by making a table of best competing solutions in > other. languages, their respective strengths, and ways that we can possibly > improve on them! > > Where do You keep Your application draft? Ideally it should be a shared > space where you can add mentors as co-editors. > — > Cheers > Michal > On Sun, 25 Mar 2018 at 02:32, wrote: > > The list of mentors for this project looks great to me. I am not sure if I > can add much other than I think this is a nice project. Perhaps it would be > best to get the advice of some of the mentors? > > For some very simple tests with an ODE solver, I concluded that accelerate > can perform at least as well as Julia. It would certainly be very helpful > to be able to get Jacobians for ODE solving and for other applications. > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > Twitter: @idontgetoutmuch > > > > On 24 Mar 2018, at 17:20, Charles Blake wrote: > > Thanks for the response Michal, > > Yes, this did cross my mind - and I wouldn't be expecting to outperform > those frameworks in the timeframe available! I assumed that the reason that > this project was suggested was perhaps: > > a) there is some intrinsic value in implementing these algorithms natively > in haskell (hence why the 'ad' library was developed in the first place), > so that those who want to use parallel automatic differentiation / the > machine learning algorithms built on top of it can do so without leaving > the haskell ecosystem, > > and b) because the challenges involved in implementing parallel ad in a > purely functional language are a little different to those involved in > doing so in OO/imperative languages - so it might be interesting from that > angle as well? > > So perhaps my aim would no be to do something unique, but rather to do > something that has already done well in other languages, but has not yet > been provided as a haskell library. Does this sound like a reasonable > approach or do I need to find a slightly more unique angle? > > Thanks, > Charlie > > ------------------------------ > *From:* Michal J Gajda > *Sent:* 24 March 2018 16:56:35 > *To:* Dominic Steinitz; Marco Zocca; accelerate-haskell at googlegroups.com; > Charles Blake; haskell-cafe at haskell.org > *Subject:* Re: Accelerating Automatic Differentiation > > > Hi Charlie > > It certainly looks like exciting project, but the bar is currently placed > very high. > TensorFlow package not only provides automatic differentiation for whole > programs, but also optimizes data processing both on GPU, and reading to > achieve large batches. > This field has a lot of hot developments, so You would either need to > propose something unique to Haskell, or You risk being outclassed by > PyTorch and TensorFlow bindings > Maybe Dominic suggests something too. > Cheers > Michal > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 trevor.mcdonell at gmail.com Mon Mar 26 01:22:20 2018 From: trevor.mcdonell at gmail.com (Trevor McDonell) Date: Mon, 26 Mar 2018 01:22:20 +0000 Subject: [Haskell-cafe] GSoC Project Introduction: Accelerate Automatic Differentiation In-Reply-To: References: Message-ID: Just to follow up, we have gotten in contact with Charlie directly. Cheers, -Trev On Sat, 24 Mar 2018 at 02:59 Charles Blake wrote: > Dear all, > > > I'm a student interested in the GSoC programme and I wanted to introduce > myself and make contact with those involved in potentially mentoring for > the 'Implementing Automatic Differentiation in Accelerate' project ( > https://summer.haskell.org/ideas.html#accelerate-automatic-differentiation). > If it would be more appropriate for me to contact those individuals > directly then please let me know. > > > My name is Charlie Blake, and I'm currently coming to the end of my CS > undergrad degree. Much of my study of late has been focused on functional > programming and parallelism - so when I saw this project proposal it jumped > out at me! I was expecting to be assisting research at my university (St > Andrews University, Scotland) in this field over the summer, but this > arrangement has recently fallen through. Hence why I'm unfortunately > sending this message rather close to the deadline. Nevertheless, I'm now > hoping very much to get on the GSoC program, to which I am very much > committed. > > > With regards to the project itself, I'm currently in the process of > drawing up a proposal. Although I'm making every effort to read as much as > I can about the 'ad' and 'accelerate' libraries, it's still quite hard to > get a good sense of the scope of the project. Would, for instance, it be a > reasonable goal to expect to be able to implement all of the core 'ad' > functionality in my own parallel library in the time-frame? This seems like > the natural objective, but I don't want to propose an unrealistically large > project if this is not feasible. If anyone has answers to these questions > and might further be willing to discuss a draft project proposal with me > over the next few days that would be greatly appreciated. > > > Many thanks, > > Charlie Blake > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 alois.cochard at gmail.com Mon Mar 26 12:05:39 2018 From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=) Date: Mon, 26 Mar 2018 14:05:39 +0200 Subject: [Haskell-cafe] GSoC Mentoring/Voting Message-ID: Hi all, I'm a bit confuse about the process regarding voting on GSoC proposals and proposing as mentor. I receive email from Google that seems to talk about a UI that I have never seen (i.e. they speak about some purple button "I want to be mentor"), OTOH there is this GitHub repository where it seems people contributed proposals. It seems like tomorrow is the deadline for the proposal, so I'm curious what will be the next steps for potential mentor as it seems we diverged a bit from the "official Google way". Thanks for the help. -- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Mon Mar 26 12:15:25 2018 From: alois.cochard at gmail.com (=?UTF-8?Q?Alo=C3=AFs_Cochard?=) Date: Mon, 26 Mar 2018 14:15:25 +0200 Subject: [Haskell-cafe] GSoC Mentoring/Voting In-Reply-To: References: Message-ID: So to answer my own question: One can access the "dashboard" as mentor and access all the Google UI: https://summerofcode.withgoogle.com/dashboard/ Sorry I missed this initially! On 26 March 2018 at 14:05, Aloïs Cochard wrote: > Hi all, > > I'm a bit confuse about the process regarding voting on GSoC proposals and > proposing as mentor. > > I receive email from Google that seems to talk about a UI that I have > never seen (i.e. they speak about some purple button "I want to be > mentor"), OTOH there is this GitHub repository where it seems people > contributed proposals. > > It seems like tomorrow is the deadline for the proposal, so I'm curious > what will be the next steps for potential mentor as it seems we diverged a > bit from the "official Google way". > > Thanks for the help. > > -- > *Λ\oïs* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > -- *Λ\oïs* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai.maruseac at gmail.com Mon Mar 26 14:04:53 2018 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Mon, 26 Mar 2018 07:04:53 -0700 Subject: [Haskell-cafe] [Call for Contributions] Haskell Communities and Activities Report, May 2018 edition (34th edition) Message-ID: Dear all, We would like to collect contributions for the 34th edition of the ============================================================ Haskell Communities & Activities Report http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report Submission deadline: 30 April 2018 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format, both are equally accepted) ============================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough --- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell us, so that we can contact the project leaders and ask them to submit an entry. * If you are working on a project that is looking for contributors, please write a short entry and submit it, mentioning that your are looking for contributors. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the previous edition --- you will find interesting projects described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Mihai Maruseac FAQ: Q: What format should I write in? A: The usual format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2017/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2017/hcar.sty that you can use to preview your entry. If you do not know LaTeX or don't want to use it or don't have time to translate your entry into it, then please use plain text, it is better to have an entry in plain-text which we will translate than not have it at all. If you modify an old entry that you have written for an earlier edition of the report, you should soon receive your old entry as a template (provided we have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include Haskell code? A: Yes. Please use lhs2tex syntax (http://www.andres-loeh.de/lhs2tex/). The report is compiled in mode polycode.fmt. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg or .png format, then. PNG is preferred for simplicity. Q: Should I send files in .zip archives or similar? A: No, plain file attachments are the way. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or "historic" overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also simply ask us. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use HCAR to ask for more contributors to your project, it is a good way to gain visibility and traction. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell us that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them. Q: Will I get confirmation if I send an entry? How do I know whether my email has even reached its destination, and not ended up in a spam folder? A: Prior to publication of the final report, we will send a draft to all contributors, for possible corrections. So if you do not hear from us within two weeks after the deadline, it is safer to send another mail and check whether your first one was received. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From evan at evanrutledgeborden.dreamhosters.com Wed Mar 28 19:46:09 2018 From: evan at evanrutledgeborden.dreamhosters.com (evan@evan-borden.com) Date: Wed, 28 Mar 2018 15:46:09 -0400 Subject: [Haskell-cafe] ANN: network-2.6.3.5 Message-ID: Announcing network-2.6.3.5 * Reverting "Do not closeFd within sendFd" [#271](https://github.com/haskell/network/pull/271) Sorry for any disruption this versioning snafu may have caused. https://hackage.haskell.org/package/network-2.6.3.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Thu Mar 29 05:09:12 2018 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Thu, 29 Mar 2018 13:09:12 +0800 Subject: [Haskell-cafe] Minimizing cascading rebuilds Message-ID: Hi, In my project, I have multiple packages. One of the packages, packageA, is very fundamental and depended on directly and indirectly by almost all the other packages. It has functions that use some hard-coded data (a ByteString top-level variable) also defined within packageA. This hard-coded data is appended regularly, causing packageA to be rebuilt and thus almost all the other packages to be rebuilt, and building takes a painfully long time. I know I can move this hard-coded data to a file that's read at run-time, but that means one more item to plumb in at run-time (where to find the file), and IO (preventing the functions from being pure), so I would like to keep it hard-coded. Is there an elegant way to prevent or minimize the cascading rebuild of the dependent packages just because the hard-coded data in packageA changed? For analogy, in C or C++, source code gets compiled to .o files, one for each .cpp source file. Multiple .o files get linked into executables. So, unless the interface (.hpp files) also change, an implementation (.cpp file) change does not cause dependents to be recompiled to get new .o files, although dependent executables get relinked. I'm not familiar with the compilation and linking logic in GHC so maybe it has additional complications. BTW, I'm using stack, in case it makes any difference to the nature of the problem. Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Thu Mar 29 05:25:20 2018 From: danburton.email at gmail.com (Dan Burton) Date: Thu, 29 Mar 2018 05:25:20 +0000 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: I don't believe this is currently possible with ghc, due to the way ghc handles optimizations. I would love to be proven wrong on that. On Wed, Mar 28, 2018, 22:11 ☂Josh Chia (謝任中) wrote: > Hi, > > In my project, I have multiple packages. One of the packages, packageA, is > very fundamental and depended on directly and indirectly by almost all the > other packages. It has functions that use some hard-coded data (a > ByteString top-level variable) also defined within packageA. > > This hard-coded data is appended regularly, causing packageA to be rebuilt > and thus almost all the other packages to be rebuilt, and building takes a > painfully long time. I know I can move this hard-coded data to a file > that's read at run-time, but that means one more item to plumb in at > run-time (where to find the file), and IO (preventing the functions from > being pure), so I would like to keep it hard-coded. > > Is there an elegant way to prevent or minimize the cascading rebuild of > the dependent packages just because the hard-coded data in packageA changed? > > For analogy, in C or C++, source code gets compiled to .o files, one for > each .cpp source file. Multiple .o files get linked into executables. So, > unless the interface (.hpp files) also change, an implementation (.cpp > file) change does not cause dependents to be recompiled to get new .o > files, although dependent executables get relinked. I'm not familiar with > the compilation and linking logic in GHC so maybe it has additional > complications. > > BTW, I'm using stack, in case it makes any difference to the nature of the > problem. > > Josh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Mar 29 05:27:22 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 29 Mar 2018 01:27:22 -0400 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: The logic has *lots* of additional complications; Haskell isn't C. https://wiki.haskell.org/Shared_libraries_and_GHC isn't quite about this (shared libraries have even more complications), but has a reasonable overview. Hypothetically, this specific case *could* be handled better. But it doesn't come up often enough, and the whole thing is tangled enough that it's only very recently that ghc's dependency handling started to play along well with nix's idea of how things work, much less anything trickier. Although this might be one of the rare cases where -split-objs could be worth the cost (-split-sections is generally preferred with recent ghc, but wouldn't help with this specific case). On Thu, Mar 29, 2018 at 1:09 AM, ☂Josh Chia (謝任中) wrote: > Hi, > > In my project, I have multiple packages. One of the packages, packageA, is > very fundamental and depended on directly and indirectly by almost all the > other packages. It has functions that use some hard-coded data (a > ByteString top-level variable) also defined within packageA. > > This hard-coded data is appended regularly, causing packageA to be rebuilt > and thus almost all the other packages to be rebuilt, and building takes a > painfully long time. I know I can move this hard-coded data to a file > that's read at run-time, but that means one more item to plumb in at > run-time (where to find the file), and IO (preventing the functions from > being pure), so I would like to keep it hard-coded. > > Is there an elegant way to prevent or minimize the cascading rebuild of > the dependent packages just because the hard-coded data in packageA changed? > > For analogy, in C or C++, source code gets compiled to .o files, one for > each .cpp source file. Multiple .o files get linked into executables. So, > unless the interface (.hpp files) also change, an implementation (.cpp > file) change does not cause dependents to be recompiled to get new .o > files, although dependent executables get relinked. I'm not familiar with > the compilation and linking logic in GHC so maybe it has additional > complications. > > BTW, I'm using stack, in case it makes any difference to the nature of the > problem. > > Josh > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu Mar 29 05:29:07 2018 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 29 Mar 2018 01:29:07 -0400 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: Optimizations shouldn't matter here: the problems there are caused by inlining, and if this data were short enough to get inlined then it also wouldn't be causing problems. Although I should note that ByteString "literals" aren't actually literals in the way the OP thinks, and this will also cause problems. The external data file is actually preferable for this reason. On Thu, Mar 29, 2018 at 1:25 AM, Dan Burton wrote: > I don't believe this is currently possible with ghc, due to the way ghc > handles optimizations. I would love to be proven wrong on that. > > On Wed, Mar 28, 2018, 22:11 ☂Josh Chia (謝任中) wrote: > >> Hi, >> >> In my project, I have multiple packages. One of the packages, packageA, >> is very fundamental and depended on directly and indirectly by almost all >> the other packages. It has functions that use some hard-coded data (a >> ByteString top-level variable) also defined within packageA. >> >> This hard-coded data is appended regularly, causing packageA to be >> rebuilt and thus almost all the other packages to be rebuilt, and building >> takes a painfully long time. I know I can move this hard-coded data to a >> file that's read at run-time, but that means one more item to plumb in at >> run-time (where to find the file), and IO (preventing the functions from >> being pure), so I would like to keep it hard-coded. >> >> Is there an elegant way to prevent or minimize the cascading rebuild of >> the dependent packages just because the hard-coded data in packageA changed? >> >> For analogy, in C or C++, source code gets compiled to .o files, one for >> each .cpp source file. Multiple .o files get linked into executables. So, >> unless the interface (.hpp files) also change, an implementation (.cpp >> file) change does not cause dependents to be recompiled to get new .o >> files, although dependent executables get relinked. I'm not familiar with >> the compilation and linking logic in GHC so maybe it has additional >> complications. >> >> BTW, I'm using stack, in case it makes any difference to the nature of >> the problem. >> >> Josh >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Thu Mar 29 05:40:41 2018 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Thu, 29 Mar 2018 05:40:41 +0000 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: (sorry for duplicate, failed to reply to list) Haskell is going to be unwieldy if you try to code in a non-functional style! Your data, however static, should be passed as an argument to functions that need it. In this case, "as an argument" should probably be read as "with the Reader monad." If you want to avoid loading via IO, you can still put your data set in a separate package. It will depend on packageA to define the data type, but nothing but your final executable has to depend on it -- in fact, it can probably live in the executable's source tree. Put all of your logic that depends on that data (directly or indirectly) in a Reader, and invoke it at the top level. Once you've got that down, it's very much worth reading up on transformers and mtl. I'd also suggest looking at the Rio[1] prelude (currently not quite to a stable release, but will be inside the month) which is built around encouraging current best practices. Once you know the tools, this style becomes convenient, extremely versatile, and helps avoid unnecessary dependencies all over the place. [1] https://github.com/commercialhaskell/rio On Wed, Mar 28, 2018, 10:11 PM ☂Josh Chia (謝任中) wrote: > Hi, > > In my project, I have multiple packages. One of the packages, packageA, is > very fundamental and depended on directly and indirectly by almost all the > other packages. It has functions that use some hard-coded data (a > ByteString top-level variable) also defined within packageA. > > This hard-coded data is appended regularly, causing packageA to be rebuilt > and thus almost all the other packages to be rebuilt, and building takes a > painfully long time. I know I can move this hard-coded data to a file > that's read at run-time, but that means one more item to plumb in at > run-time (where to find the file), and IO (preventing the functions from > being pure), so I would like to keep it hard-coded. > > Is there an elegant way to prevent or minimize the cascading rebuild of > the dependent packages just because the hard-coded data in packageA changed? > > For analogy, in C or C++, source code gets compiled to .o files, one for > each .cpp source file. Multiple .o files get linked into executables. So, > unless the interface (.hpp files) also change, an implementation (.cpp > file) change does not cause dependents to be recompiled to get new .o > files, although dependent executables get relinked. I'm not familiar with > the compilation and linking logic in GHC so maybe it has additional > complications. > > BTW, I'm using stack, in case it makes any difference to the nature of the > problem. > > Josh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noteed at gmail.com Thu Mar 29 05:54:20 2018 From: noteed at gmail.com (Vo Minh Thu) Date: Thu, 29 Mar 2018 07:54:20 +0200 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: Hi, Maybe that switching to another linker can help, e.g. gold or the llvm one. Cheers, Thu Le 29 mars 2018 07:43, "Theodore Lief Gannon" a écrit : > (sorry for duplicate, failed to reply to list) > > Haskell is going to be unwieldy if you try to code in a non-functional > style! Your data, however static, should be passed as an argument to > functions that need it. In this case, "as an argument" should probably be > read as "with the Reader monad." > > If you want to avoid loading via IO, you can still put your data set in a > separate package. It will depend on packageA to define the data type, but > nothing but your final executable has to depend on it -- in fact, it can > probably live in the executable's source tree. Put all of your logic that > depends on that data (directly or indirectly) in a Reader, and invoke it at > the top level. > > Once you've got that down, it's very much worth reading up on transformers > and mtl. I'd also suggest looking at the Rio[1] prelude (currently not > quite to a stable release, but will be inside the month) which is built > around encouraging current best practices. Once you know the tools, this > style becomes convenient, extremely versatile, and helps avoid unnecessary > dependencies all over the place. > > [1] https://github.com/commercialhaskell/rio > > On Wed, Mar 28, 2018, 10:11 PM ☂Josh Chia (謝任中) > wrote: > >> Hi, >> >> In my project, I have multiple packages. One of the packages, packageA, >> is very fundamental and depended on directly and indirectly by almost all >> the other packages. It has functions that use some hard-coded data (a >> ByteString top-level variable) also defined within packageA. >> >> This hard-coded data is appended regularly, causing packageA to be >> rebuilt and thus almost all the other packages to be rebuilt, and building >> takes a painfully long time. I know I can move this hard-coded data to a >> file that's read at run-time, but that means one more item to plumb in at >> run-time (where to find the file), and IO (preventing the functions from >> being pure), so I would like to keep it hard-coded. >> >> Is there an elegant way to prevent or minimize the cascading rebuild of >> the dependent packages just because the hard-coded data in packageA changed? >> >> For analogy, in C or C++, source code gets compiled to .o files, one for >> each .cpp source file. Multiple .o files get linked into executables. So, >> unless the interface (.hpp files) also change, an implementation (.cpp >> file) change does not cause dependents to be recompiled to get new .o >> files, although dependent executables get relinked. I'm not familiar with >> the compilation and linking logic in GHC so maybe it has additional >> complications. >> >> BTW, I'm using stack, in case it makes any difference to the nature of >> the problem. >> >> Josh >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rahulmutt at gmail.com Thu Mar 29 06:14:47 2018 From: rahulmutt at gmail.com (Rahul Muttineni) Date: Thu, 29 Mar 2018 11:44:47 +0530 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: Hi Josh, I just tried a quick experiment with stack resolver lts-11.2 and I'd like to share the results as there are interesting: 1. Consider the following module setup that's a simplified version of your situation Dependencies: - Main depends on Hi - Hi depends on Hum - Hee depends on Hum Main.hs: ``` module Main where import Hi import Hee main :: IO () main = print $ hi ++ hee ++ "!" ``` Hee.hs: ``` module Hee (hee) where import Hum (hum) hee :: String hee = "hee1" ++ hum ``` Hi.hs ``` module Hi (hi) where import Hum (hum) hi :: String hi = "hi1" ++ hum ``` Hum.hs ``` module Hum (hum) where hum :: String hum = "hum" ``` 2. Now build it once with `stack build`. 3. Now change "hum" to "hum1" and run `stack build` notice that all 4 modules will recompile. 4. Now add {-# NOINLINE hum #-} just above hum :: String and run `stack build` 5. Change hum again and run `stack build`. 6. Only Hum will recompile! Lesson: Add NOINLINE to any function/value that you change frequently and don't want to trigger massive recompilations. This does come at a performace tradeoff since GHC will not be able to inline whatever you added that pragma to, but your compile-time will be saved. In your case of hard-coded data, I think you won't be able to measure any performance penalty. Hope that helps, Rahul On Thu, Mar 29, 2018 at 10:39 AM, ☂Josh Chia (謝任中) wrote: > Hi, > > In my project, I have multiple packages. One of the packages, packageA, is > very fundamental and depended on directly and indirectly by almost all the > other packages. It has functions that use some hard-coded data (a > ByteString top-level variable) also defined within packageA. > > This hard-coded data is appended regularly, causing packageA to be rebuilt > and thus almost all the other packages to be rebuilt, and building takes a > painfully long time. I know I can move this hard-coded data to a file > that's read at run-time, but that means one more item to plumb in at > run-time (where to find the file), and IO (preventing the functions from > being pure), so I would like to keep it hard-coded. > > Is there an elegant way to prevent or minimize the cascading rebuild of > the dependent packages just because the hard-coded data in packageA changed? > > For analogy, in C or C++, source code gets compiled to .o files, one for > each .cpp source file. Multiple .o files get linked into executables. So, > unless the interface (.hpp files) also change, an implementation (.cpp > file) change does not cause dependents to be recompiled to get new .o > files, although dependent executables get relinked. I'm not familiar with > the compilation and linking logic in GHC so maybe it has additional > complications. > > BTW, I'm using stack, in case it makes any difference to the nature of the > problem. > > Josh > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Rahul Muttineni -------------- next part -------------- An HTML attachment was scrubbed... URL: From 6yearold at gmail.com Thu Mar 29 07:05:17 2018 From: 6yearold at gmail.com (Gleb Popov) Date: Thu, 29 Mar 2018 10:05:17 +0300 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: On Thu, Mar 29, 2018 at 8:09 AM, ☂Josh Chia (謝任中) wrote: > Hi, > > In my project, I have multiple packages. One of the packages, packageA, is > very fundamental and depended on directly and indirectly by almost all the > other packages. It has functions that use some hard-coded data (a > ByteString top-level variable) also defined within packageA. > > This hard-coded data is appended regularly, causing packageA to be rebuilt > and thus almost all the other packages to be rebuilt, and building takes a > painfully long time. I know I can move this hard-coded data to a file > that's read at run-time, but that means one more item to plumb in at > run-time (where to find the file), and IO (preventing the functions from > being pure), so I would like to keep it hard-coded. > > Is there an elegant way to prevent or minimize the cascading rebuild of > the dependent packages just because the hard-coded data in packageA changed? > > For analogy, in C or C++, source code gets compiled to .o files, one for > each .cpp source file. Multiple .o files get linked into executables. So, > unless the interface (.hpp files) also change, an implementation (.cpp > file) change does not cause dependents to be recompiled to get new .o > files, although dependent executables get relinked. I'm not familiar with > the compilation and linking logic in GHC so maybe it has additional > complications. > > BTW, I'm using stack, in case it makes any difference to the nature of the > problem. > > Josh > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > Since you mentioned C++, why just not use preprocessor? For "developer" builds you can use a runtime file and for "release" ones - embedded file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshchia at gmail.com Thu Mar 29 16:31:14 2018 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Fri, 30 Mar 2018 00:31:14 +0800 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: Rahul's idea works within a package to prevent cascading builds of modules, but when the base package needs to be rebuilt, it is unregistered first as are its direct and indirect dependents, so unfortunately the idea works on an intra-package level but not an inter-package level. Regarding Gleb's comment, isn't this CPP distinction between embedded and external file going to affect a lot of code including their function signatures? (One version takes a filename for the data file and does IO and another version doesn't) Sounds hard to maintain. On Thu, Mar 29, 2018 at 2:14 PM, Rahul Muttineni wrote: > Hi Josh, > > I just tried a quick experiment with stack resolver lts-11.2 and I'd like > to share the results as there are interesting: > > 1. Consider the following module setup that's a simplified version of your > situation > Dependencies: > - Main depends on Hi > - Hi depends on Hum > - Hee depends on Hum > > Main.hs: > ``` > module Main where > > import Hi > import Hee > > main :: IO () > main = print $ hi ++ hee ++ "!" > ``` > > Hee.hs: > ``` > module Hee (hee) where > > import Hum (hum) > > hee :: String > hee = "hee1" ++ hum > ``` > > Hi.hs > ``` > module Hi (hi) where > > import Hum (hum) > > hi :: String > hi = "hi1" ++ hum > ``` > > Hum.hs > ``` > module Hum (hum) where > > hum :: String > hum = "hum" > ``` > > 2. Now build it once with `stack build`. > 3. Now change "hum" to "hum1" and run `stack build` notice that all 4 > modules will recompile. > 4. Now add {-# NOINLINE hum #-} just above hum :: String and run `stack > build` > 5. Change hum again and run `stack build`. > 6. Only Hum will recompile! > > Lesson: Add NOINLINE to any function/value that you change frequently and > don't want to trigger massive recompilations. This does come at a > performace tradeoff since GHC will not be able to inline whatever you added > that pragma to, but your compile-time will be saved. In your case of > hard-coded data, I think you won't be able to measure any performance > penalty. > > Hope that helps, > Rahul > > > On Thu, Mar 29, 2018 at 10:39 AM, ☂Josh Chia (謝任中) > wrote: > >> Hi, >> >> In my project, I have multiple packages. One of the packages, packageA, >> is very fundamental and depended on directly and indirectly by almost all >> the other packages. It has functions that use some hard-coded data (a >> ByteString top-level variable) also defined within packageA. >> >> This hard-coded data is appended regularly, causing packageA to be >> rebuilt and thus almost all the other packages to be rebuilt, and building >> takes a painfully long time. I know I can move this hard-coded data to a >> file that's read at run-time, but that means one more item to plumb in at >> run-time (where to find the file), and IO (preventing the functions from >> being pure), so I would like to keep it hard-coded. >> >> Is there an elegant way to prevent or minimize the cascading rebuild of >> the dependent packages just because the hard-coded data in packageA changed? >> >> For analogy, in C or C++, source code gets compiled to .o files, one for >> each .cpp source file. Multiple .o files get linked into executables. So, >> unless the interface (.hpp files) also change, an implementation (.cpp >> file) change does not cause dependents to be recompiled to get new .o >> files, although dependent executables get relinked. I'm not familiar with >> the compilation and linking logic in GHC so maybe it has additional >> complications. >> >> BTW, I'm using stack, in case it makes any difference to the nature of >> the problem. >> >> Josh >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > -- > Rahul Muttineni > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 6yearold at gmail.com Thu Mar 29 17:55:11 2018 From: 6yearold at gmail.com (Gleb Popov) Date: Thu, 29 Mar 2018 20:55:11 +0300 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: On Thu, Mar 29, 2018 at 7:31 PM, ☂Josh Chia (謝任中) wrote: > Rahul's idea works within a package to prevent cascading builds of > modules, but when the base package needs to be rebuilt, it is unregistered > first as are its direct and indirect dependents, so unfortunately the idea > works on an intra-package level but not an inter-package level. > > Regarding Gleb's comment, isn't this CPP distinction between embedded and > external file going to affect a lot of code including their function > signatures? (One version takes a filename for the data file and does IO and > another version doesn't) Sounds hard to maintain. > Well, you can wrap your data in IO: #ifdef DEVEL_BUILD constantData' :: ByteString constantData' = $(embedFile "blabla") constantData :: IO ByteString constantData = return constantData ' #else constantData :: IO ByteString constantData = readFile "blabla" #endif > On Thu, Mar 29, 2018 at 2:14 PM, Rahul Muttineni > wrote: > >> Hi Josh, >> >> I just tried a quick experiment with stack resolver lts-11.2 and I'd like >> to share the results as there are interesting: >> >> 1. Consider the following module setup that's a simplified version of >> your situation >> Dependencies: >> - Main depends on Hi >> - Hi depends on Hum >> - Hee depends on Hum >> >> Main.hs: >> ``` >> module Main where >> >> import Hi >> import Hee >> >> main :: IO () >> main = print $ hi ++ hee ++ "!" >> ``` >> >> Hee.hs: >> ``` >> module Hee (hee) where >> >> import Hum (hum) >> >> hee :: String >> hee = "hee1" ++ hum >> ``` >> >> Hi.hs >> ``` >> module Hi (hi) where >> >> import Hum (hum) >> >> hi :: String >> hi = "hi1" ++ hum >> ``` >> >> Hum.hs >> ``` >> module Hum (hum) where >> >> hum :: String >> hum = "hum" >> ``` >> >> 2. Now build it once with `stack build`. >> 3. Now change "hum" to "hum1" and run `stack build` notice that all 4 >> modules will recompile. >> 4. Now add {-# NOINLINE hum #-} just above hum :: String and run `stack >> build` >> 5. Change hum again and run `stack build`. >> 6. Only Hum will recompile! >> >> Lesson: Add NOINLINE to any function/value that you change frequently and >> don't want to trigger massive recompilations. This does come at a >> performace tradeoff since GHC will not be able to inline whatever you added >> that pragma to, but your compile-time will be saved. In your case of >> hard-coded data, I think you won't be able to measure any performance >> penalty. >> >> Hope that helps, >> Rahul >> >> >> On Thu, Mar 29, 2018 at 10:39 AM, ☂Josh Chia (謝任中) >> wrote: >> >>> Hi, >>> >>> In my project, I have multiple packages. One of the packages, packageA, >>> is very fundamental and depended on directly and indirectly by almost all >>> the other packages. It has functions that use some hard-coded data (a >>> ByteString top-level variable) also defined within packageA. >>> >>> This hard-coded data is appended regularly, causing packageA to be >>> rebuilt and thus almost all the other packages to be rebuilt, and building >>> takes a painfully long time. I know I can move this hard-coded data to a >>> file that's read at run-time, but that means one more item to plumb in at >>> run-time (where to find the file), and IO (preventing the functions from >>> being pure), so I would like to keep it hard-coded. >>> >>> Is there an elegant way to prevent or minimize the cascading rebuild of >>> the dependent packages just because the hard-coded data in packageA changed? >>> >>> For analogy, in C or C++, source code gets compiled to .o files, one for >>> each .cpp source file. Multiple .o files get linked into executables. So, >>> unless the interface (.hpp files) also change, an implementation (.cpp >>> file) change does not cause dependents to be recompiled to get new .o >>> files, although dependent executables get relinked. I'm not familiar with >>> the compilation and linking logic in GHC so maybe it has additional >>> complications. >>> >>> BTW, I'm using stack, in case it makes any difference to the nature of >>> the problem. >>> >>> Josh >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> >> -- >> Rahul Muttineni >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Mar 29 23:41:43 2018 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 30 Mar 2018 00:41:43 +0100 Subject: [Haskell-cafe] Accelerating Automatic Differentiation In-Reply-To: References: <62F12296-C691-413C-A3AA-299D80753DF4@steinitz.org> Message-ID: <20180329234142.GS11174@weber> On Sun, Mar 25, 2018 at 11:57:53PM +0000, Trevor McDonell wrote: > Regarding TensorFlow (and PyTorch, etc), it is important to note that TF is > designed specifically for the deep-learning style of machine learning, but > automatic differentiation itself is a much more generally useful and finds > applications in physics, finance, optimisation... not just machine > learning. It's true that TF and PyTorch are designed for deep learning applications but is there really anything presenting one using them for the other applications you mention? From takenobu.hs at gmail.com Fri Mar 30 12:40:30 2018 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Fri, 30 Mar 2018 21:40:30 +0900 Subject: [Haskell-cafe] Haskell to Ethereum VM ? In-Reply-To: References: <4669e0ee-3f9e-63b4-256b-9d8cfc7178ab@patrickmn.com> <86E95F90581544F3AD24460B5E1B2D1B@gregava> Message-ID: Hi cafe, I implemented a toy code of EVM assembler on Haskell DSL. HAssembly-evm https://github.com/takenobu-hs/haskell-ethereum-assembly Cheers, Takenobu 2018-03-10 11:57 GMT+09:00 Takenobu Tani : > Hi, > > Before exploring Cardano's virtual machine, I explored Ethereum virtual > machine (EVM). > I'm sharing some figures I wrote for my self-study. > > Ethereum EVM illustrated > http://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf > https://github.com/takenobu-hs/ethereum-evm-illustrated > > Haskell fits very well to DApps/Smart contracts :) > > Regards, > Takenobu > > > 2018-01-27 11:27 GMT+09:00 Takenobu Tani : > >> Hi Gregory, >> >> Thank you for much information. >> I have heard Cardano, but I did not know the details. >> >> It's amazing! >> >> Although Ethereum VM is stack based virtual machine, >> Cardano's IELE(VM) is register based VM!, it's powerfull and beautiful! >> In addition, it is protected by semantics. >> >> Umm, High-level safety abstructed language (Haskell based) + register >> based VM (IELE) ! >> It's amazing. >> >> Thank you for telling me details. >> I will explore this. >> >> Thank you very much, >> Takenobu >> >> >> 2018-01-27 10:22 GMT+09:00 Gregory Popovitch : >> >>> Probably you are aware of Cardano (https://www.cardanohub.org/en/home/), >>> a new generation blockchain platform which uses languages inspired from >>> Haskell. From the whitepaper at https://whycardano.com/: >>> >>> "Systems such as Bitcoin provide an extremely inflexible and draconian >>> scripting language that is difficult to program bespoke transactions in, >>> and to read and understand. Yet the general programmability of languages >>> such as Solidity introduce an extraordinary amount of complexity into the >>> system and are useful to only a much smaller set of actors. >>> >>> Therefore, we have chosen to design a new language called Simon6 >>> in honor of its creator Simon >>> Thompson and the creator of the concepts that inspired it, Simon Peyton >>> Jones. Simon is a domain-specific language that is based upon *Composing >>> contracts: an adventure in financial engineering >>> *. >>> >>> The principal idea is that financial transactions are generally composed >>> from a collection of foundational elements7 >>> . If one assembles a financial >>> periodic table of elements, then one can provide support for an arbitrarily >>> large set of compound transactions that will cover most, if not all, common >>> transaction types without requiring general programmability. >>> >>> The primary advantage is that security and execution can be extremely >>> well understood. Proofs can be written to show correctness of templates and >>> exhaust the execution space of problematic transaction events, such as the >>> creation of new money out of thin air >>> or transaction >>> malleability . >>> Second, one can leave in extensions to add more elements by way of soft >>> forks if new functionality is required. >>> >>> That said, there will always be a need to connect CSL to overlay >>> protocols, legacy financial systems, and special purpose servers. Thus we >>> have developed Plutus >>> as both a general >>> purpose smart contract language and also a special purpose DSL for >>> interoperability. >>> >>> Plutus is a typed functional language based on concepts from Haskell, >>> which can be used to write custom transaction scripts. For CSL, it will be >>> used for complex transactions required to add support for other layers we >>> need to connect, such as our sidechains scheme." >>> >>> ------------------------------ >>> *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On >>> Behalf Of *Takenobu Tani >>> *Sent:* Friday, January 26, 2018 8:05 PM >>> *To:* Patrick Mylund Nielsen >>> *Cc:* haskell-cafe >>> *Subject:* Re: [Haskell-cafe] Haskell to Ethereum VM ? >>> >>> Hi Carter, Patrick, >>> >>> Thank you for reply. >>> Quorum is interesting! >>> It would be very nice to be able to describe Ethereum's contract with >>> Haskell DSL. >>> The characteristics about immutable and type will fit DApps. >>> >>> Thank you very much, >>> Takenobu >>> >>> >>> >>> 2018-01-27 2:55 GMT+09:00 Patrick Mylund Nielsen >>> : >>> >>>> The Quorum[1] team has been dreaming about such a >>>> Haskell-beginner-friendly bytecode-generating DSL for a very long time. >>>> The user experience of writing applications in a language where pitfalls >>>> are so non-obvious is one of the biggest pain points of Ethereum in >>>> general. >>>> >>>> We would warmly welcome something like this, and would definitely look >>>> to use it in Quorum. (Our EVM is the same as public Ethereum.) >>>> >>>> [1]: A permissioned/non-PoW version of Ethereum with high throughput and >>>> privacy - https://github.com/jpmorganchase/quorum/ >>>> >>>> On 1/26/2018 11:43 AM, Carter Schonwald wrote: >>>> > Hello Takenobu, >>>> > while theres definitely a lot of haskell code out there that deals >>>> with >>>> > ethereum (or implementing it!), i'm not aware of anything targeting >>>> the >>>> > evm isa from haskell or any other mature functional programming >>>> language >>>> > >>>> > On Fri, Jan 26, 2018 at 8:09 AM, Takenobu Tani >>> > > wrote: >>>> > >>>> > Hi cafe, >>>> > >>>> > Does anyone know about the code generator from Haskell's syntax to >>>> > Ethereum VM language (bytecode)? >>>> > That is, what corresponds to Solidity in Haskell. >>>> > >>>> > Although Solidity is interesting, it's difficult for me to achieve >>>> > quality and safety. >>>> > Does such a project already exist? >>>> > >>>> > Regards, >>>> > Takenobu >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Haskell-Cafe mailing list >>>> > To (un)subscribe, modify options or view 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 rpglover64 at gmail.com Fri Mar 30 15:17:32 2018 From: rpglover64 at gmail.com (Alex Rozenshteyn) Date: Fri, 30 Mar 2018 15:17:32 +0000 Subject: [Haskell-cafe] Minimizing cascading rebuilds In-Reply-To: References: Message-ID: Might this be something backpack can help with? Write an interface file for your data library and actually link it in at your top level application? This doesn't help the total build time, but it helps tighten the feedback loop for the intermediate packages. This is tangentially related to Theodre's suggestion in that your data doesn't get combined in until late in the build. On Thu, Mar 29, 2018 at 10:59 AM Gleb Popov <6yearold at gmail.com> wrote: > On Thu, Mar 29, 2018 at 7:31 PM, ☂Josh Chia (謝任中) > wrote: > >> Rahul's idea works within a package to prevent cascading builds of >> modules, but when the base package needs to be rebuilt, it is unregistered >> first as are its direct and indirect dependents, so unfortunately the idea >> works on an intra-package level but not an inter-package level. >> >> Regarding Gleb's comment, isn't this CPP distinction between embedded and >> external file going to affect a lot of code including their function >> signatures? (One version takes a filename for the data file and does IO and >> another version doesn't) Sounds hard to maintain. >> > > Well, you can wrap your data in IO: > > #ifdef DEVEL_BUILD > constantData' :: ByteString > constantData' = $(embedFile "blabla") > > constantData :: IO ByteString > constantData = return constantData ' > #else > constantData :: IO ByteString > constantData = readFile "blabla" > #endif > > >> On Thu, Mar 29, 2018 at 2:14 PM, Rahul Muttineni >> wrote: >> >>> Hi Josh, >>> >>> I just tried a quick experiment with stack resolver lts-11.2 and I'd >>> like to share the results as there are interesting: >>> >>> 1. Consider the following module setup that's a simplified version of >>> your situation >>> Dependencies: >>> - Main depends on Hi >>> - Hi depends on Hum >>> - Hee depends on Hum >>> >>> Main.hs: >>> ``` >>> module Main where >>> >>> import Hi >>> import Hee >>> >>> main :: IO () >>> main = print $ hi ++ hee ++ "!" >>> ``` >>> >>> Hee.hs: >>> ``` >>> module Hee (hee) where >>> >>> import Hum (hum) >>> >>> hee :: String >>> hee = "hee1" ++ hum >>> ``` >>> >>> Hi.hs >>> ``` >>> module Hi (hi) where >>> >>> import Hum (hum) >>> >>> hi :: String >>> hi = "hi1" ++ hum >>> ``` >>> >>> Hum.hs >>> ``` >>> module Hum (hum) where >>> >>> hum :: String >>> hum = "hum" >>> ``` >>> >>> 2. Now build it once with `stack build`. >>> 3. Now change "hum" to "hum1" and run `stack build` notice that all 4 >>> modules will recompile. >>> 4. Now add {-# NOINLINE hum #-} just above hum :: String and run `stack >>> build` >>> 5. Change hum again and run `stack build`. >>> 6. Only Hum will recompile! >>> >>> Lesson: Add NOINLINE to any function/value that you change frequently >>> and don't want to trigger massive recompilations. This does come at a >>> performace tradeoff since GHC will not be able to inline whatever you added >>> that pragma to, but your compile-time will be saved. In your case of >>> hard-coded data, I think you won't be able to measure any performance >>> penalty. >>> >>> Hope that helps, >>> Rahul >>> >>> >>> On Thu, Mar 29, 2018 at 10:39 AM, ☂Josh Chia (謝任中) >>> wrote: >>> >>>> Hi, >>>> >>>> In my project, I have multiple packages. One of the packages, packageA, >>>> is very fundamental and depended on directly and indirectly by almost all >>>> the other packages. It has functions that use some hard-coded data (a >>>> ByteString top-level variable) also defined within packageA. >>>> >>>> This hard-coded data is appended regularly, causing packageA to be >>>> rebuilt and thus almost all the other packages to be rebuilt, and building >>>> takes a painfully long time. I know I can move this hard-coded data to a >>>> file that's read at run-time, but that means one more item to plumb in at >>>> run-time (where to find the file), and IO (preventing the functions from >>>> being pure), so I would like to keep it hard-coded. >>>> >>>> Is there an elegant way to prevent or minimize the cascading rebuild of >>>> the dependent packages just because the hard-coded data in packageA changed? >>>> >>>> For analogy, in C or C++, source code gets compiled to .o files, one >>>> for each .cpp source file. Multiple .o files get linked into executables. >>>> So, unless the interface (.hpp files) also change, an implementation (.cpp >>>> file) change does not cause dependents to be recompiled to get new .o >>>> files, although dependent executables get relinked. I'm not familiar with >>>> the compilation and linking logic in GHC so maybe it has additional >>>> complications. >>>> >>>> BTW, I'm using stack, in case it makes any difference to the nature of >>>> the problem. >>>> >>>> Josh >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>>> >>> >>> >>> >>> -- >>> Rahul Muttineni >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Sat Mar 31 18:22:36 2018 From: simon at joyful.com (Simon Michael) Date: Sat, 31 Mar 2018 19:22:36 +0100 Subject: [Haskell-cafe] ANN: hledger 1.9 Message-ID: I'm pleased to announce hledger 1.9. The version jump signals some noteworthy changes still landing (normal-positive reports, budget reporting) which are a kind of preview of 2.0. The next major release, on 2018/06/30, will be hledger 2.0. Thank you to release contributors: Eli Flanagan, Peter Simons, Christoph Nicolai, agander, M Parker, Moritz Kiefer, Mykola Orliuk. hledger (http://hledger.org) is a reliable, cross-platform program for tracking money, time or other commodities, using double-entry accounting and simple plain text file formats. It provides command-line, curses and web interfaces, and aims to be a pleasant and practical tool for personal, business or institutional use. What's new ? ------------ Some highlights: * the "financial statement" commands bs/bse/cf/is now show all normal balances as positive numbers, producing more conventional financial reports which are easier to share with others. (experimental) * bal/bs/bse/cf/is can now generate HTML reports * account codes can be used to customize account sorting * numbers in scientific E-notation are supported, eg in journal and CSV data * budget report improvements * general report cleanups More at http://hledger.org/release-notes#hledger-1.9 . Get started ----------- See http://hledger.org/download for all install methods. Often, to get the latest release you will need to build it. Here are some ways to do that: Using the hledger-install script, which requires only bash and will build and install the hledger tools in $HOME/.local/bin/. (Note: building haskell apps can take significant time, memory, and disk space, especially the first time. You can kill and restart the installer without losing progress. If it fails, please help us improve it by reporting the full output): $ curl -O https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh $ less hledger-install.sh # (do security review) $ bash hledger-install.sh # (add -v for more detail; use bash -x to show commands being run) Using hledger-install the more convenient, less secure way: $ curl https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh | bash Using stack: $ stack install hledger-lib-1.9 hledger-1.9 # hledger-ui-1.9 hledger-web-1.9 hledger-api-1.9 Using cabal: $ cabal update $ cabal install hledger-1.9 # hledger-ui-1.9 hledger-web-1.9 hledger-api-1.9 After installation, ensure $HOME/.local/bin is in your $PATH. Now try some commands: $ hledger -h # quick help $ hledger help # list built-in manuals $ hledger add # record some transactions $ hledger # list available commands Now perhaps work through the tutorial at http://hledger.org/step-by-step.html Or review the fine documents, presentations etc. at http://hledger.org and http://plaintextaccounting.org Or say hello and ask questions in the #hledger IRC channel on Freenode: http://irc.hledger.org New users and contributors are always welcome! Give feedback, report bugs, send pull requests, write about it, etc. And if you have been finding hledger useful, consider becoming a sponsor or donor to help to sustain and accelerate our progress (see home page). Our IRC channel is #hledger on Freenode (http://irc.hledger.org).