From anthony_clayden at clear.net.nz Thu Jun 1 02:23:54 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Thu, 01 Jun 2017 14:23:54 +1200 Subject: [Haskell-cafe] Type-level GCD [Instance Chains] Message-ID: <592f7aba.39a.18cb.5752@clear.net.nz> > On Wed May 31 14:19:55 UTC 2017, J. Garrett Morris wrote: > [Apologies for breaking threading...] Thanks Garrett, my email client does horribler things to threading. Since the O.P. was about the aesthetics/readibility of code, I'm surprised you elided all the code. (I suppose de gustibus non disputandum.) >> On Wed May 31, Anthony Clayden wrote: >> Leaving aside the question of backtracking >> on instance non-match, >> would anybody write a type-level GCD like this? >Your question seems to be "would you use > the standard recursive statement of > Euclid's algorithm to demonstrate Euclid's algorithm?" > This certainly seemed to be a reasonable idea in 2010. I think the code I posted was using Euclid's algorithm. I agree it's difficult to cast one's mind back to what was reasonable Haskell in 2010, but I didn't use Type Families. > If your concern is efficiency, .. No, my concern is readability. >> (And Subt needs a nasty kludge in case you're trying to >> subtract the larger: it returns Z.) > What you call a nasty kludge, I call a standard operation > on commutative monoids. [https://en.wikipedia.org/wiki/Monus] Well, OK sometimes the kludge is justified ;-). Not for GCD, methinks. Because the equation guards specifically avoid the need. >> I think these days (esp with TypeFamilies/Assoc types), > You seem to be discovering that closed instance chains > can be implemented by writing out truth tables. I must admit I hadn't though of stand-alone instances as being like rows in truth tables. They're like separate lines of equations, each guarded by a condition. (In math, typically the condition is trailing with comma sep.) OK I'll mirror that style below. > I discussed this transformation at length, > and suggested that doing might make your code > harder to write and to read, ... Ok, let's see. Here's the math (adapted from wikipedia): gcd(m, n) = m , if m == n gcd(m, n) = gcd(m - n, n) , if m > n gcd(m, n) = gcd(m, n - m) , if m < n Here's some Haskell (this works in Hugs, just to make sure I'm getting the right vintage) > data Z; data S n > > data LT; data EQ; data GT > data If t > > class Gcd m n p | m n -> p where > -- methods for Gcd go here > > instance (GcdCase m n p (If d), Diff m n d) > => Gcd m n p where -- single 'catch all' instance > -- method definitions > > -- GcdCase instances mirror the Euclid equations > > class GcdCase m n p d | m n d -> p > instance (HTypeCast m p) > => GcdCase m n p (If (EQ, d')) > instance (Gcd d' n p) > => GcdCase m n p (If (GT, d')) > instance (Gcd m d' p) > => GcdCase m n p (If (LT, d')) > > class Diff m n d | m n -> d > instance Diff Z Z (EQ, Z) > instance Diff (S m') Z (GT, S m') > instance Diff Z (S n') (LT, S n') > instance (Diff m' n' d) => Diff (S m') (S n') d > > -- HTypeCast omitted, use standard HList > ... in my Haskell 2015 paper "Variations on Variants". OK, will study. I see that's focussing on Wadler's "expression problem", as does the Instance Chains paper. It's the Swiestra example there I want to get on to. > Of course, you'll have an easier time of it > if you limit yourself to only considering > type-level definitions, and not > the corresponding method definitions. > But doing so rather misses the point > of instance chains. I've used classes throughout the above. So could easily add methods. The idiom (following HList 2004) is some classes are type-level only. So I see no harm making those Type Families in 2017. (Whether they should be Closed TFs vs stand-alone instances is a separate debate.) AntC From jgbm at acm.org Thu Jun 1 09:51:25 2017 From: jgbm at acm.org (J. Garrett Morris) Date: Thu, 1 Jun 2017 10:51:25 +0100 Subject: [Haskell-cafe] Type-level GCD [Instance Chains] In-Reply-To: <592f7aba.39a.18cb.5752@clear.net.nz> References: <592f7aba.39a.18cb.5752@clear.net.nz> Message-ID: On Thu, Jun 1, 2017 at 3:23 AM, Anthony Clayden wrote: > No, my concern is readability. Well, presumably from the readability perspective, the point is that instance chains allow you to express Euclid's algorithm directly, following the mathematical presentation, whereas the alternative requires indirection through auxiliary truth table classes that are both unnecessary in the mathematical presentation and unhelpful to understanding. (The introduction of the SymmetricDifferenceAndAlsoOrdering class simply seems to hammer this point home.) > I must admit I hadn't though of stand-alone instances > as being like rows in truth tables. > They're like separate lines of equations, > each guarded by a condition. I sense a Dijkstra-like argument that we should avoid writing "else" or "otherwise", instead requiring the programmer to operate De Morgan's laws by hand. The tedium of this approach is only amplified when applied to instance chains, as we generally hope for programs to have meanings and thus for instance resolution to be coherent. For example, consider the simple chain: class C t u where f :: t -> u instance C Int Int where f = M else C t u where f = N where M and N are some well-typed Haskell expressions. Now, it is simple to define type equality t == u using functional dependencies, and so (following the discussion in section 7 of the 2010 paper, or section 7.1 of my dissertation) in the instance chains framework these could be written as separate instances. We might hope to get away with just one extra instance: instance C Int Int where f = M instance C t u if t == Int fails where f = N instance C t u if u == Int fails where f = N But note that the latter instances will seem incoherent to the compiler, even if the programmer is convinced they are not. So what we really need is instance C Int Int where f = M instance C t Int if t == Int fails where f = N instance C Int u if u == Int fails where f = N instance C t u if t == Int fails, u == Int fails where f = N And indeed, this set of instances is provably coherent (and is accepted by the prototype Habit compiler). But I hardly think we've made things clearer to the programmer---since we have taken one "intuitive" case and split it into three apparently distinct branches---or made things easier for the compiler--- since we now have four axiom clauses for class C instead of two, and 6 coherence checks instead of none. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca From anthony_clayden at clear.net.nz Thu Jun 1 12:44:32 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 02 Jun 2017 00:44:32 +1200 Subject: [Haskell-cafe] Type-level GCD [Instance Chains] Message-ID: <59300c30.12c.4356.14924@clear.net.nz> > On Thu Jun 1 09:51:25 UTC 2017, J. Garrett Morris wrote: >> On Thu, Jun 1, 2017 at 3:23 AM, Anthony Clayden wrote: >> No, my concern is readability. > Well, presumably from the readability perspective, > the point is that instance chains allow you to express > Euclid's algorithm directly, following the > mathematical presentation, ... What I see in the mathematical presentation, is that each equation is stand-alone, with a guard. I guess we'll just agree to differ on the readability of the Haskell. (What if Euclid had taken up lazy functional programming ..?) >> I must admit I hadn't though of stand-alone instances >> as being like rows in truth tables. >> They're like separate lines of equations, >> each guarded by a condition. > I sense a Dijkstra-like argument that we should avoid writing > "else" or "otherwise", ... If I'm in the company of Dijkstra and Euclid, that's good enough for me. > ... we generally hope for programs to have meanings Yes we do. > and thus for instance resolution to be coherent. I agree the current (under-/non-)specified rules for overlap don't help us reason much about coherence. (But see my post on the cafe last month wrt "Well-behaved instances".) > For example, consider the simple chain: > > class C t u where f :: t -> u > instance C Int Int where > f = M > else C t u where > f = N This is an example where overlap is well-behaved. (Assuming those are the only instances.) > Now, it is simple to define type equality t == u There's a persistent problem for the compiler testing for type equality: the usage sites must have the types grounded. It's often more successful to prove disequality. > using functional dependencies, and so (...) > in the instance chains framework these could be written > as separate instances. This is a case of well-behaved overlap, so they'd work as separate instances anyway. > We might hope to get away with just one extra instance: > instance C Int Int where f = M > instance C t u if t == Int fails where f = N > instance C t u if u == Int fails where f = N > But note that the latter instances will seem incoherent to the compiler, That first most specific instance exhibits 3 type equalities: (t ~ Int. u ~ Int, t ~ u) So there's various ways to slice up the space. I think Instance Guards both have less lexical clutter, and help the compiler see what's coherent: > instance C Int Int where f = M > instance C t t | t /~ Int where f = N > instance C t u | t /~ u where f = N > [4-instance example elided] > ... we have taken one "intuitive" case and split it into > three apparently distinct branches ... I guess what's intuitive will depend on the application. It's difficult to make much claim in the abstract. > ... ---or made things easier for the compiler--- > since we now have four axiom clauses for class C > instead of two, and 6 coherence checks instead of none. The compiler author will love having precise rules for when instances are apart. And being able to check that when compiling the instance (not delay it to the usage site). And needing to validate only each pair of instances; not worry about overlaps of overlaps. I suspect that for the compiler, Instance Chains will be as problematic for type inference as with Closed Type Families: CTFs have a lot of searching under the covers to 'look ahead' for equations that can safely match. AntC From anthony_clayden at clear.net.nz Thu Jun 1 13:01:46 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 02 Jun 2017 01:01:46 +1200 Subject: [Haskell-cafe] Type-level GCD [Instance Chains] Message-ID: <5930103a.3a4.5343.25924@clear.net.nz> > On Thu Jun 1 12:44:32 UTC 2017, Anthony Clayden wrote: >> For example, consider the simple chain: >> >> class C t u where f :: t -> u >> instance C Int Int where >> f = M >> else C t u where >> f = N Ah, silly me. There's a neater way to achieve that. > I think Instance Guards both have less lexical clutter, > and help the compiler see what's coherent: > instance C Int Int where f = M > instance C t u | (t, u) /~ (Int, Int) where f = N AntC From taylor at fausak.me Thu Jun 1 22:20:31 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 01 Jun 2017 17:20:31 -0500 Subject: [Haskell-cafe] Haskell Weekly Message-ID: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some people have expressed interest in receiving my newsletter on this mailing list. Is that something I should set up? If you're curious about Haskell Weekly, please check out the latest issue, which was published today: I've also included issue 57 as plain text here. If you like what you see, head over to and subscribe! --- # Haskell Weekly ## Issue 57 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what’s going on in its community. - Realizing Hackett, a metaprogrammable Haskell > Almost five months ago, I wrote a blog post about my new programming language, Hackett, a fanciful sketch of a programming language from a far-off land with Haskell's type system and Racket's macros. [...] Hackett is not only real, it's working, and you can try it out yourself! - Imperative Haskell > Why don't we do this all the time, when Haskell is at least a serviceable imperative language? Because writing imperative programs is hard! They don't compose as well, have less useful type signatures, and are harder to reason about. Getting away from those things is why we have Haskell to begin with! - A Haskell cross compiler for Android > Finally launching and running the application on the device, we are greeted with "Hello from Haskell". While the utility of this application is certainly questionable it illustrates the essential steps required to build, link and run an Android application calling a native Haskell function. - Smart data with conduits > If you're a programmer now, there's one reality you'd best be getting used to. People expect you to know how to deal with big data. The kind of data that will take a while to process. The kind that will crash your program if you try to bring it all into memory at the same time. - Wire is hiring a Software Backend Developer (Operations) in Berlin, Germany (ad) > Wire is an open source, end-to-end encrypted messenger for personal and business use. For our development center in Berlin we are hiring two Backend Haskell Developers. As Software Developer Backend Operations you will maintain our infrastructure, ensuring that it runs 24/7. Check out our jobs at wire.com/jobs and our open source code on github.com/wireapp. - What we talk about when we talk about types > These dialogues somewhat pedantically dissect what we mean when we say a type is an instance of a type class or a type has an instance of a type class and why. Through the course of conversation, we touch on the nature of types, type constructors, and type classes, which led to us talking about math, set theory and category theory, and what they have to do with types and type classes. - The partial options monoid > Parsing options is not the hardest problem. However, if you do not create a pattern the rest of your team can follow, your program can become a tangled mess of random file reads, environment variable lookups and unpredictable defaulting. The Monoid class is a rock solid abstraction for combining options. - Playing with lens-aeson > That works, but it's far from inspiring. We're declaring a Color data type simply for the purpose of writing a type class instance. But it feels pretty heavyweight to have to declare a data type and make a type class instance for just one use site. ### Packages of the week Several interesting packages were announced this week. Instead of picking one to feature, all four are this week's packages of the week! - double-pendulum-simulation Simulates and renders a double pendulum system. - legion Implements a simple block chain server that synchronizes nodes over the network. - prettyprinter Aims to end the Wadler/Leijen zoo dilemma by being a modern, well-documented pretty printer. - sitepipe Generates static sites with plain values and less magic. From matthewtpickering at gmail.com Thu Jun 1 22:33:37 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 1 Jun 2017 23:33:37 +0100 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> Message-ID: Hi Taylor, Please keep posting this to this list. I think I missed the first 50 editions of your well edited summaries! The plain text version is perfect. Matt On 1 Jun 2017 23:23, "Taylor Fausak" wrote: Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some people have expressed interest in receiving my newsletter on this mailing list. Is that something I should set up? If you're curious about Haskell Weekly, please check out the latest issue, which was published today: I've also included issue 57 as plain text here. If you like what you see, head over to and subscribe! --- # Haskell Weekly ## Issue 57 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what’s going on in its community. - Realizing Hackett, a metaprogrammable Haskell > Almost five months ago, I wrote a blog post about my new programming language, Hackett, a fanciful sketch of a programming language from a far-off land with Haskell's type system and Racket's macros. [...] Hackett is not only real, it's working, and you can try it out yourself! - Imperative Haskell > Why don't we do this all the time, when Haskell is at least a serviceable imperative language? Because writing imperative programs is hard! They don't compose as well, have less useful type signatures, and are harder to reason about. Getting away from those things is why we have Haskell to begin with! - A Haskell cross compiler for Android > Finally launching and running the application on the device, we are greeted with "Hello from Haskell". While the utility of this application is certainly questionable it illustrates the essential steps required to build, link and run an Android application calling a native Haskell function. - Smart data with conduits > If you're a programmer now, there's one reality you'd best be getting used to. People expect you to know how to deal with big data. The kind of data that will take a while to process. The kind that will crash your program if you try to bring it all into memory at the same time. - Wire is hiring a Software Backend Developer (Operations) in Berlin, Germany (ad) > Wire is an open source, end-to-end encrypted messenger for personal and business use. For our development center in Berlin we are hiring two Backend Haskell Developers. As Software Developer Backend Operations you will maintain our infrastructure, ensuring that it runs 24/7. Check out our jobs at wire.com/jobs and our open source code on github.com/wireapp. - What we talk about when we talk about types > These dialogues somewhat pedantically dissect what we mean when we say a type is an instance of a type class or a type has an instance of a type class and why. Through the course of conversation, we touch on the nature of types, type constructors, and type classes, which led to us talking about math, set theory and category theory, and what they have to do with types and type classes. - The partial options monoid > Parsing options is not the hardest problem. However, if you do not create a pattern the rest of your team can follow, your program can become a tangled mess of random file reads, environment variable lookups and unpredictable defaulting. The Monoid class is a rock solid abstraction for combining options. - Playing with lens-aeson > That works, but it's far from inspiring. We're declaring a Color data type simply for the purpose of writing a type class instance. But it feels pretty heavyweight to have to declare a data type and make a type class instance for just one use site. ### Packages of the week Several interesting packages were announced this week. Instead of picking one to feature, all four are this week's packages of the week! - double-pendulum-simulation Simulates and renders a double pendulum system. - legion Implements a simple block chain server that synchronizes nodes over the network. - prettyprinter Aims to end the Wadler/Leijen zoo dilemma by being a modern, well-documented pretty printer. - sitepipe Generates static sites with plain values and less magic. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view 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 amin at aminb.org Thu Jun 1 22:59:34 2017 From: amin at aminb.org (Amin Bandali) Date: Thu, 01 Jun 2017 18:59:34 -0400 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> Message-ID: <87bmq7s4a1.fsf@aminb.org> > The plain text version is perfect. Seconded. I'm already subscribed to the newsletter but the HTML emails are quite painful to deal with in my setup and I would very much appreciate a plain text version instead (or maybe a subscription preference option to switch between the two). Amin Matthew Pickering writes: > Hi Taylor, > > Please keep posting this to this list. I think I missed the first 50 > editions of your well edited summaries! > > The plain text version is perfect. > > Matt > > > On 1 Jun 2017 23:23, "Taylor Fausak" wrote: > > Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some > people have expressed interest in receiving my newsletter on this > mailing list. Is that something I should set up? > > If you're curious about Haskell Weekly, please check out the latest > issue, which was published today: > > > I've also included issue 57 as plain text here. If you like what you > see, head over to and subscribe! > > --- > > # Haskell Weekly > > ## Issue 57 > > Welcome to another issue of Haskell Weekly! Haskell is a purely > functional programming language that focuses on robustness, concision, > and correctness. This is a weekly summary of what’s going on in its > community. > > - Realizing Hackett, a metaprogrammable Haskell > hackett-a-metaprogrammable-haskell/> > > Almost five months ago, I wrote a blog post about my new programming > language, Hackett, a fanciful sketch of a programming language from a > far-off land with Haskell's type system and Racket's macros. [...] Hackett > is not only real, it's working, and you can try it out yourself! > > - Imperative Haskell > > > Why don't we do this all the time, when Haskell is at least a > serviceable imperative language? Because writing imperative programs is > hard! They don't compose as well, have less useful type signatures, and are > harder to reason about. Getting away from those things is why we have > Haskell to begin with! > > - A Haskell cross compiler for Android > android-8e297cb74e8a> > > Finally launching and running the application on the device, we are > greeted with "Hello from Haskell". While the utility of this application is > certainly questionable it illustrates the essential steps required to > build, link and run an Android application calling a native Haskell > function. > > - Smart data with conduits > > > If you're a programmer now, there's one reality you'd best be getting > used to. People expect you to know how to deal with big data. The kind of > data that will take a while to process. The kind that will crash your > program if you try to bring it all into memory at the same time. > > - Wire is hiring a Software Backend Developer (Operations) in Berlin, > Germany (ad) > > > Wire is an open source, end-to-end encrypted messenger for personal and > business use. For our development center in Berlin we are hiring two > Backend Haskell Developers. As Software Developer Backend Operations you > will maintain our infrastructure, ensuring that it runs 24/7. Check out our > jobs at wire.com/jobs and our open source code on github.com/wireapp. > > - What we talk about when we talk about types > > > These dialogues somewhat pedantically dissect what we mean when we say > a type is an instance of a type class or a type has an instance of a type > class and why. Through the course of conversation, we touch on the nature > of types, type constructors, and type classes, which led to us talking > about math, set theory and category theory, and what they have to do with > types and type classes. > > - The partial options monoid > 31914a71fc67> > > Parsing options is not the hardest problem. However, if you do not > create a pattern the rest of your team can follow, your program can become > a tangled mess of random file reads, environment variable lookups and > unpredictable defaulting. The Monoid class is a rock solid abstraction for > combining options. > > - Playing with lens-aeson > > > That works, but it's far from inspiring. We're declaring a Color data > type simply for the purpose of writing a type class instance. But it feels > pretty heavyweight to have to declare a data type and make a type class > instance for just one use site. > > ### Packages of the week > > Several interesting packages were announced this week. Instead of > picking one to feature, all four are this week's packages of the week! > > - double-pendulum-simulation > > Simulates and renders a double pendulum system. > > - legion > > Implements a simple block chain server that synchronizes nodes over > the network. > > - prettyprinter > > Aims to end the Wadler/Leijen zoo dilemma by being a modern, > well-documented pretty printer. > > - sitepipe > > Generates static sites with plain values and less magic. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From taylor at fausak.me Thu Jun 1 23:07:31 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 01 Jun 2017 18:07:31 -0500 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: <87bmq7s4a1.fsf@aminb.org> References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> <87bmq7s4a1.fsf@aminb.org> Message-ID: <1496358451.2086311.996008504.2121CF67@webmail.messagingengine.com> Sorry about that! Apparently I mis-configured some part of my MailChimp account. You should now be able to request plain text emails by clicking the "update your preferences" link in the footer of any Haskell Weekly email. I can't guarantee that it'll look as nice as what I provided, but hopefully it's better than what you're dealing with now. On Thu, Jun 1, 2017, at 05:59 PM, Amin Bandali wrote: > > The plain text version is perfect. > > Seconded. I'm already subscribed to the newsletter but the HTML > emails are quite painful to deal with in my setup and I would > very much appreciate a plain text version instead (or maybe a > subscription preference option to switch between the two). > > Amin > > > Matthew Pickering writes: > > > Hi Taylor, > > > > Please keep posting this to this list. I think I missed the first 50 > > editions of your well edited summaries! > > > > The plain text version is perfect. > > > > Matt > > > > > > On 1 Jun 2017 23:23, "Taylor Fausak" wrote: > > > > Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some > > people have expressed interest in receiving my newsletter on this > > mailing list. Is that something I should set up? > > > > If you're curious about Haskell Weekly, please check out the latest > > issue, which was published today: > > > > > > I've also included issue 57 as plain text here. If you like what you > > see, head over to and subscribe! > > > > --- > > > > # Haskell Weekly > > > > ## Issue 57 > > > > Welcome to another issue of Haskell Weekly! Haskell is a purely > > functional programming language that focuses on robustness, concision, > > and correctness. This is a weekly summary of what’s going on in its > > community. > > > > - Realizing Hackett, a metaprogrammable Haskell > > > hackett-a-metaprogrammable-haskell/> > > > Almost five months ago, I wrote a blog post about my new programming > > language, Hackett, a fanciful sketch of a programming language from a > > far-off land with Haskell's type system and Racket's macros. [...] Hackett > > is not only real, it's working, and you can try it out yourself! > > > > - Imperative Haskell > > > > > Why don't we do this all the time, when Haskell is at least a > > serviceable imperative language? Because writing imperative programs is > > hard! They don't compose as well, have less useful type signatures, and are > > harder to reason about. Getting away from those things is why we have > > Haskell to begin with! > > > > - A Haskell cross compiler for Android > > > android-8e297cb74e8a> > > > Finally launching and running the application on the device, we are > > greeted with "Hello from Haskell". While the utility of this application is > > certainly questionable it illustrates the essential steps required to > > build, link and run an Android application calling a native Haskell > > function. > > > > - Smart data with conduits > > > > > If you're a programmer now, there's one reality you'd best be getting > > used to. People expect you to know how to deal with big data. The kind of > > data that will take a while to process. The kind that will crash your > > program if you try to bring it all into memory at the same time. > > > > - Wire is hiring a Software Backend Developer (Operations) in Berlin, > > Germany (ad) > > > > > Wire is an open source, end-to-end encrypted messenger for personal and > > business use. For our development center in Berlin we are hiring two > > Backend Haskell Developers. As Software Developer Backend Operations you > > will maintain our infrastructure, ensuring that it runs 24/7. Check out our > > jobs at wire.com/jobs and our open source code on github.com/wireapp. > > > > - What we talk about when we talk about types > > > > > These dialogues somewhat pedantically dissect what we mean when we say > > a type is an instance of a type class or a type has an instance of a type > > class and why. Through the course of conversation, we touch on the nature > > of types, type constructors, and type classes, which led to us talking > > about math, set theory and category theory, and what they have to do with > > types and type classes. > > > > - The partial options monoid > > > 31914a71fc67> > > > Parsing options is not the hardest problem. However, if you do not > > create a pattern the rest of your team can follow, your program can become > > a tangled mess of random file reads, environment variable lookups and > > unpredictable defaulting. The Monoid class is a rock solid abstraction for > > combining options. > > > > - Playing with lens-aeson > > > > > That works, but it's far from inspiring. We're declaring a Color data > > type simply for the purpose of writing a type class instance. But it feels > > pretty heavyweight to have to declare a data type and make a type class > > instance for just one use site. > > > > ### Packages of the week > > > > Several interesting packages were announced this week. Instead of > > picking one to feature, all four are this week's packages of the week! > > > > - double-pendulum-simulation > > > > Simulates and renders a double pendulum system. > > > > - legion > > > > Implements a simple block chain server that synchronizes nodes over > > the network. > > > > - prettyprinter > > > > Aims to end the Wadler/Leijen zoo dilemma by being a modern, > > well-documented pretty printer. > > > > - sitepipe > > > > Generates static sites with plain values and less magic. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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. > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) From mafagafogigante at gmail.com Thu Jun 1 23:28:17 2017 From: mafagafogigante at gmail.com (Bernardo Sulzbach) Date: Thu, 1 Jun 2017 20:28:17 -0300 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> Message-ID: On 06/01/2017 07:33 PM, Matthew Pickering wrote: > Hi Taylor, > > Please keep posting this to this list. I think I missed the first 50 > editions of your well edited summaries! > > The plain text version is perfect. > > Matt > I agree. This seems like something that belongs in this list and adds a lot in case you missed something during the week. From amin at aminb.org Thu Jun 1 23:29:48 2017 From: amin at aminb.org (Amin Bandali) Date: Thu, 01 Jun 2017 19:29:48 -0400 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: <1496358451.2086311.996008504.2121CF67@webmail.messagingengine.com> References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> <87bmq7s4a1.fsf@aminb.org> <1496358451.2086311.996008504.2121CF67@webmail.messagingengine.com> Message-ID: <878tlbs2vn.fsf@aminb.org> Awesome, thanks! I just updated that pref, let's see how it turns out next week. Nonetheless, I'd appreciate you posting your plain text version of the issues here :) Taylor Fausak writes: > Sorry about that! Apparently I mis-configured some part of my MailChimp > account. You should now be able to request plain text emails by clicking > the "update your preferences" link in the footer of any Haskell Weekly > email. I can't guarantee that it'll look as nice as what I provided, but > hopefully it's better than what you're dealing with now. > > On Thu, Jun 1, 2017, at 05:59 PM, Amin Bandali wrote: >> > The plain text version is perfect. >> >> Seconded. I'm already subscribed to the newsletter but the HTML >> emails are quite painful to deal with in my setup and I would >> very much appreciate a plain text version instead (or maybe a >> subscription preference option to switch between the two). >> >> Amin >> >> >> Matthew Pickering writes: >> >> > Hi Taylor, >> > >> > Please keep posting this to this list. I think I missed the first 50 >> > editions of your well edited summaries! >> > >> > The plain text version is perfect. >> > >> > Matt >> > >> > >> > On 1 Jun 2017 23:23, "Taylor Fausak" wrote: >> > >> > Hello haskell-cafe! I am the Haskell Weekly editor. In the past, some >> > people have expressed interest in receiving my newsletter on this >> > mailing list. Is that something I should set up? >> > >> > If you're curious about Haskell Weekly, please check out the latest >> > issue, which was published today: >> > >> > >> > I've also included issue 57 as plain text here. If you like what you >> > see, head over to and subscribe! >> > >> > --- >> > >> > # Haskell Weekly >> > >> > ## Issue 57 >> > >> > Welcome to another issue of Haskell Weekly! Haskell is a purely >> > functional programming language that focuses on robustness, concision, >> > and correctness. This is a weekly summary of what’s going on in its >> > community. >> > >> > - Realizing Hackett, a metaprogrammable Haskell >> > > > hackett-a-metaprogrammable-haskell/> >> > > Almost five months ago, I wrote a blog post about my new programming >> > language, Hackett, a fanciful sketch of a programming language from a >> > far-off land with Haskell's type system and Racket's macros. [...] Hackett >> > is not only real, it's working, and you can try it out yourself! >> > >> > - Imperative Haskell >> > >> > > Why don't we do this all the time, when Haskell is at least a >> > serviceable imperative language? Because writing imperative programs is >> > hard! They don't compose as well, have less useful type signatures, and are >> > harder to reason about. Getting away from those things is why we have >> > Haskell to begin with! >> > >> > - A Haskell cross compiler for Android >> > > > android-8e297cb74e8a> >> > > Finally launching and running the application on the device, we are >> > greeted with "Hello from Haskell". While the utility of this application is >> > certainly questionable it illustrates the essential steps required to >> > build, link and run an Android application calling a native Haskell >> > function. >> > >> > - Smart data with conduits >> > >> > > If you're a programmer now, there's one reality you'd best be getting >> > used to. People expect you to know how to deal with big data. The kind of >> > data that will take a while to process. The kind that will crash your >> > program if you try to bring it all into memory at the same time. >> > >> > - Wire is hiring a Software Backend Developer (Operations) in Berlin, >> > Germany (ad) >> > >> > > Wire is an open source, end-to-end encrypted messenger for personal and >> > business use. For our development center in Berlin we are hiring two >> > Backend Haskell Developers. As Software Developer Backend Operations you >> > will maintain our infrastructure, ensuring that it runs 24/7. Check out our >> > jobs at wire.com/jobs and our open source code on github.com/wireapp. >> > >> > - What we talk about when we talk about types >> > >> > > These dialogues somewhat pedantically dissect what we mean when we say >> > a type is an instance of a type class or a type has an instance of a type >> > class and why. Through the course of conversation, we touch on the nature >> > of types, type constructors, and type classes, which led to us talking >> > about math, set theory and category theory, and what they have to do with >> > types and type classes. >> > >> > - The partial options monoid >> > > > 31914a71fc67> >> > > Parsing options is not the hardest problem. However, if you do not >> > create a pattern the rest of your team can follow, your program can become >> > a tangled mess of random file reads, environment variable lookups and >> > unpredictable defaulting. The Monoid class is a rock solid abstraction for >> > combining options. >> > >> > - Playing with lens-aeson >> > >> > > That works, but it's far from inspiring. We're declaring a Color data >> > type simply for the purpose of writing a type class instance. But it feels >> > pretty heavyweight to have to declare a data type and make a type class >> > instance for just one use site. >> > >> > ### Packages of the week >> > >> > Several interesting packages were announced this week. Instead of >> > picking one to feature, all four are this week's packages of the week! >> > >> > - double-pendulum-simulation >> > >> > Simulates and renders a double pendulum system. >> > >> > - legion >> > >> > Implements a simple block chain server that synchronizes nodes over >> > the network. >> > >> > - prettyprinter >> > >> > Aims to end the Wadler/Leijen zoo dilemma by being a modern, >> > well-documented pretty printer. >> > >> > - sitepipe >> > >> > Generates static sites with plain values and less magic. >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view 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. >> Email had 1 attachment: >> + signature.asc >> 1k (application/pgp-signature) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From matthew.fernandez at gmail.com Fri Jun 2 02:08:34 2017 From: matthew.fernandez at gmail.com (Matthew Fernandez) Date: Thu, 1 Jun 2017 19:08:34 -0700 Subject: [Haskell-cafe] Fwd: Vim syntax file typo In-Reply-To: References: Message-ID: <5f606c80-7cce-52d2-efc2-2c1a10715e95@gmail.com> Hi Bram, Forwarding the below trivial fix, as I've had no response from the Haskell list. If anyone on haskell-cafe wants to assert maintainership over this file, feel free to speak up. Thanks, Matt -------- Forwarded Message -------- Subject: Vim syntax file typo Date: Thu, 4 May 2017 17:56:36 -0700 From: Matthew Fernandez To: Haskell Cafe Hello Haskell Cafe, The attached patch fixes what looks to be a typo in a comment in the Haskell Vim syntax file. Pretty trivial, but I'm mailing it to this list as it's listed as the maintainer of the file and I believe that's the Vim policy. Please let me know if there's somewhere more appropriate I should send this or if you'd prefer me to just submit it as a pull request on the Vim Github. Thanks, Matt ---- commit 9e14e74813e0170832a841b8aed48d11f9e98d09 (HEAD, c332e5d9-0406-4541-a4ae-afeeef835327) Author: Matthew Fernandez Date: Thu May 4 17:48:29 2017 -0700 fix trivial comment typo in Haskell syntax diff --git runtime/syntax/haskell.vim runtime/syntax/haskell.vim index 11f4c35..0cda784 100644 --- runtime/syntax/haskell.vim +++ runtime/syntax/haskell.vim @@ -62,7 +62,7 @@ syn match hsCharacter "^'\([^\\]\|\\[^']\+\|\\'\)'" contains=hsSpecialChar,hs syn match hsNumber "\<[0-9]\+\>\|\<0[xX][0-9a-fA-F]\+\>\|\<0[oO][0-7]\+\>" syn match hsFloat "\<[0-9]\+\.[0-9]\+\([eE][-+]\=[0-9]\+\)\=\>" -" Keyword definitions. These must be patters instead of keywords +" 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 "\" From rae at cs.brynmawr.edu Fri Jun 2 02:32:39 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 1 Jun 2017 22:32:39 -0400 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <592e4722.2a3.645c.14508@clear.net.nz> References: <592e4722.2a3.645c.14508@clear.net.nz> Message-ID: <14C01274-B425-42F7-9C15-F7536CF3879F@cs.brynmawr.edu> > On May 31, 2017, at 12:31 AM, Anthony Clayden wrote: > > If we want to part-apply a type Fun > which has a non-linear lhs, > how does that go with your case-equation style? Problematically. This is why my thesis muses on -- but stops well short of solving -- the problem of non-linear patterns. I'm not sure how it all fits together. >> >> You could always view >> >>> instance TypeError ... => C Int Bool >> >> as sugar for >> >>> instance C Int Bool fails > > Yes I understand that. > But no I don't want any instance. > (Sugar on rotten fruit doesn't hide the smell.) I hereby pronounce > instance TypeError ... => C Int Bool as "not an instance". In other words, I'm not sure what you're getting at here other than concrete syntax. How does not having an instance differ than the TypeError solution? > > OK. Perhaps you're seeing something I can't. > To adapt your example from a parallel message, suppose: > What you're getting at here is that there may be interesting interplay between instance guards and OverlappingInstances. Indeed. This would have to be worked out (or left as an open question) in the proposal. Regardless, I think that hashing out this level of detail here is the wrong place. Put it in the proposal! That way, the ensuing debate involves more of the community and persists better. Richard From dennis.raddle at gmail.com Fri Jun 2 06:03:19 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 1 Jun 2017 23:03:19 -0700 Subject: [Haskell-cafe] can this be done with stack? Message-ID: Using stack, but I have a need to build lots of executables. **lots** and new ones all the time .. my application is music playback. I used to have a single executable for playing music, and used it for all compositions. I later found that I needed to do a lot of configuration specific to each composition, and that the most natural language for specifying all the data and functions specific to a composition was Haskell. That means I have a source file for every composition, in the same directory where I store that composition (as a Sibelius file). But a couple things. (1) they aren't in the stack tree, (2) I don't want to add every one of these to a cabal file. What is the best way to approach this goal? D -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Fri Jun 2 06:27:20 2017 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 2 Jun 2017 09:27:20 +0300 Subject: [Haskell-cafe] can this be done with stack? In-Reply-To: References: Message-ID: Have you tried `stack ghc filename.hs`? Also, you could try the script interpreter approach, with something like this: #!/usr/bin/env stack -- stack --resolver lts-8.12 script --compile main = putStrLn "Hello World" Running `stack filename.hs` will compile and run your file, and you can reuse the resulting executable. On Fri, Jun 2, 2017 at 9:03 AM, Dennis Raddle wrote: > Using stack, but I have a need to build lots of executables. **lots** and > new ones all the time .. my application is music playback. I used to have a > single executable for playing music, and used it for all compositions. I > later found that I needed to do a lot of configuration specific to each > composition, and that the most natural language for specifying all the data > and functions specific to a composition was Haskell. That means I have a > source file for every composition, in the same directory where I store that > composition (as a Sibelius file). But a couple things. (1) they aren't in > the stack tree, (2) I don't want to add every one of these to a cabal file. > > What is the best way to approach this goal? > > D > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Fri Jun 2 07:22:42 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 02 Jun 2017 19:22:42 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <59311242.216.4b85.20097@clear.net.nz> > On Fri Jun 2 02:32:39 UTC 2017, Richard Eisenberg wrote: > > > On May 31, 2017, at 12:31 AM, Anthony Clayden wrote: > > >> You could always view > >> > >>> instance TypeError ... => C Int Bool > >> > >> as sugar for > >> > >>> instance C Int Bool fails > > > > Yes I understand that. > > But no I don't want any instance. > > (Sugar on rotten fruit doesn't hide the smell.) > > I hereby pronounce > > > instance TypeError ... => C Int Bool > > as "not an instance". ... Hmm. I'd be interested how you're going to stop the compiler matching some usage site to it. > In other words, I'm not sure what > you're getting at here other than concrete syntax. > How does not having an instance differ > than the TypeError solution? Good question. I've been struggling to explain it. Re-reading the Instance Chains paper has clarified the issue for me. And looking at Garrett's later 'Variations on Variants' paper. (Clarified, because that's a non-solution.) It's the Expression Problem: Once I have a catch-all instance (even if it has an impossible-to-fulfill constraint) the compiler is committed to selecting that instance. I can't introduce a new data type and new instance for it, because it'll overlap the catch-all instance. IIUC, Instance Chain's 'fail' is more powerful, it triggers back-tracking to look for another instance that doesn't fail. But we don't want to introduce backtracking into Haskell search for instances. Nevertheless, I can only write one Instance Chain per class. So I can't (say in another module) introduce a new datatype with instances. Sometimes closed/chained instances are the right solution. (That's the case for HList, for example. But even there I'm not convinced. I might want as well as HNil, HCons, a constructor with explicit type-labelling.) But sometimes closed instances are not right. I would say that where closed instances are needed, you can still achieve that with a 'catch-all' stand-alone instance, suitably guarded, of course. So I disagree with Garrett: not only do Instance Chains fail to solve the expression problem, they actually exacerbate it. (Same for Closed Type Families, or Closed Class Instances.) > > OK. Perhaps you're seeing something I can't. > > To adapt your example from a parallel message, suppose: > > > > What you're getting at here is that there may be > interesting interplay between instance guards and > OverlappingInstances. Indeed. This would have to be worked > out (or left as an open question) in the proposal. > > Regardless, I think that hashing out this level of detail > here is the wrong place. ... OK, fair enough. > Put it in the proposal! That way, the ensuing > debate involves more of the community and > persists better. > Oh! that I had "Deserts of vast eternity" to write the thing. As it is, it's easier to tackle as bite-size pieces on the forum. AntC From dennis.raddle at gmail.com Fri Jun 2 07:46:46 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 2 Jun 2017 00:46:46 -0700 Subject: [Haskell-cafe] can this be done with stack? In-Reply-To: References: Message-ID: Thanks, I'll take a look at this and get back to you if I have any questions. D On Thu, Jun 1, 2017 at 11:27 PM, Michael Snoyman wrote: > Have you tried `stack ghc filename.hs`? Also, you could try the script > interpreter approach, with something like this: > > #!/usr/bin/env stack > -- stack --resolver lts-8.12 script --compile > main = putStrLn "Hello World" > > Running `stack filename.hs` will compile and run your file, and you can > reuse the resulting executable. > > On Fri, Jun 2, 2017 at 9:03 AM, Dennis Raddle > wrote: > >> Using stack, but I have a need to build lots of executables. **lots** and >> new ones all the time .. my application is music playback. I used to have a >> single executable for playing music, and used it for all compositions. I >> later found that I needed to do a lot of configuration specific to each >> composition, and that the most natural language for specifying all the data >> and functions specific to a composition was Haskell. That means I have a >> source file for every composition, in the same directory where I store that >> composition (as a Sibelius file). But a couple things. (1) they aren't in >> the stack tree, (2) I don't want to add every one of these to a cabal file. >> >> What is the best way to approach this goal? >> >> D >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Fri Jun 2 09:31:56 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 2 Jun 2017 02:31:56 -0700 Subject: [Haskell-cafe] can this be done with stack? In-Reply-To: References: Message-ID: Something I'm not clear on, with regard to 'stack ghc', is how to tell stack what environment, modules, etc. to use -- when I run it on a file that is not within my stack directory tree. I tried simple running 'stack ghc filename.hs' and it couldn't find any of my libraries. I also cannot figure out how to pass arguments to ghc. D On Thu, Jun 1, 2017 at 11:27 PM, Michael Snoyman wrote: > Have you tried `stack ghc filename.hs`? Also, you could try the script > interpreter approach, with something like this: > > #!/usr/bin/env stack > -- stack --resolver lts-8.12 script --compile > main = putStrLn "Hello World" > > Running `stack filename.hs` will compile and run your file, and you can > reuse the resulting executable. > > On Fri, Jun 2, 2017 at 9:03 AM, Dennis Raddle > wrote: > >> Using stack, but I have a need to build lots of executables. **lots** and >> new ones all the time .. my application is music playback. I used to have a >> single executable for playing music, and used it for all compositions. I >> later found that I needed to do a lot of configuration specific to each >> composition, and that the most natural language for specifying all the data >> and functions specific to a composition was Haskell. That means I have a >> source file for every composition, in the same directory where I store that >> composition (as a Sibelius file). But a couple things. (1) they aren't in >> the stack tree, (2) I don't want to add every one of these to a cabal file. >> >> What is the best way to approach this goal? >> >> D >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Fri Jun 2 10:17:38 2017 From: P.Achten at cs.ru.nl (Peter Achten) Date: Fri, 2 Jun 2017 12:17:38 +0200 Subject: [Haskell-cafe] Call for participation: Trends in Functional Programming, 19-21 june 2017 AND Trends in Functional Programming in Education, 22 june 2017, University of Kent, Canterbury Message-ID: <76d8ce6f-4fbc-443c-5271-d3740b9a312e@cs.ru.nl> ----------------------------- C A L L F O R P A R T I C I P A T I O N ----------------------------- ======== TFP 2017 =========== 18th Symposium on Trends in Functional Programming 19-21 June, 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/events/tfp17/index.html ========= TFPIE 2017 ======== Co-located with TFP, and included in the registration fee, is Workshop on Trends in Functional Programming in Education 22 June 2017 University of Kent, Canterbury https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. TFP 2017 will be the main event of a pair of functional programming events. TFP 2017 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on 22 June. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * Soesterberg (The Netherlands) in 2014; * Inria Sophia-Antipolis (France) in 2015; * and Maryland (USA) in 2016. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2017 program chairs, Scott Owens and Meng Wang. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == PAPER SUBMISSIONS == Acceptance of articles for presentation at the symposium is based on a lightweight peer review process of extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which ALL authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. We use EasyChair for the refereeing process. Papers must be submitted at: https://easychair.org/conferences/?conf=tfp17 Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site: http://www.springer.com/computer/lncs?SGWID=0-164-6-793341-0 == INVITED SPEAKERS == Conor McBride University of Strathclyde (UK) Cătălin Hriţcu INRIA Paris (FR) Heather Miller Northeastern University (USA) and EPFL (CH) == IMPORTANT DATES == Submission of draft papers: 5 May, 2017 Notification: 12 May, 2017 Registration: 11 June, 2017 TFP Symposium: 19-21 June, 2017 Student papers feedback: 29 June, 2017 Submission for formal review: 2 August, 2017 Notification of acceptance: 3 November, 2017 Camera ready paper: 2 December, 2017 == PROGRAM COMMITTEE == Co-Chairs Meng Wang University of Kent (UK) Scott Owens University of Kent (UK) PC Jeremy Yallop University of Cambridge (UK) Nicolas Wu University of Bristol (UK) Laura Castro University of A Coruña (ES) Gabriel Scherer Northeastern University (US) Edwin Brady University of St Andrews (UK) Janis Voigtländer Radboud University Nijmegen (NL) Peter Achten Radboud University Nijmegen (NL) Tom Schrijvers KU Leuven (BE) Matthew Fluet Rochester Institute of Technology (US) Mauro Jaskelioff CIFASIS/Universidad Nacional de Rosario (AG) Patricia Johann Appalachian State University (US) Bruno Oliveira The University of Hong Kong (HK) Rita Loogen Philipps-Universität Marburg (GE) David Van Horn University of Marylan (US) Soichiro Hidaka Hosei University (JP) Michał Pałka Chalmers University of Technology (SE) Sandrine Blazy University of Rennes 1 - IRISA (FR) From jgbm at acm.org Fri Jun 2 10:26:16 2017 From: jgbm at acm.org (J. Garrett Morris) Date: Fri, 2 Jun 2017 11:26:16 +0100 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <59311242.216.4b85.20097@clear.net.nz> References: <59311242.216.4b85.20097@clear.net.nz> Message-ID: Hi Anthony, This conversation has become deeply mysterious to me. I understand that you're revisiting arguments on the structuring of conditionals that were tried and discarded in the 70s; what I don't understand is why you need to repeatedly mischaracterize my work to do so. For one example, I have no idea why you make the following claim: > Nevertheless, I can only write one Instance Chain > per class. So I can't (say in another module) > introduce a new datatype with instances. The instance chains paper is quite explicit in ruling out this interpretation; when introducing the notion of chains, we wrote: In ilab, a class can be populated by multiple, non-overlapping instance chains, where each chain may contain multiple clauses (separated by the keyword else). For another, you give a fanciful description of the problems that might arise in implementing instance chains, including: > There's a persistent problem for the compiler > testing for type equality: > the usage sites must have the types grounded. > It's often more successful to prove disequality. and also: > I suspect that for the compiler, > Instance Chains will be as problematic > for type inference as with Closed Type Families: > CTFs have a lot of searching under the covers > to 'look ahead' for equations that can safely match. Luckily, both instance chains and closed type families have formalizations that can be checked to evaluate these claims. In neither case do we find either equality limited to ground types or anything that should be construed as 'look ahead'. Perhaps you're trying to refer to the use of infinitary unification in checking apartness (but not in checking equality) for closed type families? Here again, not only is there no use of or need for infinitary unification with instance chains, but I discussed this difference and its consequences in my 2015 paper. Finally, you make various claims about what is and is not a solution to the expression problem which have no apparent relationship to any of the existing work on the expression problem or its encodings. The point of Swierstra's encoding is that you can give a complete definition of the interpretation of (right-recursive) coproducts, and that doing so is sufficient to encode extensible variants. The downside to his approach is that each new elimination of an extensible variant must itself be defined via a new type class. Subsequent work by Bahr, Oliveira et al., and myself, has lifted this restriction in various ways. At no point in any of these encodings is it in any sense necessary or desirable to extend existing instances for the coproduct, and so there is no reason to imagine that using either instance chains or closed type families would be any obstacle to implementing them. Again, this is all laid out, with examples, in my 2015 paper. /g From michael at snoyman.com Fri Jun 2 11:01:26 2017 From: michael at snoyman.com (Michael Snoyman) Date: Fri, 2 Jun 2017 14:01:26 +0300 Subject: [Haskell-cafe] can this be done with stack? In-Reply-To: References: Message-ID: If you run `stack ghc -- ...`, everything after the -- will be passed to the ghc command. For determining settings, please see this section of the user guide: https://docs.haskellstack.org/en/stable/GUIDE/#finding-project-configs-and-the-implicit-global On Fri, Jun 2, 2017 at 12:31 PM, Dennis Raddle wrote: > Something I'm not clear on, with regard to 'stack ghc', is how to tell > stack what environment, modules, etc. to use -- when I run it on a file > that is not within my stack directory tree. I tried simple running 'stack > ghc filename.hs' and it couldn't find any of my libraries. I also cannot > figure out how to pass arguments to ghc. > > D > > On Thu, Jun 1, 2017 at 11:27 PM, Michael Snoyman > wrote: > >> Have you tried `stack ghc filename.hs`? Also, you could try the script >> interpreter approach, with something like this: >> >> #!/usr/bin/env stack >> -- stack --resolver lts-8.12 script --compile >> main = putStrLn "Hello World" >> >> Running `stack filename.hs` will compile and run your file, and you can >> reuse the resulting executable. >> >> On Fri, Jun 2, 2017 at 9:03 AM, Dennis Raddle >> wrote: >> >>> Using stack, but I have a need to build lots of executables. **lots** >>> and new ones all the time .. my application is music playback. I used to >>> have a single executable for playing music, and used it for all >>> compositions. I later found that I needed to do a lot of configuration >>> specific to each composition, and that the most natural language for >>> specifying all the data and functions specific to a composition was >>> Haskell. That means I have a source file for every composition, in the same >>> directory where I store that composition (as a Sibelius file). But a couple >>> things. (1) they aren't in the stack tree, (2) I don't want to add every >>> one of these to a cabal file. >>> >>> What is the best way to approach this goal? >>> >>> D >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Fri Jun 2 13:25:26 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 2 Jun 2017 08:25:26 -0500 Subject: [Haskell-cafe] Haskell Weekly In-Reply-To: References: <1496355631.2076337.995967936.0D1BB1C6@webmail.messagingengine.com> Message-ID: +1! > El 1 jun 2017, a las 18:28, Bernardo Sulzbach escribió: > >> On 06/01/2017 07:33 PM, Matthew Pickering wrote: >> Hi Taylor, >> Please keep posting this to this list. I think I missed the first 50 editions of your well edited summaries! >> The plain text version is perfect. >> Matt > > I agree. This seems like something that belongs in this list and adds a lot in case you missed something during the week. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From rae at cs.brynmawr.edu Fri Jun 2 13:20:13 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 2 Jun 2017 09:20:13 -0400 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <59311242.216.4b85.20097@clear.net.nz> References: <59311242.216.4b85.20097@clear.net.nz> Message-ID: <36A56921-3CE4-47D8-94AD-24B24C0FA7D8@cs.brynmawr.edu> > On Jun 2, 2017, at 3:22 AM, Anthony Clayden wrote: >> I hereby pronounce >> >>> instance TypeError ... => C Int Bool >> >> as "not an instance". ... > > Hmm. I'd be interested how you're going to stop > the compiler matching some usage site to it. That's what TypeError does. When the compiler matches a use site, it issues an error. I would imagine that's the behavior you want. > >> In other words, I'm not sure what >> you're getting at here other than concrete syntax. >> How does not having an instance differ >> than the TypeError solution? > > Good question. I've been struggling to explain it. ... I'm afraid I didn't follow the description that followed. Can you write a concrete example of something you'd like to do that the current machinery doesn't? > > Oh! that I had "Deserts of vast eternity" > to write the thing. > As it is, it's easier to tackle as bite-size pieces on the > forum. It's always OK to write a proposal with open questions, such as how the feature interacts with overlapping instances, what the concrete syntax should be, etc. But the enormous advantage to moving to a proposal is that we then have a concrete artifact to stare at and evaluate, instead of some hypothetical design which might be different in all our heads. Richard From anthony_clayden at clear.net.nz Fri Jun 2 13:34:49 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 03 Jun 2017 01:34:49 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <59316979.26.2eb3.4860@clear.net.nz> > On Fri Jun 2 10:26:16 UTC 2017, J. Garrett Morris wrote: > This conversation has become deeply mysterious to me. Hi Garrett, thank you for the opportunity to debate the ideas in Instance Chains, and correct any misunderstandings I might have gained. The interaction of Overlapping Instances with other Haskell features has been vexing for a long time. There have been many approaches. I find this continuing situation particularly frustrating, because it seems to me there was an answer in 2002 [1], whose effectiveness was confirmed by the HList work 2004 [2]. I've been banging this drum for a long time [4]. > I understand that you're revisiting arguments on the structuring of conditionals ... No. Until your comment yesterday re Dijkstra (thank you for the tip), I was continuing ideas in the Sulzmann and Stuckey Constraint Handling Rules approach [1]. Although your papers/Dissertation cite some of S&S's work, you seem unaware of type disequality guards. I think that's a significant oversight. > ... that were tried and discarded in the 70s; I can see why Dijkstra's ideas might be discarded for term-level calculation: * the impossibility of determining whether guards are mutually exclusive (that's a specie of the halting problem) * the deliberate non-determinacy But that first objection is not applicable for instances/guards, because they have a very simple semantic structure: pattern-match on the instance head, then type (dis-)unifiability test. The second is a definite plus-feature for instance selection. (Reflecting how GHC works today.) So I'm fully up with the programme of the great programmer. > what I don't understand is why you need > to repeatedly mischaracterize my work to do so. If I'm mischaracterising, I apologise. I note, though, you haven't demurred at my observation that instance chains need backtracking. I find backtracking far more unacceptable than indeterminacy. > For one example, I have no idea why you make the following claim: >> Nevertheless, I can only write one Instance Chain >> per class. So I can't (say in another module) >> introduce a new datatype with instances. > The instance chains paper is quite explicit in ruling out this > interpretation; when introducing the notion of chains, we wrote: > In ilab, a class can be populated by multiple, non-overlapping > instance chains, where each chain may contain multiple clauses > (separated by the keyword else). Then I apologise. The two chief examples in that paper (gcd and the Swierstra encoding) both show a final `else ... fails` branch with a catch-all instance head. Section 3.2 comments "..., closing the Gcd class." For the Swierstra encoding in particular, the algorithm requires the class to be total (it must be closed), so that the recursive descent test/validation for go-left/go-right can be determinate. > For another, you give a fanciful description of the problems that > might arise in implementing instance chains, including: I reject "fanciful". So I'm going to give citations. >> There's a persistent problem for the compiler >> testing for type equality: >> the usage sites must have the types grounded. >> It's often more successful to prove disequality. That's straight out of the HList paper [2], Section 9 "By chance or by design?". "We should point out however groundness issues. If TypeEq is to return HTrue, the types must be ground; TypeEq can return HFalse even for unground types, provided they are instantiated enough to determine that they are not equal." > and also: >> I suspect that for the compiler, >> Instance Chains will be as problematic >> for type inference as with Closed Type Families: >> CTFs have a lot of searching under the covers >> to 'look ahead' for equations that can safely match. That's from Richard, particularly this comment [3]. The whole blog post is relevant here, I think. > Luckily, both instance chains and closed type families have > formalizations that can be checked to evaluate these claims. Yes, Overlapping Instances has suffered for too long from under-/non-formalised semantics. What I'll be doing for Instance Guards is giving a translation into Haskell2010 + MPTCs __without__ overlaps. (I will need to assume, though, a type-level type equality test/total function. You've already commented that's easliy produced.) A serious weakness of Instance Chains, it seems to me, is it can't be translated to existing Haskell. > In neither case do we find either equality limited to ground types > or anything that should be construed as 'look ahead'. I think the situation has changed with the introduction of Type Families. They weren't applicable in 2010. So not relevant to the Instance Chains paper. "Look ahead" is exactly what Richard is describing in the bulk of that blog post. That is, looking down the sequence of instance equations, to see if any would match and be confluent. This significantly helps progress in inference. If Instance Chains aren't going to be doing that, that's another weakness. > Perhaps you're trying to refer to the use of > infinitary unification in checking apartness (but not in > checking equality) for closed type families? No, infinitary unification is a whole 'nother bag of spanners. I am still goggling at your joint paper with Richard. > Here again, not only is there no use of or need > for infinitary unification with instance chains, ... Good! > but I discussed this difference and its consequences > in my 2015 paper. OK. I've not yet got through that paper. What I do see in the 2010 paper (perhaps this has changed subsequently) is using typeclass membership to determine whether a type is a member of the __same__ class. This seems to be essential to the Swierstra encoding such as: > else f :<: (g :+: h) if f :<: g > else f :<: (g :+: h) if f :<: h Gloss: "f is related to (g :+: h), if f is related to g". And likewise for f related to h. So: * this needs look inside the ( :+: ) to see if f is related to g or to h, or to both (fail) or to neither (fail). And now you tell me there might be other instance chains for `:<:`, so the compiler has to work through them. * it breaks down the 'phase distinctions' in instance selection. I feel very queazy about a recursion like that at the class level. We can express Russell's paradox: > else f :<: g fails if f :<: g Haskell very strictly doesn't support instance contexts driving selection of instances. That is confusing for newbies, but it's for very good decidability reasons. > Finally, you make various claims about what is and is not a solution > to the expression problem which have no apparent relationship to any of > the existing work on the expression problem or its encodings. > ... Again, this is all laid out, with examples, in my 2015 paper. I was being brief. (And this post has gone on plenty long enough, too.) I'll come back and debate that point when I've worked through your 2015 paper. What's strongly motivating me with Haskell is getting the type system to cater for extensible/anonymous records. (I'm a Relational Theorist by trade.) Closed instances (be they Chains or Type Families, or the proposed Closed Classes) are just not going to hack it. Adam G for the Overloaded Records Fields work has eschewed Type Families in favour of FunDeps. That's because it needs to create instances 'on the fly'. Now he hasn't needed overlaps yet (ORF is at an early stage), but anonymous/extensible records will. Just like HList. AntC [1] Sulzmann & Stuckey 2002 "A Theory of Overloading", esp section 8.2 "Overlapping Definitions" [2] Kiselyov et al 2004 "Strongly Typed Heterogeneous Collections" [3] https://typesandkinds.wordpress.com/2013/04/29/coincident-overlap-in-type-families/#comment-131 [4] https://ghc.haskell.org/trac/ghc/wiki/NewAxioms/DiscussionPage From rae at cs.brynmawr.edu Fri Jun 2 13:48:43 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 2 Jun 2017 09:48:43 -0400 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <59316979.26.2eb3.4860@clear.net.nz> References: <59316979.26.2eb3.4860@clear.net.nz> Message-ID: <9464835D-214D-4004-A662-EA6BA1454E71@cs.brynmawr.edu> I'm going to respond just to the few points that concern me directly. > On Jun 2, 2017, at 9:34 AM, Anthony Clayden wrote: > >>> There's a persistent problem for the compiler >>> testing for type equality: >>> the usage sites must have the types grounded. >>> It's often more successful to prove disequality. > > That's straight out of the HList paper [2], > Section 9 "By chance or by design?". > "We should point out however groundness issues. > If TypeEq is to return HTrue, the types must be ground; > TypeEq can return HFalse even for unground types, > provided they are instantiated enough to determine > that they are not equal." While this may be true for HList's TypeEq, it is not true for closed type families. If we have > type family Equals a b where > Equals a a = True > Equals a b = False then (Equals [a] [a]) will reduce to True, even if `a` is universally bound. Indeed, even (Equals a a) will reduce to True. So there is no groundness issue any more. > >> and also: > >>> I suspect that for the compiler, >>> Instance Chains will be as problematic >>> for type inference as with Closed Type Families: >>> CTFs have a lot of searching under the covers >>> to 'look ahead' for equations that can safely match. > > That's from Richard, particularly this comment [3]. > The whole blog post is relevant here, I think. I'm not sure where you're getting "look ahead" from. Closed type families -- and that post, as far as I can tell -- don't discuss looking ahead. Instead, closed type families are all about looking *behind*, considering previous equations (only) when working with a later one. > > I think the situation has changed with the introduction > of Type Families. They weren't applicable in 2010. > So not relevant to the Instance Chains paper. Type families were introduced in 2005, I believe. At least, that's when the papers were written. I don't know what version of GHC first included them, but I think it was before 2010. > > "Look ahead" is exactly what Richard is describing > in the bulk of that blog post. I disagree here: that blog post was about what I now call compatibility, which is a property between equations, independent of a type that we're trying to reduce. There's no looking ahead. Richard From trebla at vex.net Fri Jun 2 17:01:54 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 2 Jun 2017 13:01:54 -0400 Subject: [Haskell-cafe] listing include files in a cabal file In-Reply-To: <363d9a2e-8543-4d25-030f-81d180eaf6f2@funwithsoftware.org> References: <363d9a2e-8543-4d25-030f-81d180eaf6f2@funwithsoftware.org> Message-ID: <36f633f7-59e0-078b-29d6-0a5fb95445c0@vex.net> On 2017-05-30 02:13 PM, Patrick Pelletier wrote: > And even when compiling via C, wouldn't > the include already be picked up when it is part of the foreign > declaration, e. g.: > > foreign import ccall unsafe "tmr_tag_data.h TMR_bytesToHex" > c_TMR_bytesToHex :: Ptr Word8 > -> Word32 > -> CString > -> IO () No for GHC. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#using-header-files From jgbm at acm.org Fri Jun 2 17:35:35 2017 From: jgbm at acm.org (J. Garrett Morris) Date: Fri, 2 Jun 2017 18:35:35 +0100 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <59316979.26.2eb3.4860@clear.net.nz> References: <59316979.26.2eb3.4860@clear.net.nz> Message-ID: On Fri, Jun 2, 2017 at 2:34 PM, Anthony Clayden wrote: > Although your papers/Dissertation cite some of S&S's work, > you seem unaware of type disequality guards. Of course we were aware of inequality guards. They are a special case of the observation in §2.3 of the instance chains paper about unifying but non-overlapping instances; §7 of that paper and §7.1 of my dissertation discuss extending the formal treatment to accept such instances. My Hackage survey ("Using Hackage to inform language design", Haskell 2010) discovered that 85% of overlapping instances were contained within the same module, motivating the formalization of that usage pattern with instance chains. > We can express Russell's paradox: > >> else f :<: g fails if f :<: g This is not Russell's paradox, as the lack of set comprehensions in the near vicinity might have suggested. At best, it highlights an incompleteness in the deduction algorithm given in the 2010 paper (from a ⇒ ¬a, we would hope to conclude ¬a). But then, I never claimed completeness. > Haskell very strictly doesn't support instance contexts > driving selection of instances. > That is confusing for newbies, > but it's for very good decidability reasons. Haskell instance selection is decidable by induction on the number of type constructors in an entailment; if you apply the same restriction to instance chains (i.e., that there be more constructors in the conclusion of an instance than in its hypotheses), you get exactly the same decidability results. There are, of course, less restrictive conditions that would also guarantee decidability, but that is not the point. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca From dennis.raddle at gmail.com Fri Jun 2 19:24:23 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 2 Jun 2017 12:24:23 -0700 Subject: [Haskell-cafe] can this be done with stack? In-Reply-To: References: Message-ID: That worked beautifully, thanks. (I mean to pass --stack-yaml ) D On Fri, Jun 2, 2017 at 4:01 AM, Michael Snoyman wrote: > If you run `stack ghc -- ...`, everything after the -- will be passed to > the ghc command. For determining settings, please see this section of the > user guide: > > https://docs.haskellstack.org/en/stable/GUIDE/#finding- > project-configs-and-the-implicit-global > > On Fri, Jun 2, 2017 at 12:31 PM, Dennis Raddle > wrote: > >> Something I'm not clear on, with regard to 'stack ghc', is how to tell >> stack what environment, modules, etc. to use -- when I run it on a file >> that is not within my stack directory tree. I tried simple running 'stack >> ghc filename.hs' and it couldn't find any of my libraries. I also cannot >> figure out how to pass arguments to ghc. >> >> D >> >> On Thu, Jun 1, 2017 at 11:27 PM, Michael Snoyman >> wrote: >> >>> Have you tried `stack ghc filename.hs`? Also, you could try the script >>> interpreter approach, with something like this: >>> >>> #!/usr/bin/env stack >>> -- stack --resolver lts-8.12 script --compile >>> main = putStrLn "Hello World" >>> >>> Running `stack filename.hs` will compile and run your file, and you can >>> reuse the resulting executable. >>> >>> On Fri, Jun 2, 2017 at 9:03 AM, Dennis Raddle >>> wrote: >>> >>>> Using stack, but I have a need to build lots of executables. **lots** >>>> and new ones all the time .. my application is music playback. I used to >>>> have a single executable for playing music, and used it for all >>>> compositions. I later found that I needed to do a lot of configuration >>>> specific to each composition, and that the most natural language for >>>> specifying all the data and functions specific to a composition was >>>> Haskell. That means I have a source file for every composition, in the same >>>> directory where I store that composition (as a Sibelius file). But a couple >>>> things. (1) they aren't in the stack tree, (2) I don't want to add every >>>> one of these to a cabal file. >>>> >>>> What is the best way to approach this goal? >>>> >>>> D >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jun 3 00:31:19 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 2 Jun 2017 17:31:19 -0700 Subject: [Haskell-cafe] do I need to uninstall haskell-mode before installing intero? Message-ID: I want to try intero with emacs/stack. I have been using haskell-mode. Do I need to uninstall it first--is there any potential conflict? Thanks, D -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Sat Jun 3 00:58:13 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 2 Jun 2017 17:58:13 -0700 Subject: [Haskell-cafe] do I need to uninstall haskell-mode before installing intero? In-Reply-To: References: Message-ID: Never mind, I found it's easy to uninstall or reinstall at will, so I will just uninstall it. D On Fri, Jun 2, 2017 at 5:31 PM, Dennis Raddle wrote: > I want to try intero with emacs/stack. I have been using haskell-mode. Do > I need to uninstall it first--is there any potential conflict? > > Thanks, > D > -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at funwithsoftware.org Sat Jun 3 02:23:12 2017 From: code at funwithsoftware.org (Patrick Pelletier) Date: Fri, 2 Jun 2017 19:23:12 -0700 Subject: [Haskell-cafe] listing include files in a cabal file In-Reply-To: <36f633f7-59e0-078b-29d6-0a5fb95445c0@vex.net> References: <363d9a2e-8543-4d25-030f-81d180eaf6f2@funwithsoftware.org> <36f633f7-59e0-078b-29d6-0a5fb95445c0@vex.net> Message-ID: On 6/2/17 10:01 AM, Albert Y. C. Lai wrote: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi-chap.html#using-header-files > This also says that "include-files" is ignored. So I'm still sticking by my original assertion, that header files should just go in "extra-source-files". --Patrick From anthony_clayden at clear.net.nz Sat Jun 3 10:33:57 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 03 Jun 2017 22:33:57 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <59329095.326.2100.2771@clear.net.nz> > On Fri Jun 2 13:48:43 UTC 2017, Richard Eisenberg wrote: > I'm going to respond just to the few points that concern > me directly. > Thanks Richard, blige! there's a lot to catch up with. > > On Jun 2, 2017, at 9:34 AM, Anthony Clayden wrote: > >>> There's a persistent problem for the compiler > >>> testing for type equality: > >>> the usage sites must have the types grounded. > >>> It's often more successful to prove disequality. > > > > That's straight out of the HList paper [2], > > Section 9 "By chance or by design?". > > "We should point out however groundness issues. > > If TypeEq is to return HTrue, the types must be > > ground; TypeEq can return HFalse even for unground > > types, provided they are instantiated enough to > > determine that they are not equal." > > While this may be true for HList's TypeEq, it is not true > for closed type families. If we have > > > type family Equals a b where > > Equals a a = True > > Equals a b = False > HList's TypeEq is comparable from 2004!, using typeclasses/FunDeps/Overlaps: > class TypeEq a b p | a b -> p where > instance TypeEq a a HTrue > instance (p ~ HFalse) => TypeEq a b p The False instance needs bare typevar `p` so that it overlaps; consequently needs UndecidableInstances. (I've used (~), but that was a typecast class in 2004.) > then (Equals [a] [a]) will reduce to True, even if `a` is > universally bound. Indeed, even (Equals a a) will reduce > to True. So there is no groundness issue any more. > Great stuff! And that TypeEq behaves likewise now. I was trying to cast the discussion back to ~2010, the Instance Chains work. IIRC groundedness was still a difficulty then. > > > >> and also: > > > >>> I suspect that for the compiler, > >>> Instance Chains will be as problematic > >>> for type inference as with Closed Type Families: > >>> CTFs have a lot of searching under the covers > >>> to 'look ahead' for equations that can safely match. > > > > That's from Richard, particularly this comment [3]. > > The whole blog post is relevant here, I think. > > I'm not sure where you're getting "look ahead" from. > Closed type families -- and that post, as far as I can > tell -- don't discuss looking ahead. Instead, closed type > families are all about looking *behind*, Well, I think we're saying the same thing. Your last comment on that blog post links to the NewAxioms write-up. That has this example: > type family And (a :: Bool) (b :: Bool) where > And False a = False > And True b = b > And c False = False > And d True = d > And e e = e "All of these equations are compatible, meaning that GHC does not have to do the apartness check against the target." Faced with simplifying `And c False`, does GHC get stuck at the first or second equation, because it can't resolve `c` to `False` or `True`? No, it "looks ahead" to the third equation. Because it sees that if `And c False` unifies with either of the first two, it'll yield the same result `False`. Your comment on the blog post is "coincident overlap within closed type families (the new nomenclature for branched instances) would indeed be useful." I think it would be useful, too, for Instance Chains or Closed Classes. But there's a problem: Class instances must select method implementations, as well type improvement. So we need to fix on a specific instance, even though we only have `And c False`. > > I think the situation has changed with the introduction > > of Type Families. They weren't applicable in 2010. > > So not relevant to the Instance Chains paper. > My mistake: I meant to say "... introduction of Closed Type Families". > Type families were introduced in 2005, I believe. > At least, that's when the papers were written. Hmm, careful. 2005 was Assoc types only. The usually cited paper for Type Families is Schrivers et al 2008. Garrett's papers cite that, not the 2005, and I agree that's the full write-up. But the 2008 paper was written in parallel with development. The feature appeared in GHC after the paper. And it wasn't complete: we waited a long time to get Type Families/(~) in superclass constraints. (There were a couple of release which supported the syntax superclass, but it did nothing.) > I don't know what version of GHC first included them, > but I think it was before 2010. > Vintage ~2010 there was limited support for overlap in TF instances -- the equations had to be "confluent". (This is the (||) example near the top of your blog post, where you conclude "and we can just write || using separate instances, anyway." Yes you could just write separate instances in ~2010.) I don't see that Instance Chains has a comparable notion of "confluent" or "compatible". But perhaps I missed it. > > > > "Look ahead" is exactly what Richard is describing > > in the bulk of that blog post. > > I disagree here: ... See above AntC From anthony_clayden at clear.net.nz Sat Jun 3 11:17:36 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 03 Jun 2017 23:17:36 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <59329ad0.32f.56e8.29335@clear.net.nz> > On Fri Jun 2 17:35:35 UTC 2017, J. Garrett Morris wrote: >> On Fri, Jun 2, 2017 at 2:34 PM, Anthony Clayden wrote: >> Although your papers/Dissertation cite some of S&S's work, >> you seem unaware of type disequality guards. > Of course we were aware of inequality guards. > They are a special case of the observation in §2.3 > of the instance chains paper about unifying > but non-overlapping instances; §7 of that paper and §7.1 of my > dissertation discuss extending the formal treatment > to accept such instances. Then I'm sorry Garrett, but if any of those refs are intended to be talking about inequality guards, it's so oblique as to have failed to communicate. In particular, you fail to mention them in your dissertation §7.1, first bullet. Example: "The first challenge is to develop a method to represent negative syntactic constraints on types. For example, in the following instance chain > instance C (Maybe t) > else C t "the second clause can only apply to types that are not of the form Maybeτ for some type τ. To pursue this approach, we would need to develop representations and proof rules for such limitations on the instantiation of type variables." I would write that non-Maybe instance as: > instance C t | t /~ (Maybe _) -- underscore = anonymous I guess instance chain: > else C t fails if t == (Maybe tau) > -- but that must not introduce typevar `tau` to the environment. The S&S CHR approach did "develop proof rules" to type inequalities (according to the 2002 paper). An explicit inequality guard makes it easy to test whether two instances are apart. > My Hackage survey ("Using Hackage > to inform language design", Haskell 2010) > discovered that 85% of overlapping instances were > contained within the same module, ... Well of course they are! Putting overlapping instances in separate modules is disastrous, everybody knows that. There's a thorough write-up from SPJ here https://mail.haskell.org/pipermail/haskell-cafe/2010-July/080043.html That does not prove people _want_ to restrict the instances to a single module. They have no choice in practice. So I'm surprised there's as much as 15% of overlapping instances in separate modules. I shudder at the incoherence. If you surveyed a joinery and found everything held together with nails, that would reflect only that there were no screwdrivers on the premisses. > motivating the formalization of that > usage pattern with instance chains. No. I would say (to both Instance Chains and Closed Type Families/Classes): motivating to support something less restrictive. Viz the ability to write stand-alone instances, that can be verified to not overlap (taking guards into account), same approach as the classes in the standard libraries. (Note how the monad transformers library was re-architected, to avoid the dangers of importing overlaps.) AntC From anthony_clayden at clear.net.nz Sun Jun 4 08:06:32 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 04 Jun 2017 20:06:32 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <5933bf88.1c2.247.27284@clear.net.nz> > On Fri Jun 2 13:20:13 UTC 2017, Richard Eisenberg wrote: > > On Jun 2, 2017, at 3:22 AM, Anthony Clayden wrote: > >> I hereby pronounce > >>> instance TypeError ... => C Int Bool > >> > >> as "not an instance". ... > > > > Hmm. I'd be interested how you're going to stop > > the compiler matching some usage site to it. > > That's what TypeError does. When the compiler matches a > use site, it issues an error. I would imagine that's the > behavior you want. No. I want to leave the class open, so I can add other instances (possibly in a different module). If I protect instances in this module with guards, the compiler can satisfy itself that the other modules' instances do not overlap. > Can you write a concrete example of something you'd like > to do that the current machinery doesn't? > OK let's recap the Expression Problem first. There are two legs: * We want to freely add methods over a set of datatypes. (Problematic in OOP, because the methods are embedded in the objects.) In Haskell we can declare a new class with new method(s), and give instances over those datatypes. * We want to freely add constructors, and expand existing classes/methods to cover. That's not so easy in Haskell. The usual work-round is to make each constructor a new datatype. Then we can use the instance mechanism to extend classes/methods. ("Usual" for example with DSL's to expand the AST.) If you have closed type families/classes (esp in an imported/library module), you're blocked from extending it for new datatypes. Now apparently Instance Chains don't suffer this, the `fails` triggers a search for other instances in other chains. Garrett in an earlier message quoted section 3.1.1 of the paper "a class can be populated by multiple, non-overlapping instance chains, where each chain may contain multiple clauses". Unfortunately I can find no examples of using this feature, so I'm a bit unsure how it goes. We'd know the chains are non-overlapping because they'd chain over distinct datatypes, I imagine. And I thought that's what we were getting with CTFs, but the implementation fell short of my expectations. I wanted (when I suggested the `where`-style syntax): > module A > type family F a b -- full stop! > type instance F (T1 a) b where > ... -- overlapping equations within T1 > > module B > type instance F (T2 c) d where > ... -- overlapping equations within T2 Those closed instances in distinct modules are provably non-overlapping, because of the different type constructor. (By the same rules as currently, for apartness of instance heads. All equations within the where-group must unify with the instance head.) So then this (current) syntax would be a shorthand: > type family G e f where > ... -- total equations for G for the author of `G` who deliberately wanted to prevent anybody expanding the family. i.e shorthand for > type family G e f > type instance G e f where > ... Fair enough, that's a common requirement. But all we got in the implementation was that blitz-all style. (I'm grumpy.) And according to Garrett's survey, 15% of Hackage would be grumpy too. OK, concrete example: within the HList framework > data HNil = HNil > data HList e l = HList e l > -- deliberately not using DataKinds the Hlist paper discusses various approaches for indexing the payloads `e` within the list. Suppose (eliding a lot of detail) I choose Type-Indexed Products like > newtype PersonId = PersonId Int > newtype PersonName = PersonName String > ... > me = HCons (PersonId 41) $ HCons (PersonName "AntC") HNil And type indexed `Has` predicate needing overlaps: > class Has e l ... > -- no instance for HNil > instance Has e (HCons e l) ... > instance (Has e l') => Has e (HCons e' l') ... That's standard HList TIP, let's assume it's in a library/module. Another style of carrying the payload is type labels. To mix these styles, I need a way to cons a labelled element: > data AstroSign = AstroSign > ... > data HConsLab lab e l = HConsLab lab e l > > me2 = HConsLab AstroSign 12 me This deliberately allows the payload to be an ad-hoc type. Now I need a Has instance: > instance Has lab (HConsLab lab e l) ... > instance (Has lab l') => Has lab (HConsLab lab' e' l') ... Again relies on overlap. No danger of clashing with the vanilla HCons style, because labels are a distinct set of types. IOW this is fine: > you = HCons (PersonId 73) $ HCons (PersonName "rae") > $ HConsLab AstroSIgn 7 HNil > -- instances for the type of `you` > -- (Has you PersonId, Has you PersonName, Has you AstroSign) I can do all this now with stand-alone instances. But I have to be careful to keep my overlaps well-behaved. With closed Type Families/the proposed Classes, I can't add those HConsLab instances. I want to continue current support for freely adding instances, but provide a mechanism to enforce no-overlaps. And I think guards achieve that with relatively lightweight syntax, avoiding hard-to-follow sequences of `else` ... AntC From anthony_clayden at clear.net.nz Sun Jun 4 08:24:03 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 04 Jun 2017 20:24:03 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <5933c3a3.3a6.21d1.29624@clear.net.nz> Errk, braino! This: > data HNil = HNil > data HList e l = HList e l Should be: > data HNil = HNil > data HCons e l = HCons e l AntC From hjgtuyl at chello.nl Sun Jun 4 09:45:58 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 04 Jun 2017 11:45:58 +0200 Subject: [Haskell-cafe] Bug in GHC or cabal-install? Message-ID: L.S., I am trying the prerelease of GHC, version 8.2.0.20170507 I adapted wxHaskell to the new packages that come with the new GHC and it compiles now, but only the first time. If I compile it a second time, even if nothing has changed, the information from the custom-setup section of the wxc.cabal file seems to be forgotten. This section looks like this: custom-setup setup-depends: base, Cabal < 2, containers, bytestring, split, process, directory, filepath (I am using cabal-install 1.24.0.2) Output from the second time I try to install wxHaskell: > cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx [1 of 1] Compiling Main ( X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... [1 of 1] Compiling Main ( X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: Variable not in scope: versionBranch :: Version -> [a0] | 505 | full_ver = (concat . intersperse "." . map show . versionBranch) ver | ^^^^^^^^^^^^^ This error message indicates that the wrong version of Cabal (2.0) is used to compile the wxcore setup.hs It looks like a cabal-install bug, but this does not happen when I use GHC 8.0.2; should I write a GHC bug ticket? Regards, Henk-Jan van Tuyl -- 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://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From ivan.miljenovic at gmail.com Sun Jun 4 11:39:17 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sun, 4 Jun 2017 21:39:17 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: This is from a limitation/bug with Cabal-the-library, in that there are typically no dependency checks for custom Setup.[l]hs configurations. wxc has such a custom one: http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs versionBranch is from Data.Version in base, and it appears that the in this GHC pre-release there's been a change in base that removed this function. On 4 June 2017 at 19:45, Henk-Jan van Tuyl wrote: > > L.S., > > I am trying the prerelease of GHC, version 8.2.0.20170507 > > I adapted wxHaskell to the new packages that come with the new GHC and it > compiles now, but only the first time. If I compile it a second time, even > if nothing has changed, the information from the custom-setup section of > the wxc.cabal file seems to be forgotten. This section looks like this: > > custom-setup > setup-depends: > base, > Cabal < 2, > containers, > bytestring, > split, > process, > directory, > filepath > (I am using cabal-install 1.24.0.2) > > Output from the second time I try to install wxHaskell: > >> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx > > [1 of 1] Compiling Main ( > X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, > X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) > Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... > [1 of 1] Compiling Main ( > X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, > X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) > > X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: > Variable not in scope: versionBranch :: Version -> > [a0] > | > 505 | full_ver = (concat . intersperse "." . map show . > versionBranch) ver > | > ^^^^^^^^^^^^^ > > This error message indicates that the wrong version of Cabal (2.0) is used > to compile the wxcore setup.hs > It looks like a cabal-install bug, but this does not happen when I > use GHC 8.0.2; should I write a GHC bug ticket? > > Regards, > Henk-Jan van Tuyl > > > -- > 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://Van.Tuyl.eu/ > 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. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From anthony_clayden at clear.net.nz Sun Jun 4 12:00:21 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 05 Jun 2017 00:00:21 +1200 Subject: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families] Message-ID: <5933f655.1b3.56bb.27371@clear.net.nz> [starting a new thread for this topic] > On Fri Jun 2 17:35:35 UTC 2017, J. Garrett Morris wrote: >> On Fri, Jun 2, 2017 at 2:34 PM, Anthony Clayden wrote: >> else f :<: g fails if f :<: g >> Haskell very strictly doesn't support instance contexts >> driving selection of instances. > Haskell instance selection ... > if you apply the same restriction to instance chains ... What was confusing me is that there's a fault in the instance definitions for the Swierstra encoding as appears in the 2010 Instance Chains paper. I see in your 2015 paper that's been fixed. But before I go on to discuss, is there a typo in the 2015 paper? Figure 6 line 6 shows a type family equation > IsIn f g = Yep That's supposed to mirror the Instance Chains solution Figure 3 line 6: > else f `In` g fails So Figure 6/line 6's `Yep` should be a `Nope`?? Ok what was the fault in the 2010 paper? It correctly failed `instance f :<: (f :+: f)`, because that's ambiguous as to whether the wanted `f` should match left or right of `:+:`. But it didn't fail `instance f :<: ((f :+: f) :+: f)`, because from the failure above, the left operand of the outer `:+:`, viz `(f :+: f)`, is not an instance. So `f :<: ((fail) :+: f)` succeeds. I think this shows that using class instances to both define methods and drive selection logic can fail to separate concerns. You wrote [on the GCD thread]: >>>>> Of course, you'll have an easier time of it >>>>> if you limit yourself to only considering type-level definitions, >>>>> and not the corresponding method definitions. >>>>> But doing so rather misses the point of instance chains. It seems to me that in the 2010 paper, the fault arises from considering only the method definitions and failing to pay attention to the type-level. And yes, I want to make an easy time as possible for the programmer -- both writing and especially reading code. The second approach in the 2015 paper using a case-preparing Type Family seems to me to cleanly impose a phase distinction first type-level calculation then class instance selection/method overloading. So my end-game is to be able to remove FunDeps from the language, in favour of class and instance contexts giving Type Families with Equality constraints. (By all means, let's encourage those Type Families to be Associated within classes, per your Partiality paper with Richard.) To achieve that we need better support for overlaps. We need to do that in an understandable way for the programmer. That is, the 'umble programmer like me, not needing an advanced PhD in abstruse type theory. I think Instance Guards help readability by putting the instance selection criteria all in the one place at the instance head; not reliant on the reader scanning through a prior chain of instances/elses. > ... there is no reason to imagine that using > either instance chains or closed type families > would be any obstacle to implementing them. [viz extensible variants/co-products] No I'm not suggesting any lack of capability. If anything, Instance Chains are _too_ powerful. I'm working on showing how the Swierstra encoding could be catered for in Haskell 2010 + MPTCs+TypeEq. That is, was achievable in GHC 2004. (I could do with a few extra milli-Olegs of brain power.) It's a debate about whether/why/how we introduce syntactic sugar into current capability vs introducing a heretofore avoided feature into type inference viz: type class membership driving instance selection, as opposed to currently: types driving instance selection. AntC From clintonmead at gmail.com Sun Jun 4 12:50:59 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Sun, 4 Jun 2017 22:50:59 +1000 Subject: [Haskell-cafe] Avoiding orphan instances and dependency blowups Message-ID: Hi All Consider this common situation. 1. Class C in package A. 2. A data type D in package B. 3. There is a clear instance C D but: 4. We do not want A to depend on B as most users of A do not use B. 5. We do not want B to depend on A as most users of B do not use A. Currently the proposed solutions are: 1. Create a third package, say AB, that depends on both A and B, wrap D in a newtype, and define an instance there. 2. Create a third package, say AB, that depends on both A and B as above, but instead create an orphan instance C D in this package. 3. Just give in and either make A depend on B or B depend on A. None of these solutions seem very satisfying. The first one, wrapping D in a newtype, destroys much of the interoperability that is attempting to be achieved by defining the instance in the first place. The second solution uses orphan instances and for a variety of reasons many seem to suggest these should be avoided. The third option introduces a snowball of dependencies that the vast majority of the time will be completely unused. I've heard some conversations of changes to GHC to deal with this, like "authoritative instances" but nothing seems to have come of it? I thought to myself, maybe this is a problem that could be solved by the package manager, not GHC. Here's the draft of how this could work: 1. Create a package, AB, that depends on A and B, but passes an "option" to B, in this case "A". So the dependencies of AB are A and B(A). 2. The package B defines the instance C D, but wrapped in some preprocessor #ifdef style macros. 3. The package manager passes the requested flags to B during it's compilation, and those flags trigger the sections of code required to be compiled and also additional dependencies. 4. If a new package is installed adds to the flags of B, B is recompiled. This way, packages could define instances for each other but if those dependencies are not used, they do not need to be compiled. But the user has a way to explicitly activate the instances. My questions: 1. Is this a roughly okay idea? 2. Is there already a better way of doing what I'm proposing (perhaps through backpack which I don't know much about yet)? 3. Is there a way to make this happen currently in Stack or Cabal, perhaps with custom setup scripts, or will this need some significant changes to Stack/Cabal themselves? Clinton -------------- next part -------------- An HTML attachment was scrubbed... URL: From yotam2206 at gmail.com Sun Jun 4 13:03:54 2017 From: yotam2206 at gmail.com (Yotam Ohad) Date: Sun, 04 Jun 2017 13:03:54 +0000 Subject: [Haskell-cafe] Different results when building wxHaskell on Cabal and Stack Message-ID: Hello cafe, Lately, I wanted to try wxHaskell, so I downloaded and install wxWidgets and added the necessary paths to %PATH%. The problem was that when trying to build, cabal would have no problem at all, while stack sends me into battle with my path, complaining about missing header and executable files and so on. I don't understand why stack is having such a hard time when cabal has no trouble at all. I know that they are not the same, but I still think that it is weird that stack is acting like that. Thanks for your help, Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgbm at acm.org Sun Jun 4 13:11:47 2017 From: jgbm at acm.org (J. Garrett Morris) Date: Sun, 4 Jun 2017 14:11:47 +0100 Subject: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families] In-Reply-To: <5933f655.1b3.56bb.27371@clear.net.nz> References: <5933f655.1b3.56bb.27371@clear.net.nz> Message-ID: On Sun, Jun 4, 2017 at 1:00 PM, Anthony Clayden wrote: > Ok what was the fault in the 2010 paper? You have reiterated a point that is made at length in §3.2 of my 2015 paper, and §3.4.2 of my dissertation. I shouldn't, however, have suggested in 2015 that the deduplicated version is necessarily preferable. If you omit the deduplication constraints, you simply end up with Leijen-style scoped rows [Leijen, TFP05] instead of Rémy-Wand style rows. Of course, if, as we did in 2010, you use classes instead of branching to implement elimination on variants, you have no way to tell the difference between the two models of variants, and so there's no reason to prefer one or the other. > I'm working on showing how the Swierstra encoding > could be catered for in Haskell 2010 + MPTCs+TypeEq. You keep talking about guarding instances or equations. Guards are equivalent to closed type families, so of course they're sufficient to implement Swierstra's encoding (following any of Bahr or Oliveira et al. or my approaches), and will require auxiliary definitions and indirections that would not be required using instance chains. This conversation having precisely reattained its starting point, I don't imagine I could contribute further. /g -- Prosperum ac felix scelus virtus vocatur -- Seneca From anthony_clayden at clear.net.nz Sun Jun 4 13:38:47 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 05 Jun 2017 01:38:47 +1200 Subject: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families] Message-ID: <59340d67.367.33d2.23529@clear.net.nz> > On Sun Jun 4 12:00:21 UTC 2017, Anthony Clayden wrote: > I think this shows that using class instances > to both define methods and drive selection logic > can fail to separate concerns. Richard's been (quite correctly) prodding me to explain why I want a no-instance in places, rather than an `instance ,,, fails` or `instance (TypeError ... ) => ...` I think Figure 7 in Garrett's 2015 paper provides a case in point. I find that `type family Ifi` and its call line 5/6 above to be more like an exercise in obfuscated type-programming. `type family Into` doesn't observe kind-hygiene in the way we'd expect a term-level function to observe type-hygiene. Type families `Into` or Ifi` might properly return: * Refl | L lp | R rp -- that could be a DataKind (where `lp` or `rp` is from a recursive call to `Into`) * or `Nope` -- which is a Boolean DataKind (yeuch) Yes `Into` does need to chase down the data structure in order to return the correct L/R accessor. But it doesn't need to also encode failure in that way. The frustrating thing (for me as reader) is `type family IsIn` is looking ahead inside the data structure to find `f`. Isn't that enough lookahead and error detection? I want there to be no equation for `Into` returning `Nope`. So I want no Line 7, nor line 10, 13 in `type family Ifi`. I think I'd tackle it this way. Instead of `type family IsIn` returning a Boolean, > type family CountF f g :: Nat where > CountF f f = (S Z) > CountF f (g :+: h) = Plus (CountF f g) (CountF f h) > CountF f g = Z Then for `Into` I'd use a count-preparing helper function, (instead of `Ifi`) and avoid those `Nope` returns: > type family Into f g where > Into f f = Refl > Into f (g :+: h) = IntoLR f (g :+: h) (CountF f g) (CountF f h) > -- no fail case needed > > type family IntoLR f g (cg :: Nat) (ch :: Nat) > type instance Into' f (g :+: h) (S Z) Z = L (Into f g) > type instance Into' f (g :+: h) Z (S Z) = R (Into f h) > -- no fail case needed, no overlap, so not closed So if the counts return {Z, Z} or {S Z, S Z} or {S (S (S Z)), S (S (S (S Z)))}, etc, there's simply no instance for `IntoLR`. (If you want a helpful error message, of course easy enough to add failure instances.) For completeness, I'll give the Instance Guard version for `CountF` and `Into`: > type family {-# INSTANCEGUARD #-} CountF f g :: Nat > type instance CountF f f = (S Z) > type instance CountF f (g :+: h) | f /~ (g :+: h) > = Plus (CountF f g) (CountF f h) > type instance CountF f g | f /~ g, g /~ (_ :+: _) = Z > type family {#- INSTANCEGUARD -#} Into f g > type instance Into f f = Refl > type instance Into f (g :+: h) | f /~ (g :+: h) > = IntoLR f (g :+: h) (CountF f g) (CountF f h) Those families/instances could be Associated types, grounded in the class instances (also guarded). Now I can see my way to translating this into Haskell 2010. AntC From michael at snoyman.com Sun Jun 4 15:17:09 2017 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 4 Jun 2017 18:17:09 +0300 Subject: [Haskell-cafe] Different results when building wxHaskell on Cabal and Stack In-Reply-To: References: Message-ID: It's impossible to say why the results are different in this case without more information. For example: * Where did you install wxWidgets? * How did you modify PATH? Did you modify any other env vars? * How did you install Cabal and GHC? * How are you setting env vars? Are you sure Stack is seeing the same values as cabal? * Are you using the same versions of libraries and compilers with Stack and Cabal? * What error message are you seeing? I can't say that I've personally installed wxWidgets recently (on any OS actually), so I don't have personal experience to back it up. But with other libraries (like libicu), I've found that the easiest thing with Stack is to use msys2 and pacman to install the system libraries. As an example, see this tweet[1]. Michael [1] https://twitter.com/snoyberg/status/638359459304239104 On Sun, Jun 4, 2017 at 4:03 PM, Yotam Ohad wrote: > Hello cafe, > Lately, I wanted to try wxHaskell, so I downloaded and install wxWidgets > and added the necessary paths to %PATH%. The problem was that when trying > to build, cabal would have no problem at all, while stack sends me into > battle with my path, complaining about missing header and executable files > and so on. > > I don't understand why stack is having such a hard time when cabal has no > trouble at all. I know that they are not the same, but I still think that > it is weird that stack is acting like that. > > Thanks for your help, > Yotam > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 anthony_clayden at clear.net.nz Mon Jun 5 01:11:00 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 05 Jun 2017 13:11:00 +1200 Subject: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families] Message-ID: <5934afa4.99.3e0c.1482@clear.net.nz> > On Sun Jun 4 13:11:47 UTC 2017, J. Garrett Morris wrote: >> On Sun, Jun 4, 2017 at 1:00 PM, Anthony Clayden wrote: >> ... > You have reiterated a point that is made at length ... Good, so we're agreed that the 2010 paper is inconsistent to reject `(f :+: f)` but accept `((f :+: f) :+: f)`. > I shouldn't, however, have suggested in 2015 that > the deduplicated version is necessarily preferable. I don't follow. The 2015 version is consistent. > If you omit the deduplication constraints, you simply end > up with Leijen-style scoped rows [Leijen, TFP05] ... Ouch! Its "A novel aspect of this work is that records can contain duplicate labels, " is about the most blood-chilling claim I've seen in the many papers on records systems. It is true, though, compared to what you seem to suggest "effectively introducing a form of scoping over the labels. " If `((f :+: g) :+: (h :+: f))` is to be supported, what's the basis for preferring `f` to the left or right? > ... Of course, if, as we did in 2010, you use classes instead > of branching to implement elimination on variants, you have no way to > tell the difference between the two models of variants, .. Is the only point I was wanting to make: using a single class fails to separate concerns, in this example. >> I'm working on showing how the Swierstra encoding >> could be catered for in Haskell 2010 + MPTCs+TypeEq. > You keep talking about guarding instances or equations. > Guards are equivalent to closed type families, I think not. They're somewhere between CTFs and Instance Chains. In that guarded instances are not closed. Which also appears to be your claim wrt Instance Chains. > ... so of course they're sufficient to implement > Swierstra's encoding (following any of ...), (I was specifically aiming to implement using Haskell as at 2010, but let it pass ...) Yes any of these approaches are "sufficient". That's not in debate. > and will require auxiliary definitions and indirections Yes, see code I posted subsequent to your message. > that would not be required using instance chains. Huh? Your 2015 paper uses auxiliaries class `In` Figure 3 in the Instance Chains version. True that the 2010 paper uses no auxiliaries, but it thereby ends up inconsistent. What is "wrong" with using auxiliaries? (Again, in terms of readability.) AntC From ivan.miljenovic at gmail.com Mon Jun 5 02:58:05 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 5 Jun 2017 12:58:05 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: I don't think it's a problem with Cabal, but the version of base going by the error: versionBranch is from base, and that error message is talking about compiling the setup.hs from wxc. On 5 June 2017 at 12:03, Henk-Jan van Tuyl wrote: > > The strange thing is, that the right version of Cabal is picked, the first > time wxc is compiled. But when invoking cabal-install the second time, the > setup-depends section seems to be ignored (or at least the Cabal < 2 part). > This does not happen with GHC 8.0.2 > > (By the way, cabal-install tries to compile setup.hs again, even though > nothing has changed.) > > Regards, > Henk-Jan van Tuyl > > > > On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic > wrote: > >> This is from a limitation/bug with Cabal-the-library, in that there >> are typically no dependency checks for custom Setup.[l]hs >> configurations. >> >> wxc has such a custom one: >> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >> >> versionBranch is from Data.Version in base, and it appears that the in >> this GHC pre-release there's been a change in base that removed this >> function. >> >> On 4 June 2017 at 19:45, Henk-Jan van Tuyl wrote: >>> >>> >>> L.S., >>> >>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>> >>> I adapted wxHaskell to the new packages that come with the new GHC and it >>> compiles now, but only the first time. If I compile it a second time, >>> even >>> if nothing has changed, the information from the custom-setup section of >>> the wxc.cabal file seems to be forgotten. This section looks like this: >>> >>> custom-setup >>> setup-depends: >>> base, >>> Cabal < 2, >>> containers, >>> bytestring, >>> split, >>> process, >>> directory, >>> filepath >>> (I am using cabal-install 1.24.0.2) >>> >>> Output from the second time I try to install wxHaskell: >>> >>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>> >>> >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>> [1 of 1] Compiling Main ( >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>> >>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>> Variable not in scope: versionBranch :: Version -> >>> [a0] >>> | >>> 505 | full_ver = (concat . intersperse "." . map show . >>> versionBranch) ver >>> | >>> ^^^^^^^^^^^^^ >>> >>> This error message indicates that the wrong version of Cabal (2.0) is >>> used >>> to compile the wxcore setup.hs >>> It looks like a cabal-install bug, but this does not happen when I >>> use GHC 8.0.2; should I write a GHC bug ticket? >>> >>> Regards, >>> Henk-Jan van Tuyl > > > > -- > 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://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From rae at cs.brynmawr.edu Mon Jun 5 03:15:32 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 4 Jun 2017 23:15:32 -0400 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <5933bf88.1c2.247.27284@clear.net.nz> References: <5933bf88.1c2.247.27284@clear.net.nz> Message-ID: <3C1BF244-508E-4339-8FEB-AC08B970BF3B@cs.brynmawr.edu> > On Jun 4, 2017, at 4:06 AM, Anthony Clayden wrote: > > OK, concrete example: I'm afraid I don't see the concrete example. I was expecting an example of how today's TypeError doesn't work for you. But it looks like the example you give is one motivating instance guards... but I'm not quite sure of that, either. I find these examples are clearest when they include code that you want to write, but can't; or code that behaves a certain way, but you want different behavior. And indeed maybe that's in your example, but I didn't see it. Thanks, Richard From anthony_clayden at clear.net.nz Mon Jun 5 06:25:32 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 05 Jun 2017 18:25:32 +1200 Subject: [Haskell-cafe] Instance Chains selection by class membership [was: [ghc-proposals/cafe] Partially applied type families] Message-ID: <5934f95c.f7.400.22704@clear.net.nz> > > On Sun Jun 4 13:11:47 UTC 2017, J. Garrett Morris wrote: > > ... > > You keep talking about guarding instances or equations. > > Guards are equivalent to closed type families, > > I think not. They're somewhere between CTFs and Instance > Chains. > In that guarded instances are not closed. > Which also appears to be your claim wrt Instance Chains. > A further difference is wrt class instances and FunDeps. AFAICT, the closed class instances/Partiality paper is expecting no FunDeps, but using Assoc types within the class to achieve the same effect. I agree with that long-term aim, so the following applies to both guarded class instances and guarded type instances. The dreaded "Instances inconsistent with FunDeps" error can be boiled down to: > class TypeEq a b p | a b -> p > instance TypeEq a a HTrue > instance TypeEq a b HFalse The check for FunDep consistency unifies the class parameters on LHS of FunDep, yielding subsititution { a ~ b }. Then applies that substitution to rhs. yielding { HTrue ~ HFalse } doesn't hold, so inconsistency. GHC allows you to put this instead: > instance TypeEq a a HTrue -- same > instance (p ~ HFalse) => TypeEq a b p The consistency test compares { p ~ HTrue }, and apparently sees those as unifiable, despite the (~ HFalse) constraint. There are those [for example, Iavor], who think this should still count as inconsistent. So it works (and has consistently since 2004), but seems iffy. Furthermore the bare typevar `p` breaks the Coverage Conditions, (again despite the (~ HFalse) constraint grr! So you need UndecidableInstances, which apparently is not as benign as heretofore thought. With InstanceGuards it goes like this: class {-# INSTANCEGUARDS #-} TypeEq a b p | a b -> p instance TypeEq a a HTrue -- same instance TypeEq a b HFalse | a /~ b Now the consistency check: unifies the class parameters on lhs of FunDep, yielding { a ~ b } as before; then substitutes into the guard, yielding { a /~ a } -- a contradiction. So it doesn't need to check the consistency of the result. Because the 'arguments' to the FunDep are apart. Notice the side-benefit: by putting explicit HFalse, we haven't broken the Coverage Conditions, so don't need UndecidableInstances. The guarded type family goes likewise: > type family {-# INSTANCEGUARDS #-} Equals a b :: Bool > type instance Equals a a = True > type instance Equals a b | a /~ b = False AntC From siddu.druid at gmail.com Mon Jun 5 13:46:12 2017 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Mon, 05 Jun 2017 13:46:12 +0000 Subject: [Haskell-cafe] STG Program to invoke rule 17? Message-ID: I'm reading the original STG paper and implementing it along the way. (Raw link to paper: https://www.dcc.fc.up.pt/~pbv/aulas/linguagens/peytonjones92implementing.pdf ) I'm not able to figure out how to invoke rule 17 at all. This rule is to update a function call which calls another function. I've tried creating examples, but all of them wind up invoking the constructor update rule. ╰─$ cat stg-programs/updatable-fn-calls.stg define nu = {} \n {x, y, w, z} -> x {}; define main = {} \n {} -> let x = {} \n {} -> One {}; y = {} \n {} -> Two {}; // closure to update update = {x, y} \u {} -> nu {x, y, y, y}; // have something in argument stack kickstart = {update} \n {a, b} -> update {}; // make sure this is never evaluated bottom = {} \n {} -> bottom {} in case (kickstart {bottom, bottom}) of One {} -> Done {}; This was a program I tried, hoping that the "kickstart" function would ensure that there is something on the argument stack, so that when "nu" is entered, the rule would trigger. However, in my toy STG implementation here (simplexhc link) (Raw: https://github.com/bollu/simplexhc), the rule is not triggered. You can run it with: $ stack build && stack exec simplexhc -- stg-programs/updatable-fn-calls.stg I believe I have either misunderstood the rule or mis-implemented it. So if someone could point me to a reference of how to trigger the rule, I'd be very thankful. I'd like to have some intuition on the rule and "why it works". Cheers, ~ Siddharth -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Mon Jun 5 22:33:40 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 6 Jun 2017 08:33:40 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: On 6 June 2017 at 07:55, Henk-Jan van Tuyl wrote: > > wxc/setup.hs uses versionBranch from Cabal[0]; the function versionBranch is > not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When > installing wxc the first time, the right version of Cabal is picked, when > "cabal install" is invoked a second time, GHC tries to compile wxc/setup.hs > again, but with the wrong version of Cabal (note: the release candidate of > GHC comes with Cabal 2) > > [0] > https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.html#v:versionBranch If you look at the source for this module, you'll see that it isn't defined in there; it's actually from Data.Version in base. > > > > On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic > wrote: > >> I don't think it's a problem with Cabal, but the version of base going >> by the error: versionBranch is from base, and that error message is >> talking about compiling the setup.hs from wxc. >> >> On 5 June 2017 at 12:03, Henk-Jan van Tuyl wrote: >>> >>> >>> The strange thing is, that the right version of Cabal is picked, the >>> first >>> time wxc is compiled. But when invoking cabal-install the second time, >>> the >>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>> part). >>> This does not happen with GHC 8.0.2 >>> >>> (By the way, cabal-install tries to compile setup.hs again, even though >>> nothing has changed.) >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>> wrote: >>> >>>> This is from a limitation/bug with Cabal-the-library, in that there >>>> are typically no dependency checks for custom Setup.[l]hs >>>> configurations. >>>> >>>> wxc has such a custom one: >>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>> >>>> versionBranch is from Data.Version in base, and it appears that the in >>>> this GHC pre-release there's been a change in base that removed this >>>> function. >>>> >>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl wrote: >>>>> >>>>> >>>>> >>>>> L.S., >>>>> >>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>> >>>>> I adapted wxHaskell to the new packages that come with the new GHC and >>>>> it >>>>> compiles now, but only the first time. If I compile it a second time, >>>>> even >>>>> if nothing has changed, the information from the custom-setup section >>>>> of >>>>> the wxc.cabal file seems to be forgotten. This section looks like this: >>>>> >>>>> custom-setup >>>>> setup-depends: >>>>> base, >>>>> Cabal < 2, >>>>> containers, >>>>> bytestring, >>>>> split, >>>>> process, >>>>> directory, >>>>> filepath >>>>> (I am using cabal-install 1.24.0.2) >>>>> >>>>> Output from the second time I try to install wxHaskell: >>>>> >>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>>>> >>>>> >>>>> >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>> [1 of 1] Compiling Main ( >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>> >>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>> Variable not in scope: versionBranch :: Version >>>>> -> >>>>> [a0] >>>>> | >>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>> versionBranch) ver >>>>> | >>>>> ^^^^^^^^^^^^^ >>>>> >>>>> This error message indicates that the wrong version of Cabal (2.0) is >>>>> used >>>>> to compile the wxcore setup.hs >>>>> It looks like a cabal-install bug, but this does not happen when I >>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>> >>>>> Regards, >>>>> Henk-Jan van Tuyl > > > -- > 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://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ivan.miljenovic at gmail.com Mon Jun 5 22:37:53 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 6 Jun 2017 08:37:53 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: On 6 June 2017 at 08:33, Ivan Lazar Miljenovic wrote: > On 6 June 2017 at 07:55, Henk-Jan van Tuyl wrote: >> >> wxc/setup.hs uses versionBranch from Cabal[0]; the function versionBranch is >> not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When >> installing wxc the first time, the right version of Cabal is picked, when >> "cabal install" is invoked a second time, GHC tries to compile wxc/setup.hs >> again, but with the wrong version of Cabal (note: the release candidate of >> GHC comes with Cabal 2) >> >> [0] >> https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.html#v:versionBranch > > If you look at the source for this module, you'll see that it isn't > defined in there; it's actually from Data.Version in base. You can see this more specifically here: https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/src/Distribution-Version.html -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From code at funwithsoftware.org Mon Jun 5 23:25:29 2017 From: code at funwithsoftware.org (Patrick Pelletier) Date: Mon, 5 Jun 2017 16:25:29 -0700 Subject: [Haskell-cafe] [ANN] mercury-api-0.1.0.0 (for RFID readers) Message-ID: <947f5f0d-2ae3-0f97-9e80-2879d9c04a5e@funwithsoftware.org> https://hackage.haskell.org/package/mercury-api https://github.com/ppelleti/hs-mercury-api This package is a Haskell binding to the "Mercury API" C API for ThingMagic RFID readers. It is especially geared toward the SparkFun Simultaneous RFID Reader board, which uses ThingMagic's M6e Nano module, but it should work with other ThingMagic readers. (Though currently, only support for serial readers is compiled in.) Most of the function and type names are the same as their counterparts in the C API, with the TMR_ prefix dropped. For more in-depth, language-independent documentation of Mercury API, see Mercury API Programmers Guide, available from the "Manuals & Firmware" page, below. This package includes a copy of the Mercury API C library, so no external libraries are necessary. Several small bug fixes have been applied to the included version of the library. (I have submitted these patches upstream, but I don't know if or when they will be included in the official version.) The Haskell binding doesn't support background reads. I recommend that you just spawn a new Haskell thread and do foreground reads instead. Currently, only support for the serial reader is compiled in, but it probably wouldn't be too hard to enable LLRP support. (I don't have any way to test LLRP, however, as the M6e Nano doesn't support it.) On Mac OS X, be sure to use the serial device that starts with "/dev/cu.", not the serial device that starts with "/dev/tty.". Only some parameters and some tagops are currently supported in the Haskell binding. (There are a lot of them, and I only implemented the ones I needed.) If you need support for additional parameters or tagops, please file an issue in GitHub and I will add them. I have tested this package on Linux, Mac OS X, and Windows, using the SparkFun board. Additional resources: SparkFun Simultaneous RFID Reader: https://www.sparkfun.com/products/14066 ThingMagic Manuals & Firmware: http://www.thingmagic.com/index.php/manuals-firmware From anthony_clayden at clear.net.nz Tue Jun 6 02:48:27 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 06 Jun 2017 14:48:27 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <593617fb.2aa.14ea.15992@clear.net.nz> > On Mon Jun 5 03:15:32 UTC 2017, Richard Eisenberg wrote: > > On Jun 4, 2017, at 4:06 AM, Anthony Clayden wrote: > ... I find these examples are clearest when they > include code that you want to write, but can't; Haskellers are a bright bunch. If there's code they want to write but can't, they'll find a work-round; bless it as an 'idiom'; publish a couple of papers; and make a virtue out of necessity. Looking at the HList library as is today. It's almost unrecognisable compared to the 2004 paper. It is in fact using the same techniques, but they're entirely obscured in work-rounds. There's no longer overlapping instances except in one class/in its own module. viz the type-level type equality test, returning Boolean. > ... I was expecting an example of how today's > TypeError doesn't work for you. The classic place in HList where TypeError (used to be) unavoidable is the `Lacks` predicate. Validate that an HList does _not_ contain element type `e`: > class HLacks e l > instance HLacks e HNil > instance (TypeError e) => HLacks e (HCons e l') > instance (HLacks e l') => HLacks e (HCons e' l') The sole purpose of that type-equal/TypeError instance, is to 'shadow' the type-different instance. That's nowadays avoidable: > -- class and HNil instance same > instance (TypeEq e e' b, HLacksCase b e l') > => HLacks e (HCons e' l') -- catch-all HCons > class HLacksCase b e l' > instance (HLacks e l') => HLacksCase False e l' > instance (TypeError e) => HLacksCase True e l' -- this now optional So every class in the HList library now has a catch-all HCons instance, with a call to the type equality test, and a case-despatching auxiliary class. It is semantically robust. I suppose you get used to the idiom. But in terms of helping type-level programming look like term-level programming, it's obtuse. (All that InstanceGuards are aimed at is blessing this idiom with some syntax sugar, so it looks like term-level guards.) And HList is working one element at a time, as it recursively descends into the list. The TypeError technique doesn't scale. What I really want to do is use 'flat' tuples as type-indexed anonymous/extensible records, putting newtypes to label the payloads: > me = (PersonId 41, PersonName "AntC") Again we must prevent repeated types: > notme = (PersonId 41, PersonName "AntC", PersonId 72) > class TIPle t -- Type Indexed Product tuples > instance TIPle (e1, e2) -- I just want e1 /~ e2, so: > instance (TypeError e1) => (e1, e1) -- exclude repeats This approach doesn't scale. Take the threeple: > instance (TypeError e1) => TIPle (e1, e1, e3) > instance (TypeError e1) => TIPle (e1, e2, e1) > instance (TypeError e2) => TIPle (e1, e2, e2) > instance TIPle (e1, e2, e3) -- OK, elements distinct by elimination Arguably I should also have > instance (TypeError e1) => (e1, e1, e1) The fourple case needs 6, arguably 9 exclusionary instances. I could use the nowadays HList idiom: > instance (TypeEq e1 e2 b1, TypeEq e1 e3 b2, TypeEq e2 e3 b3, > TIPleCase (b1, b2, b3) (e1, e2, e3) ) > => TIPle (e1, e2, e3) > instance TIPleCase (False, False, False) (e1, e2, e3) > -- TypeError instance(s) optional Perhaps I could use a type family with (~) constraint > instance (Equal e1 e2 ~ False, Equal e1 e3 ~ False, Equal e2 e3 ~ False) > => TIPle (e1, e2, e3) Note I've only talked so far about validating a TIPle, we want a whole bunch of methods for extending/projecting/ merging and comparing TIPles, and the classic record subtype relationship. With classes over two TIPLes there's a combinatorial explosion. So what you do is convert tuples to HLists, do all the operations on the HList, convert the result back to tuple. > > OK, concrete example: > > I'm afraid I don't see the concrete example. > But it looks like the example you give is one > motivating instance guards... It was trying to show: with CTFs (and presumably closed classes) there's an explicit or implicit TypeError catch-all instance at the end of the chain of `else`s. (It seems InstanceChain `fails` doesn't suffer this.) So the example showed I _didn't_ want that behaviour. AntC From mail at athiemann.net Tue Jun 6 07:43:53 2017 From: mail at athiemann.net (Alexander Thiemann) Date: Tue, 06 Jun 2017 09:43:53 +0200 Subject: [Haskell-cafe] [ANN] Schedule for Haskell Hackathon in Freiburg, Germany Message-ID: <1496735033.817377.1000072728.56440E53@webmail.messagingengine.com> Dear Haskellers, the schedule for the Haskell Hackathon taking place in Freiburg, Germany this year is now online ( https://wiki.haskell.org/HacFreiburg2017 ) and we still have spots available. Register here: https://goo.gl/LDIQlw == Details: When: Friday 4 August 2017 - Sunday 6 August 2017 Where: Faculty of Engineering, University of Freiburg, Germany (https://goo.gl/maps/ZcHWLpMPhtj)Info page: https://wiki.haskell.org/HacFreiburg2017 Organizers: Peter Thiemann, Alexander Thiemann, Stefan Wehr == HacFreiburg is another Haskell Hackathon, where Haskell programmers from all around the world meet in Freiburg, Germany, to discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! The Haskell Hackathon in Freiburg is part of the "Sommercampus 2017" (https://sommercampus.fachschaft.tf/en/), organized by the Faculty of Engineering at the University of Freiburg. Hope to see you there, Alex (with Peter and Stefan) -------------- next part -------------- An HTML attachment was scrubbed... URL: From siddu.druid at gmail.com Tue Jun 6 07:46:49 2017 From: siddu.druid at gmail.com (Siddharth Bhat) Date: Tue, 06 Jun 2017 07:46:49 +0000 Subject: [Haskell-cafe] Collecting examples where GHC generates unintuitive error messages Message-ID: Hello all, A discussion of GHC and error messages came up on ghc-devs. I'd like to give back to the community and try to improve this part of GHC. So, I created a repo to collect error messages ( https://github.com/bollu/hask-error-messages-catalog). That way, there's some concrete context for anyone who's working on the error messages subsystem of GHC. Elm does this as well (https://github.com/elm-lang/error-message-catalog), though they catalogue *all* errors. I'd be grateful for short examples where GHC generates unintuitive error messages, and perhaps a short explanation of what *would* be useful if possible. If you do have certain examples, please either open a pull request against the repository, or post a snippet on the mailing list. Thanks for the help, ~Siddharth -- Sending this from my phone, please excuse any typos! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Tue Jun 6 11:13:55 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Tue, 06 Jun 2017 13:13:55 +0200 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: You are right, versionBranch is from originally from base, but you are missing the point: package wxc compiles perfectly the first time, but, without anything being changed, does not compile the second time. By the way, I am using a cabal sandbox and as I said earlier, I am using a GHC release candidate. Regards, Henk-Jan van Tuyl On Tue, 06 Jun 2017 00:33:40 +0200, Ivan Lazar Miljenovic wrote: > On 6 June 2017 at 07:55, Henk-Jan van Tuyl wrote: >> >> wxc/setup.hs uses versionBranch from Cabal[0]; the function >> versionBranch is >> not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When >> installing wxc the first time, the right version of Cabal is picked, >> when >> "cabal install" is invoked a second time, GHC tries to compile >> wxc/setup.hs >> again, but with the wrong version of Cabal (note: the release candidate >> of >> GHC comes with Cabal 2) >> >> [0] >> https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.html#v:versionBranch > > If you look at the source for this module, you'll see that it isn't > defined in there; it's actually from Data.Version in base. > >> >> >> >> On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic >> wrote: >> >>> I don't think it's a problem with Cabal, but the version of base going >>> by the error: versionBranch is from base, and that error message is >>> talking about compiling the setup.hs from wxc. >>> >>> On 5 June 2017 at 12:03, Henk-Jan van Tuyl >>> wrote: >>>> >>>> >>>> The strange thing is, that the right version of Cabal is picked, the >>>> first >>>> time wxc is compiled. But when invoking cabal-install the second time, >>>> the >>>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>>> part). >>>> This does not happen with GHC 8.0.2 >>>> >>>> (By the way, cabal-install tries to compile setup.hs again, even >>>> though >>>> nothing has changed.) >>>> >>>> Regards, >>>> Henk-Jan van Tuyl >>>> >>>> >>>> >>>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>>> wrote: >>>> >>>>> This is from a limitation/bug with Cabal-the-library, in that there >>>>> are typically no dependency checks for custom Setup.[l]hs >>>>> configurations. >>>>> >>>>> wxc has such a custom one: >>>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>>> >>>>> versionBranch is from Data.Version in base, and it appears that the >>>>> in >>>>> this GHC pre-release there's been a change in base that removed this >>>>> function. >>>>> >>>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl wrote: >>>>>> >>>>>> >>>>>> >>>>>> L.S., >>>>>> >>>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>>> >>>>>> I adapted wxHaskell to the new packages that come with the new GHC >>>>>> and >>>>>> it >>>>>> compiles now, but only the first time. If I compile it a second >>>>>> time, >>>>>> even >>>>>> if nothing has changed, the information from the custom-setup >>>>>> section >>>>>> of >>>>>> the wxc.cabal file seems to be forgotten. This section looks like >>>>>> this: >>>>>> >>>>>> custom-setup >>>>>> setup-depends: >>>>>> base, >>>>>> Cabal < 2, >>>>>> containers, >>>>>> bytestring, >>>>>> split, >>>>>> process, >>>>>> directory, >>>>>> filepath >>>>>> (I am using cabal-install 1.24.0.2) >>>>>> >>>>>> Output from the second time I try to install wxHaskell: >>>>>> >>>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>>>>> >>>>>> >>>>>> >>>>>> [1 of 1] Compiling Main ( >>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>>> [1 of 1] Compiling Main ( >>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>>> >>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>>> Variable not in scope: versionBranch :: >>>>>> Version >>>>>> -> >>>>>> [a0] >>>>>> | >>>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>>> versionBranch) ver >>>>>> | >>>>>> ^^^^^^^^^^^^^ >>>>>> >>>>>> This error message indicates that the wrong version of Cabal (2.0) >>>>>> is >>>>>> used >>>>>> to compile the wxcore setup.hs >>>>>> It looks like a cabal-install bug, but this does not happen when I >>>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>>> >>>>>> Regards, >>>>>> Henk-Jan van Tuyl -- 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://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From S.J.Thompson at kent.ac.uk Tue Jun 6 11:27:11 2017 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Tue, 6 Jun 2017 12:27:11 +0100 Subject: [Haskell-cafe] Collecting examples where GHC generates unintuitive error messages In-Reply-To: References: Message-ID: <7471A32D-BF1A-49CE-A2EB-40C81B4BB349@kent.ac.uk> I did something like this for Hugs a long time ago. Not directly relevant, but might be of interest. Simon T. > On 6 Jun 2017, at 08:46, Siddharth Bhat wrote: > > Hello all, > > A discussion of GHC and error messages came up on ghc-devs. I'd like to give back to the community and try to improve this part of GHC. So, I created a repo to collect error messages (https://github.com/bollu/hask-error-messages-catalog ). That way, there's some concrete context for anyone who's working on the error messages subsystem of GHC. > > Elm does this as well (https://github.com/elm-lang/error-message-catalog ), though they catalogue *all* errors. > > I'd be grateful for short examples where GHC generates unintuitive error messages, and perhaps a short explanation of what *would* be useful if possible. If you do have certain examples, please either open a pull request against the repository, or post a snippet on the mailing list. > > Thanks for the help, > ~Siddharth > -- > Sending this from my phone, please excuse any typos! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.J.Thompson at kent.ac.uk Tue Jun 6 11:39:49 2017 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Tue, 6 Jun 2017 12:39:49 +0100 Subject: [Haskell-cafe] Collecting examples where GHC generates unintuitive error messages In-Reply-To: <7471A32D-BF1A-49CE-A2EB-40C81B4BB349@kent.ac.uk> References: <7471A32D-BF1A-49CE-A2EB-40C81B4BB349@kent.ac.uk> Message-ID: <25C6F0AE-D234-42D0-9B8D-DE89AF601CD7@kent.ac.uk> And here’s the link. Oops! https://www.cs.kent.ac.uk/people/staff/sjt/craft2e/errors.html S. > On 6 Jun 2017, at 12:27, Simon Thompson wrote: > > I did something like this for Hugs a long time ago. Not directly relevant, but might be of interest. > > Simon T. >> On 6 Jun 2017, at 08:46, Siddharth Bhat > wrote: >> >> Hello all, >> >> A discussion of GHC and error messages came up on ghc-devs. I'd like to give back to the community and try to improve this part of GHC. So, I created a repo to collect error messages (https://github.com/bollu/hask-error-messages-catalog ). That way, there's some concrete context for anyone who's working on the error messages subsystem of GHC. >> >> Elm does this as well (https://github.com/elm-lang/error-message-catalog ), though they catalogue *all* errors. >> >> I'd be grateful for short examples where GHC generates unintuitive error messages, and perhaps a short explanation of what *would* be useful if possible. If you do have certain examples, please either open a pull request against the repository, or post a snippet on the mailing list. >> >> Thanks for the help, >> ~Siddharth >> -- >> Sending this from my phone, please excuse any typos! >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > Simon Thompson | Professor of Logic and Computation > School of Computing | University of Kent | Canterbury, CT2 7NF, UK > s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ivan.miljenovic at gmail.com Tue Jun 6 12:32:45 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 6 Jun 2017 22:32:45 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: On 6 June 2017 at 21:13, Henk-Jan van Tuyl wrote: > > You are right, versionBranch is from originally from base, but you are > missing the point: > package wxc compiles perfectly the first time, but, without anything being > changed, does not compile the second time. By the way, I am using a cabal > sandbox and as I said earlier, I am using a GHC release candidate. And in that release candidate, does the version of base have versionBranch in it? My guess is that a new version of Cabal is being used the second time, which is compiled against the base that comes with that RC which is missing versionBranch. (But since I don't have any GHC RC's I can't check it myself.) > > Regards, > Henk-Jan van Tuyl > > > > On Tue, 06 Jun 2017 00:33:40 +0200, Ivan Lazar Miljenovic > wrote: > >> On 6 June 2017 at 07:55, Henk-Jan van Tuyl wrote: >>> >>> >>> wxc/setup.hs uses versionBranch from Cabal[0]; the function versionBranch >>> is >>> not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When >>> installing wxc the first time, the right version of Cabal is picked, when >>> "cabal install" is invoked a second time, GHC tries to compile >>> wxc/setup.hs >>> again, but with the wrong version of Cabal (note: the release candidate >>> of >>> GHC comes with Cabal 2) >>> >>> [0] >>> >>> https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.html#v:versionBranch >> >> >> If you look at the source for this module, you'll see that it isn't >> defined in there; it's actually from Data.Version in base. >> >>> >>> >>> >>> On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic >>> wrote: >>> >>>> I don't think it's a problem with Cabal, but the version of base going >>>> by the error: versionBranch is from base, and that error message is >>>> talking about compiling the setup.hs from wxc. >>>> >>>> On 5 June 2017 at 12:03, Henk-Jan van Tuyl >>>> wrote: >>>>> >>>>> >>>>> >>>>> The strange thing is, that the right version of Cabal is picked, the >>>>> first >>>>> time wxc is compiled. But when invoking cabal-install the second time, >>>>> the >>>>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>>>> part). >>>>> This does not happen with GHC 8.0.2 >>>>> >>>>> (By the way, cabal-install tries to compile setup.hs again, even though >>>>> nothing has changed.) >>>>> >>>>> Regards, >>>>> Henk-Jan van Tuyl >>>>> >>>>> >>>>> >>>>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>>>> wrote: >>>>> >>>>>> This is from a limitation/bug with Cabal-the-library, in that there >>>>>> are typically no dependency checks for custom Setup.[l]hs >>>>>> configurations. >>>>>> >>>>>> wxc has such a custom one: >>>>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>>>> >>>>>> versionBranch is from Data.Version in base, and it appears that the in >>>>>> this GHC pre-release there's been a change in base that removed this >>>>>> function. >>>>>> >>>>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> L.S., >>>>>>> >>>>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>>>> >>>>>>> I adapted wxHaskell to the new packages that come with the new GHC >>>>>>> and >>>>>>> it >>>>>>> compiles now, but only the first time. If I compile it a second time, >>>>>>> even >>>>>>> if nothing has changed, the information from the custom-setup section >>>>>>> of >>>>>>> the wxc.cabal file seems to be forgotten. This section looks like >>>>>>> this: >>>>>>> >>>>>>> custom-setup >>>>>>> setup-depends: >>>>>>> base, >>>>>>> Cabal < 2, >>>>>>> containers, >>>>>>> bytestring, >>>>>>> split, >>>>>>> process, >>>>>>> directory, >>>>>>> filepath >>>>>>> (I am using cabal-install 1.24.0.2) >>>>>>> >>>>>>> Output from the second time I try to install wxHaskell: >>>>>>> >>>>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1 of 1] Compiling Main ( >>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>>>> [1 of 1] Compiling Main ( >>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>>>> >>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>>>> Variable not in scope: versionBranch :: Version >>>>>>> -> >>>>>>> [a0] >>>>>>> | >>>>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>>>> versionBranch) ver >>>>>>> | >>>>>>> ^^^^^^^^^^^^^ >>>>>>> >>>>>>> This error message indicates that the wrong version of Cabal (2.0) is >>>>>>> used >>>>>>> to compile the wxcore setup.hs >>>>>>> It looks like a cabal-install bug, but this does not happen when I >>>>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>>>> >>>>>>> Regards, >>>>>>> Henk-Jan van Tuyl > > > > -- > 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://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From kei at lanl.gov Tue Jun 6 13:59:50 2017 From: kei at lanl.gov (Kei Davis) Date: Tue, 6 Jun 2017 07:59:50 -0600 Subject: [Haskell-cafe] STG Program to invoke rule 17? In-Reply-To: References: Message-ID: <27b464af-336e-1956-56d4-07c037a31764@lanl.gov> On 06/06/2017 06:00 AM, haskell-cafe-request at haskell.org wrote: > [Haskell-cafe] STG Program to invoke rule 17? This isn't a proper answer to your question, but I found the "fast curry" paper to be more useful for understanding STG http://community.haskell.org/~simonmar/papers/evalapplyjfp06.pdf -- Kei Davis Applied Computer Science Group CCS-7, Mail Stop B287 Los Alamos National Laboratory Los Alamos, NM 87545, U.S.A. From rae at cs.brynmawr.edu Tue Jun 6 19:22:45 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 6 Jun 2017 15:22:45 -0400 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families In-Reply-To: <593617fb.2aa.14ea.15992@clear.net.nz> References: <593617fb.2aa.14ea.15992@clear.net.nz> Message-ID: <15617E14-0CE2-4255-9B2B-A5DE7E97BB8F@cs.brynmawr.edu> > On Jun 5, 2017, at 10:48 PM, Anthony Clayden wrote: > > It was trying to show: > with CTFs (and presumably closed classes) > there's an explicit or implicit TypeError catch-all instance > at the end of the chain of `else`s. > (It seems InstanceChain `fails` doesn't suffer this.) As I understand it: You've said that TypeError doesn't work for you. I asked why, looking for a concrete example of how things go wrong. I do see your example of why instance guards can help (already convinced there)... but I still don't see why TypeError is problematic once we have instance guards. Richard From ivan.miljenovic at gmail.com Tue Jun 6 22:53:20 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 7 Jun 2017 08:53:20 +1000 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: On 6 June 2017 at 23:27, Henk-Jan van Tuyl wrote: > > versionBranch is still in base, but it is not compatible with Cabal 2. You mean it isn't re-exported by Cabal-2? Then maybe wxc's Setup.hs needs to explicitly import Data.Version from base rather than relying upon the re-export. > > Regards, > Henk-Jan van Tuyl > > > > > On Tue, 06 Jun 2017 14:32:45 +0200, Ivan Lazar Miljenovic > wrote: > >> On 6 June 2017 at 21:13, Henk-Jan van Tuyl wrote: >>> >>> >>> You are right, versionBranch is from originally from base, but you are >>> missing the point: >>> package wxc compiles perfectly the first time, but, without anything >>> being >>> changed, does not compile the second time. By the way, I am using a cabal >>> sandbox and as I said earlier, I am using a GHC release candidate. >> >> >> And in that release candidate, does the version of base have >> versionBranch in it? >> >> My guess is that a new version of Cabal is being used the second time, >> which is compiled against the base that comes with that RC which is >> missing versionBranch. >> >> (But since I don't have any GHC RC's I can't check it myself.) >> > > > >>> >>> Regards, >>> Henk-Jan van Tuyl >>> >>> >>> >>> On Tue, 06 Jun 2017 00:33:40 +0200, Ivan Lazar Miljenovic >>> wrote: >>> >>>> On 6 June 2017 at 07:55, Henk-Jan van Tuyl >>>> wrote: >>>>> >>>>> >>>>> >>>>> wxc/setup.hs uses versionBranch from Cabal[0]; the function >>>>> versionBranch >>>>> is >>>>> not in Cabal 2, that is why I added "Cabal < 2" to wxc.cabal. When >>>>> installing wxc the first time, the right version of Cabal is picked, >>>>> when >>>>> "cabal install" is invoked a second time, GHC tries to compile >>>>> wxc/setup.hs >>>>> again, but with the wrong version of Cabal (note: the release candidate >>>>> of >>>>> GHC comes with Cabal 2) >>>>> >>>>> [0] >>>>> >>>>> >>>>> https://hackage.haskell.org/package/Cabal-1.24.2.0/docs/Distribution-Make.html#v:versionBranch >>>> >>>> >>>> >>>> If you look at the source for this module, you'll see that it isn't >>>> defined in there; it's actually from Data.Version in base. >>>> >>>>> >>>>> >>>>> >>>>> On Mon, 05 Jun 2017 04:58:05 +0200, Ivan Lazar Miljenovic >>>>> wrote: >>>>> >>>>>> I don't think it's a problem with Cabal, but the version of base going >>>>>> by the error: versionBranch is from base, and that error message is >>>>>> talking about compiling the setup.hs from wxc. >>>>>> >>>>>> On 5 June 2017 at 12:03, Henk-Jan van Tuyl >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The strange thing is, that the right version of Cabal is picked, the >>>>>>> first >>>>>>> time wxc is compiled. But when invoking cabal-install the second >>>>>>> time, >>>>>>> the >>>>>>> setup-depends section seems to be ignored (or at least the Cabal < 2 >>>>>>> part). >>>>>>> This does not happen with GHC 8.0.2 >>>>>>> >>>>>>> (By the way, cabal-install tries to compile setup.hs again, even >>>>>>> though >>>>>>> nothing has changed.) >>>>>>> >>>>>>> Regards, >>>>>>> Henk-Jan van Tuyl >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, 04 Jun 2017 13:39:17 +0200, Ivan Lazar Miljenovic >>>>>>> wrote: >>>>>>> >>>>>>>> This is from a limitation/bug with Cabal-the-library, in that there >>>>>>>> are typically no dependency checks for custom Setup.[l]hs >>>>>>>> configurations. >>>>>>>> >>>>>>>> wxc has such a custom one: >>>>>>>> http://hackage.haskell.org/package/wxc-0.92.3.0/src/Setup.hs >>>>>>>> >>>>>>>> versionBranch is from Data.Version in base, and it appears that the >>>>>>>> in >>>>>>>> this GHC pre-release there's been a change in base that removed this >>>>>>>> function. >>>>>>>> >>>>>>>> On 4 June 2017 at 19:45, Henk-Jan van Tuyl >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> L.S., >>>>>>>>> >>>>>>>>> I am trying the prerelease of GHC, version 8.2.0.20170507 >>>>>>>>> >>>>>>>>> I adapted wxHaskell to the new packages that come with the new GHC >>>>>>>>> and >>>>>>>>> it >>>>>>>>> compiles now, but only the first time. If I compile it a second >>>>>>>>> time, >>>>>>>>> even >>>>>>>>> if nothing has changed, the information from the custom-setup >>>>>>>>> section >>>>>>>>> of >>>>>>>>> the wxc.cabal file seems to be forgotten. This section looks like >>>>>>>>> this: >>>>>>>>> >>>>>>>>> custom-setup >>>>>>>>> setup-depends: >>>>>>>>> base, >>>>>>>>> Cabal < 2, >>>>>>>>> containers, >>>>>>>>> bytestring, >>>>>>>>> split, >>>>>>>>> process, >>>>>>>>> directory, >>>>>>>>> filepath >>>>>>>>> (I am using cabal-install 1.24.0.2) >>>>>>>>> >>>>>>>>> Output from the second time I try to install wxHaskell: >>>>>>>>> >>>>>>>>>> cabal install --force-reinstalls --reinstall wxdirect wxc wxcore >>>>>>>>>> wx >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1 of 1] Compiling Main ( >>>>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >>>>>>>>> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >>>>>>>>> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >>>>>>>>> [1 of 1] Compiling Main ( >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >>>>>>>>> >>>>>>>>> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >>>>>>>>> Variable not in scope: versionBranch :: >>>>>>>>> Version >>>>>>>>> -> >>>>>>>>> [a0] >>>>>>>>> | >>>>>>>>> 505 | full_ver = (concat . intersperse "." . map show . >>>>>>>>> versionBranch) ver >>>>>>>>> | >>>>>>>>> ^^^^^^^^^^^^^ >>>>>>>>> >>>>>>>>> This error message indicates that the wrong version of Cabal (2.0) >>>>>>>>> is >>>>>>>>> used >>>>>>>>> to compile the wxcore setup.hs >>>>>>>>> It looks like a cabal-install bug, but this does not happen when I >>>>>>>>> use GHC 8.0.2; should I write a GHC bug ticket? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Henk-Jan van Tuyl > > > -- > 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://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming > -- -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ruben.astud at gmail.com Wed Jun 7 05:16:04 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Wed, 7 Jun 2017 01:16:04 -0400 Subject: [Haskell-cafe] Turtle library : grepping on Text vs FilePath Message-ID: <812c3667-ac96-380b-eca9-084aa4f74df9@gmail.com> Dear list On the Turtle library, the grep function got the following signature grep :: Pattern a -> Shell Line -> Shell Line For it to filter output of the `ls :: FilePath -> Shell FilePath` I got to fmap and transform via de Turtle.Format or Turtle.Line modules. Is this an indicator I shouldn't be doing this? Is the library telling me to use `find`? or is just accidental? -- -- Ruben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From joehillen at gmail.com Wed Jun 7 07:08:04 2017 From: joehillen at gmail.com (Joe Hillenbrand) Date: Wed, 7 Jun 2017 00:08:04 -0700 Subject: [Haskell-cafe] Turtle library : grepping on Text vs FilePath In-Reply-To: <812c3667-ac96-380b-eca9-084aa4f74df9@gmail.com> References: <812c3667-ac96-380b-eca9-084aa4f74df9@gmail.com> Message-ID: Is onFiles[1] what you're looking for? https://hackage.haskell.org/package/turtle-1.3.5/docs/Turtle-Prelude.html#v:onFiles On Tue, Jun 6, 2017 at 10:16 PM, Ruben Astudillo wrote: > Dear list > > On the Turtle library, the grep function got the following signature > > grep :: Pattern a -> Shell Line -> Shell Line > > For it to filter output of the `ls :: FilePath -> Shell FilePath` I got > to fmap and transform via de Turtle.Format or Turtle.Line modules. Is > this an indicator I shouldn't be doing this? Is the library telling me > to use `find`? or is just accidental? > > -- > -- Ruben > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ruben.astud at gmail.com Wed Jun 7 07:22:33 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Wed, 7 Jun 2017 03:22:33 -0400 Subject: [Haskell-cafe] Turtle library : grepping on Text vs FilePath In-Reply-To: References: <812c3667-ac96-380b-eca9-084aa4f74df9@gmail.com> Message-ID: <590b53ba-d322-23b7-b572-d4d05e2e571e@gmail.com> On 07/06/17 03:08, Joe Hillenbrand wrote: > Is onFiles[1] what you're looking for? > > https://hackage.haskell.org/package/turtle-1.3.5/docs/Turtle-Prelude.html#v:onFiles Almost. Grep operates over Shell Line. Line is just a newtype over Text. I still don't know if this is telling me "don't do that". > On Tue, Jun 6, 2017 at 10:16 PM, Ruben Astudillo wrote: >> Dear list >> >> On the Turtle library, the grep function got the following signature >> >> grep :: Pattern a -> Shell Line -> Shell Line >> >> For it to filter output of the `ls :: FilePath -> Shell FilePath` I got >> to fmap and transform via de Turtle.Format or Turtle.Line modules. Is >> this an indicator I shouldn't be doing this? Is the library telling me >> to use `find`? or is just accidental? >> >> -- >> -- Ruben >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -- -- Ruben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lexi.lambda at gmail.com Wed Jun 7 07:38:15 2017 From: lexi.lambda at gmail.com (Alexis King) Date: Wed, 7 Jun 2017 00:38:15 -0700 Subject: [Haskell-cafe] Encoding superclass relationships as a constraint? Message-ID: <834DB8D9-7992-4BCC-A058-0ABA6ACD4E35@gmail.com> Using ExistentialQuantification, it’s possible to create a rather generic type that packages some arbitrary dictionary up at runtime: data Some ctx = forall a. ctx a => Some a This is nice, but it’s not very interesting. It would be nice if we could define a Show instance for our type, and a naïve implementation is trivial: instance Show (Some Show) where show (Some x) = show x However, this isn’t very useful in practice, since it means we can only show values of precisely the type (Some Show), which are better represented as values of type String. However, we might reasonably have some class with Show as a superclass: class Show a => Foo a instance Foo () ...and we might want to show values of type (Some Foo). However, this won’t work with the naïve implementation, since Foo is not the same as Show. Clearly, what we want is some instance like this: instance (ctx ≈> Show) => Show (Some ctx) ...where (a ≈> b) can be read “a implies b”. Unfortunately, as far as I can tell, this isn’t actually possible in any general way. The closest thing I was able to come up with was a less general solution using Edward Kmett’s constraints package. It’s possible to write (≈>) with some manual boilerplate: import Data.Constraint import Data.Constraint.Forall class Class (ctx a) (ctx' a) => Class1' ctx ctx' a instance Class (ctx a) (ctx' a) => Class1' ctx ctx' a type Class1 ctx ctx' = Forall (Class1' ctx ctx') type a ≈> b = Class1 b a ...and then it’s possible to write that Show instance: instance (ctx ≈> Show) => Show (Some ctx) where show (Some (x :: a)) = case inst @(Class1' Show ctx) @a of Sub Dict -> case (cls :: ctx a :- Show a) of Sub Dict -> show x However, this means users have to manually implement Class instances for their classes. Using the above example of Foo, a user would have to write the following instance: instance Class (Show a) (Foo a) where cls = Sub Dict With that instance, we can properly show values of type (Some Foo): ghci> Some () :: Some Foo () But this instance is both trivial and annoying, since it means the machinery leaks out of the implementation code and into the code that uses it. I’m wondering if there’s any way to do this more generally, and if not, if there’s any reason it could not or should not be supported by GHC itself. Alexis From S.J.Thompson at kent.ac.uk Wed Jun 7 09:57:39 2017 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Wed, 7 Jun 2017 10:57:39 +0100 Subject: [Haskell-cafe] Call for participation: Trends in Functional Programming in Education 2015 (in association with TFP 2017) Message-ID: Trends in Functional Programming in Education, 2017 Call for participation https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/ Programme timings https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/TFPIE_2017/Programme.html The sixth workshop on Trends in Functional Programming in Education, 2017, which is to be held on the Canterbury campus of the University of Kent on Thursday, 22 June. Registration is included with that for TFP 2017, 19–21 June. Morning: functional programming and online learning A particular topic of this year's TFPIE will be MOOCs and other online learning and we've managed to gather people from most of the current MOOCs in functional programming to come to an informal symposium. Keynote: Heather Miller of EFPL and Northeastern University will begin the symposium by giving a keynote on this topic. Heather works on and around the Scala programming language and is Executive Director of the Scala Center. This will be followed by a presentation from Yann Régis-Gianas and Benjamin Canou about the MOOC on OCaml, and a round table discussion including Heather, the OCaml MOOC team, Jeremy Singer (Haskell), and Simon Thompson (Erlang). The morning will conclude with two regular presentations: - Stephen Adams. Teaching Erlang through the Internet: An Experience Report - Jeremy Singer and Blair Archibald. Functional Baby Talk: Analysis of Code Fragments from Novice Haskell Programmers Afternoon: TFPIE regular programme The afternoon will begin with a best lecture: Colin Runciman (York) on the topic of Purely Functional Queues The meeting will then have four regular presentations: - Marco T. Morazan. Vector Programming Using Structural Recursion - Curtis d'Alves, Tanya Bouman, Christopher Schankula, Jenell Hogg, Levin Noronha, Emily Horsman, Rumsha Siddiqui and Christopher K. Anand. Using Elm to Introduce Algebraic Thinking to K-8 Students - Hans-Wolfgang Loidl, Phil Barker and Sanusi Usman. Enhancing the Learning Experience on Programming-focused Courses via Electronic Assessment Tools (Extended Abstract) - Juan Carlos Saenz-Carrasco and Mike Stannett. Overcoming Non Distributivity: A Case Study in Functional Programming The meeting will conclude with a lightning talks session for attendees and others to give short talks about work in progress or projects that they would like to get started, followed by a plenary discussion on future directions for the community and the workshop. Programme committee Dr Laura Castro, University of A Coruña Prof Ralf Lämmel, University of Koblenz-Landau Dr Elena Machkasova, University of Minnesota, Morris Prof Michel Mauny, Inria, Paris Dr Jeremy Singer, University of Glasgow Prof Simon Thompson, University of Kent (chair) Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From lysxia at gmail.com Wed Jun 7 10:36:12 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Wed, 7 Jun 2017 06:36:12 -0400 Subject: [Haskell-cafe] Encoding superclass relationships as a constraint? In-Reply-To: <834DB8D9-7992-4BCC-A058-0ABA6ACD4E35@gmail.com> References: <834DB8D9-7992-4BCC-A058-0ABA6ACD4E35@gmail.com> Message-ID: <04626f44-f77e-b7a2-ce28-cd9b90b765c0@gmail.com> This ticket about "Quantified contexts" (forall a. ctx a => Show a) seems to be what you're looking for. https://ghc.haskell.org/trac/ghc/ticket/2893 On 06/07/2017 03:38 AM, Alexis King wrote: > Using ExistentialQuantification, it’s possible to create a rather > generic type that packages some arbitrary dictionary up at runtime: > > data Some ctx = forall a. ctx a => Some a > > This is nice, but it’s not very interesting. It would be nice if we > could define a Show instance for our type, and a naïve implementation > is trivial: > > instance Show (Some Show) where > show (Some x) = show x > > However, this isn’t very useful in practice, since it means we can only > show values of precisely the type (Some Show), which are better > represented as values of type String. However, we might reasonably have > some class with Show as a superclass: > > class Show a => Foo a > instance Foo () > > ...and we might want to show values of type (Some Foo). However, this > won’t work with the naïve implementation, since Foo is not the same as > Show. > > Clearly, what we want is some instance like this: > > instance (ctx ≈> Show) => Show (Some ctx) > > ...where (a ≈> b) can be read “a implies b”. Unfortunately, as far as I > can tell, this isn’t actually possible in any general way. > > The closest thing I was able to come up with was a less general solution > using Edward Kmett’s constraints package. It’s possible to write (≈>) > with some manual boilerplate: > > import Data.Constraint > import Data.Constraint.Forall > > class Class (ctx a) (ctx' a) => Class1' ctx ctx' a > instance Class (ctx a) (ctx' a) => Class1' ctx ctx' a > > type Class1 ctx ctx' = Forall (Class1' ctx ctx') > type a ≈> b = Class1 b a > > ...and then it’s possible to write that Show instance: > > instance (ctx ≈> Show) => Show (Some ctx) where > show (Some (x :: a)) = case inst @(Class1' Show ctx) @a of > Sub Dict -> case (cls :: ctx a :- Show a) of > Sub Dict -> show x > > However, this means users have to manually implement Class instances for > their classes. Using the above example of Foo, a user would have to > write the following instance: > > instance Class (Show a) (Foo a) where cls = Sub Dict > > With that instance, we can properly show values of type (Some Foo): > > ghci> Some () :: Some Foo > () > > But this instance is both trivial and annoying, since it means the > machinery leaks out of the implementation code and into the code that > uses it. I’m wondering if there’s any way to do this more generally, and > if not, if there’s any reason it could not or should not be supported > by GHC itself. > > Alexis > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ezyang at mit.edu Wed Jun 7 11:56:12 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Wed, 07 Jun 2017 07:56:12 -0400 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: Message-ID: <1496836395-sup-4284@sabre> This sounds like a Cabal bug to me. A few things to try: - Can you post a -v3 log of the second cabal install force reinstall somewhere? It sounds like we are incorrectly attempting to use the wrong version of Cabal to build the Setup script, and a -v3 log would help confirm. - Are you on Ubuntu? If you could install and test a cabal-install-head binary from https://launchpad.net/~hvr/+archive/ubuntu/ghc that would be helpful to find out if we've fixed this bug already. - If you want to file a bug, please do so in the Cabal bug tracker https://github.com/haskell/cabal/issues Thanks! Cheers, Edward Excerpts from Henk-Jan van Tuyl's message of 2017-06-04 11:45:58 +0200: > > L.S., > > I am trying the prerelease of GHC, version 8.2.0.20170507 > > I adapted wxHaskell to the new packages that come with the new GHC and it > compiles now, but only the first time. If I compile it a second time, even > if nothing has changed, the information from the custom-setup section of > the wxc.cabal file seems to be forgotten. This section looks like this: > > custom-setup > setup-depends: > base, > Cabal < 2, > containers, > bytestring, > split, > process, > directory, > filepath > (I am using cabal-install 1.24.0.2) > > Output from the second time I try to install wxHaskell: > > > cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx > [1 of 1] Compiling Main ( > X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, > X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) > Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... > [1 of 1] Compiling Main ( > X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, > X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) > > X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: > Variable not in scope: versionBranch :: Version -> > [a0] > | > 505 | full_ver = (concat . intersperse "." . map show . > versionBranch) ver > | > ^^^^^^^^^^^^^ > > This error message indicates that the wrong version of Cabal (2.0) is used > to compile the wxcore setup.hs > It looks like a cabal-install bug, but this does not happen when I > use GHC 8.0.2; should I write a GHC bug ticket? > > Regards, > Henk-Jan van Tuyl > > > -- > 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://Van.Tuyl.eu/ > http://members.chello.nl/hjgtuyl/tourdemonad.html > Haskell programming From m at jaspervdj.be Wed Jun 7 19:35:02 2017 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Wed, 7 Jun 2017 21:35:02 +0200 Subject: [Haskell-cafe] Last call for presentations: CUFP 2017, September 7-9, Oxford, UK Message-ID: <20170607193502.GA3211@colony6> The deadline for CUFP presentations is this friday, the 9th of June. This CFP and the form for submitting presentations proposals can be found at: http://cufp.org/2017/call-for-presentations.html ------------------------------------------------------------------------ 2017 Call for Presentations Workshop for Commercial Users of Functional Programming 2017 Sponsored by SIGPLAN CUFP 2017 Co-located with ICFP 2017 Oxford, UK September 7-9 Talk Proposal Submission Deadline: 9 June 2017 The annual CUFP event is a place where people can see how others are using functional programming to solve real world problems; where practitioners meet and collaborate; where language designers and users can share ideas about the future of their favorite language; and where one can learn practical techniques and approaches for putting functional programming to work. ------------------------------------------------------------------------ Giving a CUFP Talk If you have experience using functional languages in a practical setting, we invite you to submit a proposal to give a talk at the event. We're looking for two kinds of talks: Retrospective reports are typically 25 minutes long. Now that CUFP has run for more than a decade, we intend to invite past speakers to share what they’ve learned after a decade spent as commercial users of functional programming. We will favour experience reports that include technical content. Technical talks are also 25 minutes long, and should focus on teaching the audience something about a particular technique or methodology, from the point of view of someone who has seen it play out in practice. These talks could cover anything from techniques for building functional concurrent applications, to managing dynamic reconfigurations, to design recipes for using types effectively in large-scale applications. While these talks will often be based on a particular language, they should be accessible to a broad range of programmers. We strongly encourage submissions from people in communities that are underrepresented in functional programming, including but not limited to women; people of color; people in gender, sexual and romantic minorities; people with disabilities; people residing in Asia, Africa, or Latin America; and people who have never presented at a conference before. We recognize that inclusion is an important part of our ission to promote functional programming. So that CUFP can be a safe environment in which participants openly exchange ideas, we abide by the SIGPLAN Conference Anti-Harassment Policy: http://www.sigplan.org/Resources/Policies/Anti-harassment If you are interested in offering a talk, or nominating someone to do so, please submit your presentation before 09 June 2017 via the CUFP 2017 Presentation Submission Form: https://goo.gl/forms/KPloANxHHwdiaoVj2 You do not need to submit a paper, just a short proposal for your talk. There will be a short scribe's report of the presentations and discussions but not of the details of individual talks, as the meeting is intended to be more of a discussion forum than a technical interchange. Nevertheless, presentations will be recorded and presenters will be expected to sign an ACM copyright release form. Note that we will need presenters to register for the CUFP workshop and travel to Oxford at their own expense. There are some funds available to would-be presenters who require assistance in this respect. ------------------------------------------------------------------------ Program Committee Alex Lang (Tsuru Capital), co-chair Rachel Reese (Mulberry Labs), co-chair Garrett Smith (Guild AI) Danielle Sucher (Jane Street) Jasper Van der Jeugt (Fugue) Yukitoshi Suzuki (Ziosoft) Evelina Gabasova (University of Cambridge) Brian Mitchell (Jet.com) ------------------------------------------------------------------------ More information For more information on CUFP, including videos of presentations from previous years, take a look at the CUFP website at http://cufp.org. Note that presenters, like other attendees, will need to register for the event. Acceptance and rejection letters will be sent out by July 15th. Guidance on giving a great CUFP talk Focus on the interesting bits: Think about what will distinguish your talk, and what will engage the audience, and focus there. There are a number of places to look for those interesting bits. Setting: FP is pretty well-established in some areas, including formal verification, financial processing, and server-side web services. An unusual setting can be a source of interest. If you're deploying FP-based mobile UIs or building servers on oil rigs, then the challenges of that scenario are worth focusing on. Did FP help or hinder in adapting to the setting? Technology: The CUFP audience is hungry to learn about how FP techniques work in practice. What design patterns have you applied, and to what areas? Did you use functional reactive programming for user interfaces, or DSLs for playing chess, or fault-tolerant actors for large-scale geological data processing? Teach us something about the techniques you used, and why we should consider using them ourselves. Getting things done: How did you deal with large-scale software development in the absence of pre-existing support tools that are often expected in larger commercial environments (IDEs, coverage tools, debuggers, profilers) and without larger, proven bodies of libraries? Did you hit any brick walls that required support from the community? Don't just be a cheerleader: It's easy to write a rah-rah talk about how well FP worked for you, but CUFP is more interesting when the talks also cover what doesn't work. Even when the results were all great, you should spend more time on the challenges along the way than on the parts that went smoothly. From joehillen at gmail.com Wed Jun 7 23:05:56 2017 From: joehillen at gmail.com (Joe Hillenbrand) Date: Wed, 7 Jun 2017 16:05:56 -0700 Subject: [Haskell-cafe] Turtle library : grepping on Text vs FilePath In-Reply-To: <590b53ba-d322-23b7-b572-d4d05e2e571e@gmail.com> References: <812c3667-ac96-380b-eca9-084aa4f74df9@gmail.com> <590b53ba-d322-23b7-b572-d4d05e2e571e@gmail.com> Message-ID: Line is not just a wrapper around Text. It's a guarantee that the string does not contain any newline characters. Can you be more explicit about what you are trying to do? I'm having troubling understanding what you want. Are you trying to filter the output of `ls` using `grep`? For that you can do this: main = do view $ grep (suffix "hs") $ fmap (unsafeTextToLine . format fp) (ls ".") This will print all the files in the current directory that end in "hs". On Wed, Jun 7, 2017 at 12:22 AM, Ruben Astudillo wrote: > On 07/06/17 03:08, Joe Hillenbrand wrote: >> Is onFiles[1] what you're looking for? >> >> https://hackage.haskell.org/package/turtle-1.3.5/docs/Turtle-Prelude.html#v:onFiles > > Almost. Grep operates over Shell Line. Line is just a newtype over Text. > I still don't know if this is telling me "don't do that". > >> On Tue, Jun 6, 2017 at 10:16 PM, Ruben Astudillo wrote: >>> Dear list >>> >>> On the Turtle library, the grep function got the following signature >>> >>> grep :: Pattern a -> Shell Line -> Shell Line >>> >>> For it to filter output of the `ls :: FilePath -> Shell FilePath` I got >>> to fmap and transform via de Turtle.Format or Turtle.Line modules. Is >>> this an indicator I shouldn't be doing this? Is the library telling me >>> to use `find`? or is just accidental? >>> >>> -- >>> -- Ruben >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. > > > -- > -- Ruben > From ivan.miljenovic at gmail.com Thu Jun 8 04:29:01 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 8 Jun 2017 14:29:01 +1000 Subject: [Haskell-cafe] ANNOUNCE: streaming-conduit Message-ID: I've recently found myself really enjoying using Michael Thompson's [streaming] library for, well, streaming data. However, a lot of packages that I want to use already use conduit for all their streaming needs. As such, I've just written the [streaming-conduit] library to convert between the two (rather than just switching this project to conduit entirely as I couldn't find a simple way to just stream data from a PostgreSQL database). I make no guarantees at this stage of performance, and it's quite possible that - especially for the asStream and asConduit functions - that they may not interoperate cleanly with monadic operations. [streaming]: https://hackage.haskell.org/package/streaming [streaming-conduit]: https://hackage.haskell.org/package/streaming-conduit -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From anthony_clayden at clear.net.nz Thu Jun 8 09:23:48 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Thu, 08 Jun 2017 21:23:48 +1200 Subject: [Haskell-cafe] [ghc-proposals/cafe] Partially applied type families Message-ID: <593917a4.1cf.5e9f.20315@clear.net.nz> > On Tue Jun 6 19:22:45 UTC 2017, Richard Eisenberg wrote: > I still don't see why TypeError is problematic once we > have instance guards. Ah, "once we have instance guards", TypeError is never needed. With instance guards, you might sometimes want to put a TypeError instance, to give a more helpful message. (HList nowadays exploits TypeError that way.) OTOH, sometimes currently you want to say: "I don't want to provide an instance for that pattern here, but by all means somebody else can elsewhere." Example code to illustrate the above: > module A > class C a b ... > instance C Int b ... > > module B > instance C a Bool ... Those instances overlap irresolvably. The only way you can catch (not really improve) is: > instance (TypeError ) => C Int Bool ... But a) which module do you put that in? b) what if somebody wants a `instance C Int Bool`? with guards > module A > class {-# INSTANCEGUARDS #-} C a b ... > instance C Int b | b /~ Bool ... > > module B > instance C a Bool | a /~ Int ... > > module C -- if 'somebody else' wants > instance C Int Bool ... AntC From mahmoudmurad92 at gmail.com Thu Jun 8 13:03:55 2017 From: mahmoudmurad92 at gmail.com (Mahmoud Murad) Date: Thu, 8 Jun 2017 16:03:55 +0300 Subject: [Haskell-cafe] Arithmetic expressions with random operators Message-ID: I have the following problem, I want to randomly generate arithmetic expressions based on a number, for example: if I have n = 3, then the expression must have 3 operators like this (4)*(((3+5)-2)). Any advice or hint? I am relatively new to Haskell. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Jun 8 13:52:18 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 8 Jun 2017 15:52:18 +0200 Subject: [Haskell-cafe] Arithmetic expressions with random operators In-Reply-To: References: Message-ID: <20170608135218.GA17588@casa.casa> On Thu, Jun 08, 2017 at 04:03:55PM +0300, Mahmoud Murad wrote: > I have the following problem, I want to randomly generate arithmetic > expressions based on a number, for example: > if I have n = 3, then the expression must have 3 operators like this > (4)*(((3+5)-2)). Hello Mahmoud, probably not the most flexible and posh solution, but datatypes would do. data Exp = EInt Integer | Sum Exp Exp | Diff Exp Exp | Mult Exp Exp and then of course you want to write evaluate :: Exp -> Integer and write :: Exp -> String -- maybe instance Show Exp where Once you do that, picking Exp constructors at random should not be difficult. There are other ways to write a DSL like this (using GADTs, tagless final style, etc.), each of those expands on/solves a specific problem (extensibility, etc.); but there is no benefit in complicating your code if you don't need it. Does that help? -F From taylor at fausak.me Thu Jun 8 13:55:07 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 08 Jun 2017 08:55:07 -0500 Subject: [Haskell-cafe] Issue 58 :: Haskell Weekly Message-ID: <1496930107.3945812.1002959592.73EF763A@webmail.messagingengine.com> \ Haskell Weekly \/\/ Issue 58 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what's going on in its community. - A Haskell cross compiler for iOS So far we have built a Haskell cross compiler for Raspberry Pi, as well as a Haskell cross compiler for Android. To round this off, we will build a cross compiler for iOS as well. With the WWDC signaling the end of 32-bit devices, we will only build the 64-bit cross compiler. - Event sourced aggregates in Haskell In this first post I'll be digging into event sourced aggregates in Haskell. It basically means that instead of persisting some state like "Johns account balance is $100", you keep track of the changes to John's account: "First he deposited $125, then withdrew $25". - The round-trip property We know that parsers and printers are supposed to be dual. We can simply treat this as a law, and write a property test to enforce it. This is both the simplest useful property test I can think of for a working engineer and the most likely to reliably identify bugs of consequence. - How well do you know your programming tools? Take the survey and test your skills! (ad) "It is a good survey which, in addition to remembering what I already knew, gave me new tools to learn about and work with." This is how developers feel about the Developer Economics survey. The survey also shows you how you compare to other developers in your country. Plus you may win an iPhone 7 or a Pixel 32GB phone. - Assume it worked and fix it later If your email service is down, it can be beneficial to have the signup succeed regardless. By decoupling the success of an email request from the success of account signup, you can improve the reliability of your application. - Flexible data with Aeson At a certain point, our Haskell programs have to be compatible with other programs running on the web. This is especially useful given the growing usage of micro-services as an architecture. Regardless, it's very common to be transferring data between applications on different stacks. - Tagless final encoding of a test language I have experimented with a test language encoded in tagless final style, instead of algebraic data types, to support the typed combinators `beforeEach` and `beforeAll`. I want to share the Haskell prototype I ended up with, and explain how I got there. - Can't see the four-est for the trees It's a fun puzzle so you may want to take a crack at it yourself before reading on. But this isn't really about that puzzle. This is about how sometimes when the mathematical insights aren't flowing it's good to be a programmer. - The Typeclassopedia is now up to date The title pretty much says it all: I have finally finished (I hope) updating the Typeclassopedia to reflect various recent changes to the language and standard libraries (such as the AMP and BBP/FTP). Along the way I also added more links to related reading as well as more exercises. - Continuations from the ground up It's difficult to learn functional programming without hearing about continuations. Often they're mentioned while talking about boosting the performance of pure functional code, sometimes there's talk of control flow, and occasionally with "time-travel" thrown in there to make it all seem more obscure. - How to send me a pull request I find myself repeating a lot of the same comments in pull requests, so I decided to put together a list of what I consider the most important features of a good pull request. Other people will have different feelings on some of these, but the points below are what apply to my projects. Package of the week ------------------- This week's package of the week is Yesod, a web framework for productive development of type-safe, RESTful, high performance web applications. From mahmoudmurad92 at gmail.com Thu Jun 8 14:34:52 2017 From: mahmoudmurad92 at gmail.com (Mahmoud Murad) Date: Thu, 8 Jun 2017 17:34:52 +0300 Subject: [Haskell-cafe] Arithmetic expressions with random operators In-Reply-To: <20170608135218.GA17588@casa.casa> References: <20170608135218.GA17588@casa.casa> Message-ID: Thanks Francesco, I will try it 8 Haz 2017 16:55 tarihinde "Francesco Ariis" yazdı: On Thu, Jun 08, 2017 at 04:03:55PM +0300, Mahmoud Murad wrote: > I have the following problem, I want to randomly generate arithmetic > expressions based on a number, for example: > if I have n = 3, then the expression must have 3 operators like this > (4)*(((3+5)-2)). Hello Mahmoud, probably not the most flexible and posh solution, but datatypes would do. data Exp = EInt Integer | Sum Exp Exp | Diff Exp Exp | Mult Exp Exp and then of course you want to write evaluate :: Exp -> Integer and write :: Exp -> String -- maybe instance Show Exp where Once you do that, picking Exp constructors at random should not be difficult. There are other ways to write a DSL like this (using GADTs, tagless final style, etc.), each of those expands on/solves a specific problem (extensibility, etc.); but there is no benefit in complicating your code if you don't need it. Does that help? -F _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Thu Jun 8 19:00:34 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 8 Jun 2017 15:00:34 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc Message-ID: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> I've been reading about garbage collection. I understand that is stop-the-world, parallel and generational. Per capability also exists "the nursery", which is a block of memory where new objects are allocated. When the nursery of a capability gets filled, do we have to stop-the-world just for that local nursery gc?. To me this is different than gen0 or gen1 gc because isn't really a shared resource. -- Ruben Astudillo. From allbery.b at gmail.com Thu Jun 8 19:03:10 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Jun 2017 15:03:10 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> Message-ID: On Thu, Jun 8, 2017 at 3:00 PM, Ruben Astudillo wrote: > When the nursery of a capability gets filled, do we have to > stop-the-world just for that local nursery gc?. To me this is different > than gen0 or gen1 gc because isn't really a shared resource. > Things that survive garbage collection get promoted out of the nursery. -- 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 ruben.astud at gmail.com Thu Jun 8 19:05:00 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 8 Jun 2017 15:05:00 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> Message-ID: <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> On 08/06/17 15:03, Brandon Allbery wrote: > > On Thu, Jun 8, 2017 at 3:00 PM, Ruben Astudillo > wrote: > > When the nursery of a capability gets filled, do we have to > stop-the-world just for that local nursery gc?. To me this is different > than gen0 or gen1 gc because isn't really a shared resource. > > > Things that survive garbage collection get promoted out of the nursery. but being promoted to gen0 is allocation, and thus there isn't need to stop the other threads. -- Ruben Astudillo From allbery.b at gmail.com Thu Jun 8 19:08:14 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Jun 2017 15:08:14 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> Message-ID: On Thu, Jun 8, 2017 at 3:05 PM, Ruben Astudillo wrote: > On 08/06/17 15:03, Brandon Allbery wrote: > > On Thu, Jun 8, 2017 at 3:00 PM, Ruben Astudillo > > wrote: > > When the nursery of a capability gets filled, do we have to > > stop-the-world just for that local nursery gc?. To me this is > different > > than gen0 or gen1 gc because isn't really a shared resource. > > > > Things that survive garbage collection get promoted out of the nursery. > > but being promoted to gen0 is allocation, and thus there isn't need to > stop the other threads. > It's not just allocation: if it didn't get garbage collected, then there is *at least* one reference to it that needs to be updated. So what happens when there is more than one, and some of those are active in other threads? -- 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 ruben.astud at gmail.com Thu Jun 8 19:29:42 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 8 Jun 2017 15:29:42 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> Message-ID: <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> I didn't understand some parts On 08/06/17 15:08, Brandon Allbery wrote: > It's not just allocation: if it didn't get garbage collected, then > there is *at least* one reference to it that needs to be updated. which reference is that?. Immutability means that old data can't reference the new one, right?. What kind of reference (apart from live data on the stack) can we have on new data on the nursery? > So what happens when there is more than one, and some of those are > active in other threads? Same as before right? Sorry, maybe I don't have the right mental model. If you could show me a general picture of what happens when a nursery gets full I would appreciate it :-) . -- Ruben Astudillo From allbery.b at gmail.com Thu Jun 8 19:45:19 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Jun 2017 15:45:19 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> Message-ID: On Thu, Jun 8, 2017 at 3:29 PM, Ruben Astudillo wrote: > On 08/06/17 15:08, Brandon Allbery wrote: > > It's not just allocation: if it didn't get garbage collected, then > > there is *at least* one reference to it that needs to be updated. > > which reference is that?. Immutability means that old data can't > reference the new one, right?. What kind of reference (apart from live > data on the stack) can we have on new data on the nursery? > Another reference within the same nursery. Now consider that the same nursery can *also* contain newly created threads, which can be scheduled just like existing ones. Between two garbage collections, we may have: - allocation of new values - spawning of new sparks which have access to said values If you now have multiple hardware threads, these can be running concurrently and allocating their own heap values which reference those shared values: for example, each is building its own list of cons cells referencing the value in different ways as specified by other values passed to the thread. Relocating the shared value from the nursery now requires updating all such thread-specific cons cells. Those heap values are also being promoted out of the nursery, but that doesn't change anything; copying them does not magically also update the copied things being pointed to, that is part of what GC does. -- 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 Jun 8 19:57:04 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 8 Jun 2017 15:57:04 -0400 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> Message-ID: On Thu, Jun 8, 2017 at 3:45 PM, Brandon Allbery wrote: > If you now have multiple hardware threads, these can be running > concurrently and allocating their own heap values which reference those > shared values: for example, each is building its own list of cons cells > referencing the value in different ways as specified by other values passed > to the thread. Relocating the shared value from the nursery now requires > updating all such thread-specific cons cells. Those heap values are also > being promoted out of the nursery, but that doesn't change anything; > copying them does not magically also update the copied things being pointed > to, that is part of what GC does. > I should also point out that the fact that the cons cells for the other thread are in a different nursery from the shared value *also* does not change anything (aside from possibly complicating the implementation of the garbage collector). They still must be updated to point to the new value, so that thread must be quiescent/not actively accessing through the pointer being updated. This stuff *is* complicated; I've had to stop and think through the whole thing a few times myself. And I might still have some things wrong. :/ -- 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 eric at seidel.io Thu Jun 8 20:01:01 2017 From: eric at seidel.io (Eric Seidel) Date: Thu, 08 Jun 2017 13:01:01 -0700 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> Message-ID: <1496952061.1572442.1003356592.5B58E0FB@webmail.messagingengine.com> Simon Marlow wrote a paper about this issue a few years ago. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/local-gc.pdf The conclusion IIRC was that while maintaining thread-local heaps could reduce the amount of time spent in GC, the benefit was surprisingly small, and came at a sizable cost in code complexity. So GHC HQ decided it was not worth merging at the time. I don't know if there's been any work on that front since the paper though. On Thu, Jun 8, 2017, at 12:45, Brandon Allbery wrote: > On Thu, Jun 8, 2017 at 3:29 PM, Ruben Astudillo > wrote: > > > On 08/06/17 15:08, Brandon Allbery wrote: > > > It's not just allocation: if it didn't get garbage collected, then > > > there is *at least* one reference to it that needs to be updated. > > > > which reference is that?. Immutability means that old data can't > > reference the new one, right?. What kind of reference (apart from live > > data on the stack) can we have on new data on the nursery? > > > > Another reference within the same nursery. Now consider that the same > nursery can *also* contain newly created threads, which can be scheduled > just like existing ones. > > Between two garbage collections, we may have: > > - allocation of new values > - spawning of new sparks which have access to said values > > If you now have multiple hardware threads, these can be running > concurrently and allocating their own heap values which reference those > shared values: for example, each is building its own list of cons cells > referencing the value in different ways as specified by other values > passed > to the thread. Relocating the shared value from the nursery now requires > updating all such thread-specific cons cells. Those heap values are also > being promoted out of the nursery, but that doesn't change anything; > copying them does not magically also update the copied things being > pointed > to, that is part of what GC does. > > -- > 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. From wolfgang-it at jeltsch.info Thu Jun 8 21:20:54 2017 From: wolfgang-it at jeltsch.info (Wolfgang Jeltsch) Date: Fri, 09 Jun 2017 00:20:54 +0300 Subject: [Haskell-cafe] Haskell in Leipzig 2017: 1st call for papers Message-ID: <1496956854.15892.70.camel@jeltsch.info> Event:    Haskell in Leipzig 2017 Time:     October 26–28, 2017 Place:    HTWK Leipzig, Germany Homepage: https://hal2017.softbase.org/ About ===== Haskell is a modern functional programming language that allows rapid development of robust and correct software. It is renowned for its expressive type system, its unique approaches to concurrency and parallelism, and its excellent refactoring capabilities. Haskell is both the playing field of cutting-edge programming language research and a reliable base for commercial software development. The workshop series Haskell in Leipzig (HaL), now in its 12th year, brings together Haskell developers, Haskell researchers, Haskell enthusiasts, and Haskell beginners to listen to talks, take part in tutorials, join in interesting conversations, and hack together. To support the latter, HaL will include a one-day hackathon this year. The workshop will have a focus on functional reactive programming (FRP) this time, while continuing to be open to all aspects of Haskell. As in the previous year, the workshop will be in English. Contributions ============= Everything related to Haskell is on topic, whether it is about current research, practical applications, interesting ideas off the beaten track, education, or art, and topics may extend to functional programming in general and its connections to other programming paradigms. Contributions can take the form of   * talks (about 30 minutes),   * tutorials (about 90 minutes),   * demonstrations, artistic performances, or other extraordinary     things. Please submit an abstract that describes the content and form of your presentation, the intended audience, and required previous knowledge. We recommend a length of 2 pages, so that the program committee and the audience get a good idea of your contribution, but this is not a hard requirement. Please submit your abstract as a PDF document at     https://easychair.org/conferences/?conf=hal2017 until Friday, August 4, 2017. You will be notified by Friday, August 25, 2017. Hacking Projects ================ Projects for the hackathon can be presented during the workshop. A prior submission is not needed for this. Program Committee =================   * Edward Amsden, Plow Technologies, USA   * Heinrich Apfelmus, Germany   * Jurriaan Hage, Utrecht University, The Netherlands   * Petra Hofstedt, BTU Cottbus-Senftenberg, Germany   * Wolfgang Jeltsch, Tallinn University of Technology, Estonia (chair)   * Andres Löh, Well-Typed LLP, Germany   * Keiko Nakata, SAP SE, Germany   * Henrik Nilsson, University of Nottingham, UK   * Ertuğrul Söylemez, Intelego GmbH, Germany   * Henning Thielemann, Germany   * Niki Vazou, University of Maryland, USA   * Johannes Waldmann, HTWK Leipzig, Germany Questions ========= If you have any questions, please do not hesitate to contact Wolfgang Jeltsch at wolfgang-it at jeltsch.info. From ok at cs.otago.ac.nz Thu Jun 8 22:54:47 2017 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Fri, 9 Jun 2017 10:54:47 +1200 Subject: [Haskell-cafe] Arithmetic expressions with random operators In-Reply-To: References: <20170608135218.GA17588@casa.casa> Message-ID: <3f04c0cf97f0eb7120aea29e2bf81b78.squirrel@chasm.otago.ac.nz> > > On Thu, Jun 08, 2017 at 04:03:55PM +0300, Mahmoud Murad wrote: >> I have the following problem, I want to randomly generate arithmetic >> expressions based on a number, for example: >> if I have n = 3, then the expression must have 3 operators like this >> (4)*(((3+5)-2)). > I don't seem to have the original message in my mailbox, so my response may be inappropriate. Generating random arithmetic expressions in Haskell has two parts: how to generate random arithmetic expressions at all, and how to do it in Haskell. Assuming that "arithmetic expressions" means expressions using numbers and the four binary operations + - * / (or possibly the exponentiation operator as well), the basic problem reduces to * generate a random binary tree with n internal nodes * assign random numbers to the leaves * assign random operators to the internal nodes The last two subtasks are pretty easy. This leaves generating random binary trees as the main problem. This paper may help: http://www.cs.otago.ac.nz/staffpriv/mike/Papers/RandomGeneration/RandomBinaryTrees.pdf There's a survey paper at http://www.sis.uta.fi/cs/reports/A-1998-3.ps.Z and the Atkinson/Sack approach does seem to be pretty good, at least if you want to make *large* expressions. This only matters if you want all expressions to be equally likely. You may not. From anselm.scholl at tu-harburg.de Fri Jun 9 06:30:09 2017 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Fri, 9 Jun 2017 08:30:09 +0200 Subject: [Haskell-cafe] rts nursery and stopping the world minor gc In-Reply-To: <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> References: <3c007abb-9420-f26f-1a20-194bcf8a9a51@gmail.com> <08227af9-d78f-d1dd-f1ea-703e6c5135d5@gmail.com> <34c6efb9-9cd2-b390-9a2f-bdfee4458396@gmail.com> Message-ID: <39834344-9922-37df-e0a1-1cc010713960@tu-harburg.de> On 06/08/2017 09:29 PM, Ruben Astudillo wrote: > I didn't understand some parts > > On 08/06/17 15:08, Brandon Allbery wrote: >> It's not just allocation: if it didn't get garbage collected, then >> there is *at least* one reference to it that needs to be updated. > > which reference is that?. Immutability means that old data can't > reference the new one, right?. What kind of reference (apart from live > data on the stack) can we have on new data on the nursery? No, immutability does not mean that old data cannot reference new data. The reason is that we are in a lazy language: If you have an old value referencing a thunk and the thunk is evaluated, it is replaced by an indirection to the new value (it may be replaced if the new value is small enough, but this is just an optimization). So if two threads share a reference to an infinite list and one threads evaluates a piece of the list and later throws away its reference, the other thread still references the new evaluated part of the list - which was allocated in the nursery of the other thread! Additionally, not all data in Haskell is immutable. Just think about all the different vectors, arrays and things like IORefs you can modify as long as you are in the correct monad. The GC has to take care of that, otherwise your program would either leak memory or after the GC frees your data while you still hold an IORef pointing to it or similar. > >> So what happens when there is more than one, and some of those are >> active in other threads? > > Same as before right? > > Sorry, maybe I don't have the right mental model. If you could show me a > general picture of what happens when a nursery gets full I would > appreciate it :-)> > -- Ruben Astudillo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 488 bytes Desc: OpenPGP digital signature URL: From iblech at web.de Thu Jun 8 16:20:19 2017 From: iblech at web.de (Ingo Blechschmidt) Date: Thu, 8 Jun 2017 18:20:19 +0200 Subject: [Haskell-cafe] Arithmetic expressions with random operators In-Reply-To: References: Message-ID: <20170608162019.GA22493@speicherleck.de> Dear Murad, On Thu, Jun 08, 2017 at 04:03:55PM +0300, Mahmoud Murad wrote: > I have the following problem, I want to randomly generate arithmetic > expressions based on a number, for example: > if I have n = 3, then the expression must have 3 operators like this > (4)*(((3+5)-2)). Mark Dominus, well-known in the Perl community, likes this puzzle so much that he collected several solutions and nonsolutions on his blog (which I warmly recommend). He also lists several Haskell solutions: http://blog.plover.com/math/24-puzzle.html Ideas for further optimizations of the Haskell solutions (regarding clarity, elegance, and length of the code) are very much welcome: https://gist.github.com/iblech/e21b0a2f5a6e0184ba43c3b1e0e70337 Cheers, Ingo From hjgtuyl at chello.nl Fri Jun 9 20:52:47 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 09 Jun 2017 22:52:47 +0200 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: <1496836395-sup-4284@sabre> References: <1496836395-sup-4284@sabre> Message-ID: I have attached the -v3 log. Regards, Henk-Jan van Tuyl On Wed, 07 Jun 2017 13:56:12 +0200, Edward Z. Yang wrote: > This sounds like a Cabal bug to me. A few things to try: > > - Can you post a -v3 log of the second cabal install force > reinstall somewhere? It sounds like we are incorrectly > attempting to use the wrong version of Cabal to build the > Setup script, and a -v3 log would help confirm. > > - Are you on Ubuntu? If you could install and test a cabal-install-head > binary from https://launchpad.net/~hvr/+archive/ubuntu/ghc > that would be helpful to find out if we've fixed this bug > already. > > - If you want to file a bug, please do so in the Cabal > bug tracker https://github.com/haskell/cabal/issues > Thanks! > > Cheers, > Edward > > Excerpts from Henk-Jan van Tuyl's message of 2017-06-04 11:45:58 +0200: >> >> L.S., >> >> I am trying the prerelease of GHC, version 8.2.0.20170507 >> >> I adapted wxHaskell to the new packages that come with the new GHC and >> it >> compiles now, but only the first time. If I compile it a second time, >> even >> if nothing has changed, the information from the custom-setup section of >> the wxc.cabal file seems to be forgotten. This section looks like this: >> >> custom-setup >> setup-depends: >> base, >> Cabal < 2, >> containers, >> bytestring, >> split, >> process, >> directory, >> filepath >> (I am using cabal-install 1.24.0.2) >> >> Output from the second time I try to install wxHaskell: >> >> > cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx >> [1 of 1] Compiling Main ( >> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, >> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) >> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... >> [1 of 1] Compiling Main ( >> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, >> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) >> >> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: >> Variable not in scope: versionBranch :: Version >> -> >> [a0] >> | >> 505 | full_ver = (concat . intersperse "." . map show . >> versionBranch) ver >> | >> ^^^^^^^^^^^^^ >> >> This error message indicates that the wrong version of Cabal (2.0) is >> used >> to compile the wxcore setup.hs >> It looks like a cabal-install bug, but this does not happen when I >> use GHC 8.0.2; should I write a GHC bug ticket? >> >> Regards, >> Henk-Jan van Tuyl -- 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://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CabalInstall-v3.txt URL: From ezyang at mit.edu Sat Jun 10 01:13:11 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Fri, 09 Jun 2017 21:13:11 -0400 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: <1496836395-sup-4284@sabre> Message-ID: <1497055440-sup-9171@sabre> Thanks Henk, I know what the problem is. I've filed a bug here. https://github.com/haskell/cabal/issues/4561 In the meantime, you should try giving new-build a try. I believe it does not suffer from this problem. http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html Edward Excerpts from Henk-Jan van Tuyl's message of 2017-06-09 22:52:47 +0200: > > I have attached the -v3 log. > > Regards, > Henk-Jan van Tuyl > > On Wed, 07 Jun 2017 13:56:12 +0200, Edward Z. Yang wrote: > > > This sounds like a Cabal bug to me. A few things to try: > > > > - Can you post a -v3 log of the second cabal install force > > reinstall somewhere? It sounds like we are incorrectly > > attempting to use the wrong version of Cabal to build the > > Setup script, and a -v3 log would help confirm. > > > > - Are you on Ubuntu? If you could install and test a cabal-install-head > > binary from https://launchpad.net/~hvr/+archive/ubuntu/ghc > > that would be helpful to find out if we've fixed this bug > > already. > > > > - If you want to file a bug, please do so in the Cabal > > bug tracker https://github.com/haskell/cabal/issues > > Thanks! > > > > Cheers, > > Edward > > > > Excerpts from Henk-Jan van Tuyl's message of 2017-06-04 11:45:58 +0200: > >> > >> L.S., > >> > >> I am trying the prerelease of GHC, version 8.2.0.20170507 > >> > >> I adapted wxHaskell to the new packages that come with the new GHC and > >> it > >> compiles now, but only the first time. If I compile it a second time, > >> even > >> if nothing has changed, the information from the custom-setup section of > >> the wxc.cabal file seems to be forgotten. This section looks like this: > >> > >> custom-setup > >> setup-depends: > >> base, > >> Cabal < 2, > >> containers, > >> bytestring, > >> split, > >> process, > >> directory, > >> filepath > >> (I am using cabal-install 1.24.0.2) > >> > >> Output from the second time I try to install wxHaskell: > >> > >> > cabal install --force-reinstalls --reinstall wxdirect wxc wxcore wx > >> [1 of 1] Compiling Main ( > >> X:\Temp\wxHaskell\wxcore\dist\setup\setup.hs, > >> X:\Temp\wxHaskell\wxcore\dist\setup\Main.o ) > >> Linking X:\Temp\wxHaskell\wxcore\dist\setup\setup.exe ... > >> [1 of 1] Compiling Main ( > >> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs, > >> X:\Temp\wxHaskell\wxc\dist\setup\Main.o ) > >> > >> X:\Temp\wxHaskell\wxc\dist\setup\setup.hs:505:61: error: > >> Variable not in scope: versionBranch :: Version > >> -> > >> [a0] > >> | > >> 505 | full_ver = (concat . intersperse "." . map show . > >> versionBranch) ver > >> | > >> ^^^^^^^^^^^^^ > >> > >> This error message indicates that the wrong version of Cabal (2.0) is > >> used > >> to compile the wxcore setup.hs > >> It looks like a cabal-install bug, but this does not happen when I > >> use GHC 8.0.2; should I write a GHC bug ticket? > >> > >> Regards, > >> Henk-Jan van Tuyl > > > 2017-06-07 17:03:12,27 > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507> Call cbl install -v3 --force-reinstalls --reinstall wxdirect wxc wxcore wx > * > *** You are now in a sandbox *** > * > Command: cabal install -v3 --force-reinstalls --reinstall wxdirect wxc wxcore wx > Using a sandbox located at > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\.cabal-sandbox > Searching for ghc in path. > Found ghc at C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--numeric-version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc.exe is version 8.2.0.20170507 > looking for tool ghc-pkg near compiler in > C:\Progs\Haskell\ghc-8.2.0.20170507\bin > candidate locations: > ["C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe"] > found ghc-pkg in C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc-pkg.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe",["--version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc-pkg.exe is version > 8.2.0.20170507 > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--supported-languages"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--info"]) > Searching for alex in path. > Found alex at C:\Users\X\AppData\Roaming\cabal\bin\alex.exe > ("C:\\Users\\-\\AppData\\Roaming\\cabal\\bin\\alex.exe",["--version"]) > C:\Users\X\AppData\Roaming\cabal\bin\alex.exe is version 3.2.1 > Searching for ar.exe in path. > Found ar.exe at C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\ar.exe > Searching for c2hs in path. > Found c2hs at C:\Progs\Haskell\c2hs.exe > ("C:\\Progs\\Haskell\\c2hs.exe",["--numeric-version"]) > C:\Progs\Haskell\c2hs.exe is version 0.17.2 > Searching for cpphs in path. > Found cpphs at C:\Users\X\AppData\Roaming\cabal\bin\cpphs.exe > ("C:\\Users\\-\\AppData\\Roaming\\cabal\\bin\\cpphs.exe",["--version"]) > C:\Users\X\AppData\Roaming\cabal\bin\cpphs.exe is version 1.20.5 > Searching for gcc.exe in path. > Found gcc.exe at C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\gcc.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\bin\\gcc.exe",["-dumpversion"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\gcc.exe is version 6.2.0 > Searching for ghcjs in path. > Cannot find ghcjs on the path > Searching for ghcjs-pkg in path. > Cannot find ghcjs-pkg on the path > Searching for greencard in path. > Cannot find greencard on the path > looking for tool haddock near compiler in > C:\Progs\Haskell\ghc-8.2.0.20170507\bin > candidate locations: > ["C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\haddock.exe"] > found haddock in C:\Progs\Haskell\ghc-8.2.0.20170507\bin\haddock.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\haddock.exe",["--version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\haddock.exe is version 2.18.0 > Searching for happy in path. > Found happy at C:\Users\X\AppData\Roaming\cabal\bin\happy.exe > ("C:\\Users\\-\\AppData\\Roaming\\cabal\\bin\\happy.exe",["--version"]) > C:\Users\X\AppData\Roaming\cabal\bin\happy.exe is version 1.19.5 > Searching for hmake in path. > Cannot find hmake on the path > Searching for hpc in path. > Found hpc at C:\Progs\Haskell\ghc-8.2.0.20170507\bin\hpc.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\hpc.exe",["version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\hpc.exe is version 0.67 > looking for tool hsc2hs near compiler in > C:\Progs\Haskell\ghc-8.2.0.20170507\bin > candidate locations: > ["C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\hsc2hs.exe"] > found hsc2hs in C:\Progs\Haskell\ghc-8.2.0.20170507\bin\hsc2hs.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\hsc2hs.exe",["--version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\hsc2hs.exe is version 0.68.2 > Searching for HsColour in path. > Found HsColour at C:\Users\X\AppData\Roaming\cabal\bin\HsColour.exe > ("C:\\Users\\-\\AppData\\Roaming\\cabal\\bin\\HsColour.exe",["-version"]) > C:\Users\X\AppData\Roaming\cabal\bin\HsColour.exe is version 1.24 > Searching for jhc in path. > Cannot find jhc on the path > Searching for ld.exe in path. > Found ld.exe at C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\ld.exe > Environment: [("","ExitCode=00000000"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\-\\AppData\\Roaming"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","ALQUANTOR"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("CPLUS_INCLUDE_PATH","C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\include\\c++\\6.2.0\\;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\x86_64-w64-mingw32\\include"),("C_INCLUDE_PATH","C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\x86_64-w64-mingw32\\include"),("FP_NO_HOST_CHECK","NO"),("GHCVERSION","8.2.0.20170507"),("GHC_DIR","C:\\Progs\\Haskell\\ghc-8.2.0.20170507"),("GHC_VERSION","8.2.0.20170507"),("HASKELL_COMPILER_DIR","C:\\Progs\\Haskell\\ghc-8.2.0.20170507"),("HOME","C:\\Users\\-"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\-"),("JAVA_HOME","C:\\Progs\\Java\\jdk1.8.0_25"),("LIBDIR","C:\\Libs"),("LIBRARY_PATH","C:\\Progs\\wxWidgets\\3.0.3-GCC6.2.0-64bit\\lib\\gcc_dll;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\lib\\"),("LOCALAPPDATA","C:\\Users\\-\\AppData\\Local"),("LOGONSERVER","\\\\ALQUANTOR"),("NUMBER_OF_PROCESSORS","8"),("OS","Windows_NT"),("PACKAGE","wx"),("PACKAGES","wxdirect wxc wxcore wx"),("PATH","wxdirect\\dist\\build\\wxdirect;C:\\Progs\\Haskell;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\bin;C:\\Program Files\\Haskell\\bin;C:\\Windows\\system32;C:\\ProgramData\\Oracle\\Java\\javapath;C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;C:\\Progs\\Python27\\;C:\\bin\\;C:\\bin\\bin;C:\\Progs\\7-Zip;C:\\Progs\\THE;C:\\Progs\\upx391w;C:\\Progs\\GNU\\GnuPG;C:\\Progs\\Geany\\1.30.1\\bin;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files (x86)\\Windows Live\\Shared;C:\\Progs\\GNU\\GnuPG\\pub;C:\\Progs\\rexx.org\\Regina;C:\\Progs\\THE;C:\\Progs\\WinMerge;C:\\Progs\\Windows Kits\\8.1\\Wi! ndows Pe rformance Toolkit\\;C:\\Progs\\SlikSvn\\bin;C:\\Progs\\GitExtensions\\;C:\\Progs\\Stack;C:\\Progs\\MSYS2\\msys64;C:\\Progs\\MSYS2\\msys64\\mingw64\\bin;C:\\Users\\-\\AppData\\Roaming\\cabal\\bin;C:\\Progs\\FAHClient;C:\\Progs\\IrfanView;C:\\Progs\\Graphviz2.38\\bin;C:\\Progs\\Git\\bin;C:\\Progs\\DependencyWalker;C:\\Users\\-\\AppData\\Roaming\\cabal\\bin"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 60 Stepping 3, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","3c03"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$D $T $_$P$G$S"),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("REGINA_LANG","en"),("REGINA_LANG_DIR","C:\\Progs\\rexx.org\\Regina"),("RESMURF","If Exist dist Rd /s/q dist"),("SESSIONNAME","Console"),("SMURF","cabal install -v3 --force-reinstalls --reinstall wxdirect wxc wxcore wx"),("STACK_ROOT","C:\\Users\\-\\Documents\\StackRoot"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TC_VERSION","3.0.3-GCC6.2.0-64bit-8.2.0.20170507"),("TEMP","C:\\Users\\-\\AppData\\Local\\Temp"),("THE_HELP_FILE","C:\\Progs\\THE\\THE_Help.txt"),("THE_HOME_DIR","C:\\Progs\\THE"),("THE_MACRO_PATH","C:\\Progs\\THE\\extras"),("TMP","C:\\Users\\-\\AppData\\Local\\Temp"),("UNREGISTER","cabal exec ghc-pkg unregister"),("USERDOMAIN","Alquantor"),("USERDOMAIN_ROAMINGPROFILE","Alquantor"),("USERNAME","User"),("USERPROFILE","C:\\Users\\-"),("VBOX_MSI_INSTALL_PATH","C:\\Progs\\Oracle\\VirtualBox\\"),("WINDIR","C:\\Windows"),("WXCFG","gcc_dll\\mswu"),("WXCONFIGURATION","Achelanne"),("WXCONFIGVER","0.1"),("WXHASKELL_TEMP_DIR","wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507"),("WXWIDGETS_VERSION","3.0.3-GCC6.2.0-64bit"),("WXWIDGETS_VERSION_NO_BITNESS","3.0.3-GCC6.2.0"),("WXWIN","C:\\Progs\\wxWidgets\\3.0.3-GCC6.2.0-64bit")] > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["-hide-all-packages","-c","C:\\Users\\-\\AppData\\Local\\Temp\\4118467.c","-o","C:\\Users\\-\\AppData\\Local\\Temp\\633426500.o"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\bin\\ld.exe",["-x","-r","C:\\Users\\-\\AppData\\Local\\Temp\\633426500.o","-o","C:\\Users\\-\\AppData\\Local\\Temp\\1916915724.o"]) > Searching for lhc in path. > Cannot find lhc on the path > Searching for lhc-pkg in path. > Cannot find lhc-pkg on the path > Searching for pkg-config in path. > Found pkg-config at C:\bin\pkg-config.exe > ("C:\\bin\\pkg-config.exe",["--version"]) > C:\bin\pkg-config.exe is version 0.28 > Searching for strip in path. > Found strip at C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\strip.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\bin\\strip.exe",["--version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\mingw\bin\strip.exe is version 2.27 > Searching for tar in path. > Cannot find tar on the path > Searching for uhc in path. > Cannot find uhc on the path > The package database already exists: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\.cabal-sandbox\x86_64-windows-ghc-8.2.0.20170507-packages.conf.d > Reading installed packages... > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe",["dump","--package-db=X:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\.cabal-sandbox\\x86_64-windows-ghc-8.2.0.20170507-packages.conf.d","-v0"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--print-libdir"]) > Checking whether the dependency is modified: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wx > Using internal setup method with build-type Simple and args: > ["sdist","--verbose=3","--list-sources=C:\\Users\\-\\AppData\\Local\\Temp\\cabal-list-sources.-1020\\cabal-sdist-list-sources"] > List of package sources written to file > 'C:\Users\X\AppData\Local\Temp\cabal-list-sources.-1020\cabal-sdist-list-sources' > Dependency has a modified source file: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wx\src\Graphics\UI\WX\Draw.hs > Checking whether the dependency is modified: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxcore > Using external setup method with build-type Custom > Using explicit dependencies: False > creating > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxcore\dist\setup > Using Cabal library version 2.0.0.0 > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxcore\dist\setup\setup.exe > sdist --verbose=3 > --list-sources=C:\Users\X\AppData\Local\Temp\cabal-list-sources.-1020\cabal-sdist-list-sources > List of package sources written to file > 'C:\Users\X\AppData\Local\Temp\cabal-list-sources.-1020\cabal-sdist-list-sources' > Dependency has a modified source file: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxcore\src/haskell\Graphics\UI\WXCore.hs > Checking whether the dependency is modified: > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc > Using external setup method with build-type Custom > Using explicit dependencies: False > creating X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup > Searching for ghc in path. > Found ghc at C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--numeric-version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc.exe is version 8.2.0.20170507 > looking for tool ghc-pkg near compiler in > C:\Progs\Haskell\ghc-8.2.0.20170507\bin > candidate locations: > ["C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe"] > found ghc-pkg in C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc-pkg.exe > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe",["--version"]) > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc-pkg.exe is version > 8.2.0.20170507 > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--supported-languages"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--info"]) > Reading installed packages... > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe",["dump","--global","-v0"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc-pkg.exe",["dump","--user","-v0"]) > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--print-libdir"]) > Using Cabal library version 2.0.0.0 > Setup executable needs to be updated, compiling... > Environment: [("","ExitCode=00000000"),("ALLUSERSPROFILE","C:\\ProgramData"),("APPDATA","C:\\Users\\-\\AppData\\Roaming"),("COMMONPROGRAMFILES","C:\\Program Files\\Common Files"),("COMMONPROGRAMFILES(X86)","C:\\Program Files (x86)\\Common Files"),("COMMONPROGRAMW6432","C:\\Program Files\\Common Files"),("COMPUTERNAME","ALQUANTOR"),("COMSPEC","C:\\Windows\\system32\\cmd.exe"),("CPLUS_INCLUDE_PATH","C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\include\\c++\\6.2.0\\;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\x86_64-w64-mingw32\\include"),("C_INCLUDE_PATH","C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\x86_64-w64-mingw32\\include"),("FP_NO_HOST_CHECK","NO"),("GHCVERSION","8.2.0.20170507"),("GHC_DIR","C:\\Progs\\Haskell\\ghc-8.2.0.20170507"),("GHC_VERSION","8.2.0.20170507"),("HASKELL_COMPILER_DIR","C:\\Progs\\Haskell\\ghc-8.2.0.20170507"),("HOME","C:\\Users\\-"),("HOMEDRIVE","C:"),("HOMEPATH","\\Users\\-"),("JAVA_HOME","C:\\Progs\\Java\\jdk1.8.0_25"),("LIBDIR","C:\\Libs"),("LIBRARY_PATH","C:\\Progs\\wxWidgets\\3.0.3-GCC6.2.0-64bit\\lib\\gcc_dll;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\lib\\"),("LOCALAPPDATA","C:\\Users\\-\\AppData\\Local"),("LOGONSERVER","\\\\ALQUANTOR"),("NUMBER_OF_PROCESSORS","8"),("OS","Windows_NT"),("PACKAGE","wx"),("PACKAGES","wxdirect wxc wxcore wx"),("PATH","wxdirect\\dist\\build\\wxdirect;C:\\Progs\\Haskell;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin;C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\mingw\\bin;C:\\Program Files\\Haskell\\bin;C:\\Windows\\system32;C:\\ProgramData\\Oracle\\Java\\javapath;C:\\Program Files (x86)\\NVIDIA Corporation\\PhysX\\Common;C:\\Progs\\Python27\\;C:\\bin\\;C:\\bin\\bin;C:\\Progs\\7-Zip;C:\\Progs\\THE;C:\\Progs\\upx391w;C:\\Progs\\GNU\\GnuPG;C:\\Progs\\Geany\\1.30.1\\bin;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files (x86)\\Windows Live\\Shared;C:\\Progs\\GNU\\GnuPG\\pub;C:\\Progs\\rexx.org\\Regina;C:\\Progs\\THE;C:\\Progs\\WinMerge;C:\\Progs\\Windows Kits\\8.1\\Wi! ndows Pe rformance Toolkit\\;C:\\Progs\\SlikSvn\\bin;C:\\Progs\\GitExtensions\\;C:\\Progs\\Stack;C:\\Progs\\MSYS2\\msys64;C:\\Progs\\MSYS2\\msys64\\mingw64\\bin;C:\\Users\\-\\AppData\\Roaming\\cabal\\bin;C:\\Progs\\FAHClient;C:\\Progs\\IrfanView;C:\\Progs\\Graphviz2.38\\bin;C:\\Progs\\Git\\bin;C:\\Progs\\DependencyWalker"),("PATHEXT",".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC"),("PROCESSOR_ARCHITECTURE","AMD64"),("PROCESSOR_IDENTIFIER","Intel64 Family 6 Model 60 Stepping 3, GenuineIntel"),("PROCESSOR_LEVEL","6"),("PROCESSOR_REVISION","3c03"),("PROGRAMDATA","C:\\ProgramData"),("PROGRAMFILES","C:\\Program Files"),("PROGRAMFILES(X86)","C:\\Program Files (x86)"),("PROGRAMW6432","C:\\Program Files"),("PROMPT","$D $T $_$P$G$S"),("PSMODULEPATH","C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\Modules\\"),("PUBLIC","C:\\Users\\Public"),("REGINA_LANG","en"),("REGINA_LANG_DIR","C:\\Progs\\rexx.org\\Regina"),("RESMURF","If Exist dist Rd /s/q dist"),("SESSIONNAME","Console"),("SMURF","cabal install -v3 --force-reinstalls --reinstall wxdirect wxc wxcore wx"),("STACK_ROOT","C:\\Users\\-\\Documents\\StackRoot"),("SYSTEMDRIVE","C:"),("SYSTEMROOT","C:\\Windows"),("TC_VERSION","3.0.3-GCC6.2.0-64bit-8.2.0.20170507"),("TEMP","C:\\Users\\-\\AppData\\Local\\Temp"),("THE_HELP_FILE","C:\\Progs\\THE\\THE_Help.txt"),("THE_HOME_DIR","C:\\Progs\\THE"),("THE_MACRO_PATH","C:\\Progs\\THE\\extras"),("TMP","C:\\Users\\-\\AppData\\Local\\Temp"),("UNREGISTER","cabal exec ghc-pkg unregister"),("USERDOMAIN","Alquantor"),("USERDOMAIN_ROAMINGPROFILE","Alquantor"),("USERNAME","User"),("USERPROFILE","C:\\Users\\-"),("VBOX_MSI_INSTALL_PATH","C:\\Progs\\Oracle\\VirtualBox\\"),("WINDIR","C:\\Windows"),("WXCFG","gcc_dll\\mswu"),("WXCONFIGURATION","Achelanne"),("WXCONFIGVER","0.1"),("WXHASKELL_TEMP_DIR","wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507"),("WXWIDGETS_VERSION","3.0.3-GCC6.2.0-64bit"),("WXWIDGETS_VERSION_NO_BITNESS","3.0.3-GCC6.2.0"),("WXWIN","C:\\Progs\\wxWidgets\\3.0.3-GCC6.2.0-64bit")] > ("C:\\Progs\\Haskell\\ghc-8.2.0.20170507\\bin\\ghc.exe",["--make","-v","-odir","X:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\wxc\\dist\\setup","-hidir","X:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\wxc\\dist\\setup","-i","-iX:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\wxc","-package-id","Cabal-2.0.0.0","X:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\wxc\\dist\\setup\\setup.hs","-o","X:\\Temp\\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\\wxc\\dist\\setup\\setup.exe","-threaded"]) > Glasgow Haskell Compiler, Version 8.2.0.20170507, stage 2 booted by GHC version 8.0.2 > Using binary package database: C:\Progs\Haskell\ghc-8.2.0.20170507\lib\package.conf.d\package.cache > Using binary package database: C:\Users\X\AppData\Roaming\ghc\x86_64-mingw32-8.2.0.20170507\package.conf.d\package.cache > package flags [-package-id Cabal-2.0.0.0{unit Cabal-2.0.0.0 True ([])}] > loading package database C:\Progs\Haskell\ghc-8.2.0.20170507\lib\package.conf.d > loading package database C:\Users\X\AppData\Roaming\ghc\x86_64-mingw32-8.2.0.20170507\package.conf.d > wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 > wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 > wired-in package base mapped to base-4.10.0.0 > wired-in package rts mapped to rts > wired-in package template-haskell mapped to template-haskell-2.12.0.0 > wired-in package ghc mapped to ghc-8.2.0.20170507 > wired-in package dph-seq not found. > wired-in package dph-par not found. > package flags [-package-id Cabal-2.0.0.0{unit Cabal-2.0.0.0 True ([])}] > loading package database C:\Progs\Haskell\ghc-8.2.0.20170507\lib\package.conf.d > loading package database C:\Users\X\AppData\Roaming\ghc\x86_64-mingw32-8.2.0.20170507\package.conf.d > wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 > wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 > wired-in package base mapped to base-4.10.0.0 > wired-in package rts mapped to rts-1.0 > wired-in package template-haskell mapped to template-haskell-2.12.0.0 > wired-in package ghc mapped to ghc-8.2.0.20170507 > wired-in package dph-seq not found. > wired-in package dph-par not found. > *** Chasing dependencies: > Chasing modules from: *X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup\setup.hs > Created temporary directory: C:\Users\X\AppData\Local\Temp\ghc3688_0 > *** C pre-processor: > "C:\Progs\Haskell\ghc-8.2.0.20170507\lib/../mingw/bin/gcc.exe" "-E" "-undef" "-traditional" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\process-1.6.0.0\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\directory-1.3.0.2\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\time-1.8.0.1\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\Win32-2.5.4.1\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\bytestring-0.10.8.2\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\base-4.10.0.0\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib\integer-gmp-1.0.0.1\include" "-I" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib/include" "-include" "C:\Progs\Haskell\ghc-8.2.0.20170507\lib/include\ghcversion.h" "-Dmingw32_BUILD_OS" "-Dx86_64_BUILD_ARCH" "-Dmingw32_HOST_OS" "-Dx86_64_HOST_ARCH" "-D__GLASGOW_HASKELL_TH__" "-D__SSE__" "-D__SSE2__" "-includeC:\Users\X\AppData\Local\Temp\ghc3688_0\ghc_2.h" "-x" "assembler-with-cpp" "X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup\setup.hs" "-o" "C:\Users\X\AppData\Local\Temp\ghc3688_0\ghc_1.hscpp" > !!! Chasing dependencies: finished in 31.25 milliseconds, allocated 9.007 megabytes > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2017-06-07 00:19:41.7814384 UTC > ms_mod = Main, > ms_textual_imps = [(Nothing, Prelude), (Nothing, System.Process), > (Nothing, System.Process), (Nothing, System.IO.Unsafe), > (Nothing, System.IO.Error), (Nothing, System.IO), > (Nothing, System.FilePath), (Nothing, System.Exit), > (Nothing, System.Environment), (Nothing, System.Directory), > (Nothing, Distribution.Version), (Nothing, Distribution.Verbosity), > (Nothing, Distribution.System), > (Nothing, Distribution.Simple.Utils), > (Nothing, Distribution.Simple.Setup), > (Nothing, Distribution.Simple.Program.Types), > (Nothing, Distribution.Simple.Program), > (Nothing, Distribution.Simple.PackageIndex), > (Nothing, Distribution.Simple.LocalBuildInfo), > (Nothing, Distribution.Simple.InstallDirs), > (Nothing, Distribution.Simple), (Nothing, Distribution.Make), > (Nothing, Distribution.PackageDescription), > (Nothing, Distribution.Compat.Exception), (Nothing, Data.Map), > (Nothing, Data.Maybe), (Nothing, Data.List.Split), > (Nothing, Data.List), (Nothing, Data.Functor), > (Nothing, Data.Char), (Nothing, Data.ByteString.Lazy), > (Nothing, Control.Monad), (Nothing, Control.Exception)] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: C:\Users\X\AppData\Local\Temp\ghc3688_0\ghc_2.h > compile: input file C:\Users\X\AppData\Local\Temp\ghc3688_0\ghc_1.hscpp > *** Checking old interface for Main (use -ddump-hi-diffs for more details): > [1 of 1] Compiling Main ( X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup\setup.hs, X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup\Main.o ) > *** Parser [Main]: > !!! Parser [Main]: finished in 15.63 milliseconds, allocated 17.654 megabytes > *** Renamer/typechecker [Main]: > !!! Renamer/typechecker [Main]: finished in 125.00 milliseconds, allocated 50.259 megabytes > > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507\wxc\dist\setup\setup.hs:15:27: error: > Module `Distribution.Make' does not export `versionBranch' > | > 15 | import Distribution.Make (versionBranch) > | ^^^^^^^^^^^^^ > Upsweep partially successful. > *** Deleting temp files: > Deleting: C:\Users\X\AppData\Local\Temp\ghc3688_0\ghc_1.hscpp > link(batch): upsweep (partially) failed OR > Main.main not exported; not linking. > *** Deleting temp files: > Deleting: > *** Deleting temp dirs: > Deleting: C:\Users\X\AppData\Local\Temp\ghc3688_0 > C:\Progs\Haskell\ghc-8.2.0.20170507\bin\ghc.exe returned ExitFailure 1 > > 2017-06-07 17:03:22,32 > X:\Temp\wxHaskell-3.0.3-GCC6.2.0-64bit-8.2.0.20170507> From m at jaspervdj.be Sat Jun 10 14:36:37 2017 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Sat, 10 Jun 2017 16:36:37 +0200 Subject: [Haskell-cafe] Last call for presentations: CUFP 2017, September 7-9, Oxford, UK In-Reply-To: <20170607193502.GA3211@colony6> References: <20170607193502.GA3211@colony6> Message-ID: We have extended the deadline until Monday (12th of June). Jasper On Wed, Jun 7, 2017 at 9:35 PM, Jasper Van der Jeugt wrote: > The deadline for CUFP presentations is this friday, the 9th of June. > This CFP and the form for submitting presentations proposals can be > found at: http://cufp.org/2017/call-for-presentations.html > > ------------------------------------------------------------------------ > > 2017 Call for Presentations > > Workshop for Commercial Users of Functional Programming 2017 > Sponsored by SIGPLAN > CUFP 2017 > Co-located with ICFP 2017 > Oxford, UK > September 7-9 > Talk Proposal Submission Deadline: 9 June 2017 > > The annual CUFP event is a place where people can see how others are > using functional programming to solve real world problems; where > practitioners meet and collaborate; where language designers and users > can share ideas about the future of their favorite language; and where > one can learn practical techniques and approaches for putting functional > programming to work. > > ------------------------------------------------------------------------ > > Giving a CUFP Talk > > If you have experience using functional languages in a practical > setting, we invite you to submit a proposal to give a talk at the event. > We're looking for two kinds of talks: > > Retrospective reports are typically 25 minutes long. Now that CUFP has > run for more than a decade, we intend to invite past speakers to share > what they’ve learned after a decade spent as commercial users of > functional programming. We will favour experience reports that include > technical content. > > Technical talks are also 25 minutes long, and should focus on teaching > the audience something about a particular technique or methodology, from > the point of view of someone who has seen it play out in practice. These > talks could cover anything from techniques for building functional > concurrent applications, to managing dynamic reconfigurations, to design > recipes for using types effectively in large-scale applications. While > these talks will often be based on a particular language, they should be > accessible to a broad range of programmers. > > We strongly encourage submissions from people in communities that are > underrepresented in functional programming, including but not limited to > women; people of color; people in gender, sexual and romantic > minorities; people with disabilities; people residing in Asia, Africa, > or Latin America; and people who have never presented at a conference > before. We recognize that inclusion is an important part of our ission > to promote functional programming. So that CUFP can be a safe > environment in which participants openly exchange ideas, we abide by the > SIGPLAN Conference Anti-Harassment Policy: > > http://www.sigplan.org/Resources/Policies/Anti-harassment > > If you are interested in offering a talk, or nominating someone to do > so, please submit your presentation before 09 June 2017 via the CUFP > 2017 Presentation Submission Form: > > https://goo.gl/forms/KPloANxHHwdiaoVj2 > > You do not need to submit a paper, just a short proposal for your talk. > There will be a short scribe's report of the presentations and > discussions but not of the details of individual talks, as the meeting > is intended to be more of a discussion forum than a technical > interchange. > > Nevertheless, presentations will be recorded and presenters will be > expected to sign an ACM copyright release form. > > Note that we will need presenters to register for the CUFP workshop and > travel to Oxford at their own expense. There are some funds available to > would-be presenters who require assistance in this respect. > > ------------------------------------------------------------------------ > > Program Committee > > Alex Lang (Tsuru Capital), co-chair > Rachel Reese (Mulberry Labs), co-chair > Garrett Smith (Guild AI) > Danielle Sucher (Jane Street) > Jasper Van der Jeugt (Fugue) > Yukitoshi Suzuki (Ziosoft) > Evelina Gabasova (University of Cambridge) > Brian Mitchell (Jet.com) > > ------------------------------------------------------------------------ > > More information > > For more information on CUFP, including videos of presentations from > previous years, take a look at the CUFP website at http://cufp.org. Note > that presenters, like other attendees, will need to register for the > event. Acceptance and rejection letters will be sent out by July 15th. > Guidance on giving a great CUFP talk > > Focus on the interesting bits: Think about what will distinguish your > talk, and what will engage the audience, and focus there. There are a > number of places to look for those interesting bits. > > Setting: FP is pretty well-established in some areas, including formal > verification, financial processing, and server-side web services. An > unusual setting can be a source of interest. If you're deploying > FP-based mobile UIs or building servers on oil rigs, then the challenges > of that scenario are worth focusing on. Did FP help or hinder in > adapting to the setting? > > Technology: The CUFP audience is hungry to learn about how FP techniques > work in practice. What design patterns have you applied, and to what > areas? Did you use functional reactive programming for user interfaces, > or DSLs for playing chess, or fault-tolerant actors for large-scale > geological data processing? Teach us something about the techniques you > used, and why we should consider using them ourselves. > > Getting things done: How did you deal with large-scale software > development in the absence of pre-existing support tools that are often > expected in larger commercial environments (IDEs, coverage tools, > debuggers, profilers) and without larger, proven bodies of libraries? > Did you hit any brick walls that required support from the community? > > Don't just be a cheerleader: It's easy to write a rah-rah talk about how > well FP worked for you, but CUFP is more interesting when the talks also > cover what doesn't work. Even when the results were all great, you > should spend more time on the challenges along the way than on the parts > that went smoothly. From daniel.berecz at gmail.com Sun Jun 11 14:34:51 2017 From: daniel.berecz at gmail.com (Daniel Berecz) Date: Sun, 11 Jun 2017 16:34:51 +0200 Subject: [Haskell-cafe] [ANN] Budapest Haskell Hackathon 2017, 29-30th July 2017 Message-ID: Hi everybody, I'm happy to announce that our local user group will hold a Haskell Hackathon in Budapest this year (this will be the second)! We will hold it from the 29th to the 30th of July (Saturday & Sunday). You can find out more on the following link: https://wiki.haskell.org/Budapest_Hackathon_2017 We will reguraly update the site with new information. If you decide to come, please fill out the following Google Form: https://goo.gl/forms/QjTNdXTD1aEOMEQU2 If you have a project, demo, or talk that you want to bring to the event please contact us, and we can talk about the details. You can find our contact info the events wiki site, or you can just contact me directly. The event will be open to people of all experience levels, from beginners to gurus. The only requisite is that you’re interested in the Haskell language, and want to hang out with us, and have a good time! Greetings from Daniel, and the other BP-HUG organizers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sun Jun 11 20:06:00 2017 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 11 Jun 2017 22:06:00 +0200 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: <1497055440-sup-9171@sabre> References: <1496836395-sup-4284@sabre> <1497055440-sup-9171@sabre> Message-ID: cabal new-build works fine, although I now have the problem how to set LIBRARY_PATH to the location of the wxc.dll that is generated during the build of one package and needed for the build of another package. Regards, Henk-Jan van Tuyl On Sat, 10 Jun 2017 03:13:11 +0200, Edward Z. Yang wrote: > Thanks Henk, I know what the problem is. I've filed > a bug here. https://github.com/haskell/cabal/issues/4561 > > In the meantime, you should try giving new-build a try. > I believe it does not suffer from this problem. > http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > > Edward -- 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://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From ezyang at mit.edu Sun Jun 11 20:17:03 2017 From: ezyang at mit.edu (Edward Z. Yang) Date: Sun, 11 Jun 2017 16:17:03 -0400 Subject: [Haskell-cafe] Bug in GHC or cabal-install? In-Reply-To: References: <1496836395-sup-4284@sabre> <1497055440-sup-9171@sabre> Message-ID: <1497212036-sup-6479@sabre> Yeah, my suggestion is to add that other package to the project (or, vice versa, add wxc and co to the new-build of that package.) Edward Excerpts from Henk-Jan van Tuyl's message of 2017-06-11 22:06:00 +0200: > > cabal new-build works fine, although I now have the problem how to set > LIBRARY_PATH to the location of the wxc.dll that is generated during the > build of one package and needed for the build of another package. > > Regards, > Henk-Jan van Tuyl > > On Sat, 10 Jun 2017 03:13:11 +0200, Edward Z. Yang wrote: > > > Thanks Henk, I know what the problem is. I've filed > > a bug here. https://github.com/haskell/cabal/issues/4561 > > > > In the meantime, you should try giving new-build a try. > > I believe it does not suffer from this problem. > > http://cabal.readthedocs.io/en/latest/nix-local-build-overview.html > > > > Edward > From olf at aatal-apotheke.de Sun Jun 11 20:55:30 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 11 Jun 2017 22:55:30 +0200 Subject: [Haskell-cafe] ANNOUNCE: streaming-conduit Message-ID: <7D54901D-2810-4A3F-9AD1-FE64C0A02C37@aatal-apotheke.de> Dear Ivan, I'm confused. The package documentation states that the typical problem to avoid is extracting a long list from IO, which is bound to allocate too much memory. However, if I do preprocess :: IO [a] preprocess = fmap (map (parse :: String -> a) . lines) $ readFile filename then this may create a huge pile of thunks if the rest of the program is not written in a streaming style. But if done right, lazy IO will make sure only the necessary part of the list is kept im memory. For example, a strict function like postprocess :: [a] -> IO () postprocess = mapM (print . f) with some strict f would fit the bill. Did I get the concept of lazy IO wrong? What is the operational semantics of the following fragment? x:xs <- someIOaction :: IO [a] Control.DeepSeq.force x I used to think that xs is now a thunk which, when evalated further, may trigger more (read) IO actions. Hence, would behave as if someIOaction was one of your Streams. I do acknowledge, though, that the style above is easy to go wrong [*], whereas explicitly wrapping each list element in its own monadic action makes the intentions more verbose. Cheers, Olaf [*] If someIOaction needs to touch every list element in order to ensure the result has the shape _:_ then we will indeed have a huge list of thunks. From ivan.miljenovic at gmail.com Mon Jun 12 01:05:45 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 12 Jun 2017 11:05:45 +1000 Subject: [Haskell-cafe] ANNOUNCE: streaming-conduit In-Reply-To: <7D54901D-2810-4A3F-9AD1-FE64C0A02C37@aatal-apotheke.de> References: <7D54901D-2810-4A3F-9AD1-FE64C0A02C37@aatal-apotheke.de> Message-ID: On 12 June 2017 at 06:55, Olaf Klinke wrote: > Dear Ivan, > > I'm confused. The package documentation states that the typical problem to avoid is extracting a long list from IO, which is bound to allocate too much memory. Well, this is the whole point of libraries like streaming, conduit, pipes, etc. but not specifically of streaming-conduit (which is just to help two of these libraries interoperate). > However, if I do > > preprocess :: IO [a] > preprocess = fmap (map (parse :: String -> a) . lines) $ readFile filename > > then this may create a huge pile of thunks if the rest of the program is not written in a streaming style. But if done right, lazy IO will make sure only the necessary part of the list is kept im memory. Lazy I/O works really well if you have just a single input stream that you can read in and process elements of using an existing lazy I/O function such as readFile then write out lazily as well. However, it does require the unsafeInterleaveIO hack in readFile to work properly. I have done stuff like this in production software where great care was taken to ensure it remained lazy and was able to make it stream (even though we had existing streaming use in other parts of the system). In particular, the issue arises in that you have to be able to somehow get the entire result of IO, treat it as a pure value, then do IO with it again... but doing so lazily, which doesn't always work too well. What these libraries do is make that streaming style explicit, so at a low-level you specifically request the next chunk. Taking your preprocess example, the equivalent would be that: 1. You read in a file as a ByteString 2. This is converted to String a chunk at a time 3. This implicit stream of Strings (or possibly just Chars, depending on the implementation) is converted into an explicit Stream of line-based Strings (though 2 and 3 may be switched around) 4. You map the parsing function on each element of the stream. However, at a higher level there are various combinators to take most of this into account for you. Streaming in particular tries to emulate a list-based style, so that `IO [a]` is equivalent to `Stream (Of a) IO r`. The API lets you act like you are operating over a list (and still doing it with function composition, which makes it different from most of the other similar libraries) whilst taking care of the IO for you. This does mean you can't do as much of the "do IO to get value, operate purely on the value then do IO to put it back out", but if you write combinators to do the streaming without specifying which monad it's operating in (and thus being unable to do any IO). See writings like https://stackoverflow.com/questions/5892653/whats-so-bad-about-lazy-i-o and https://www.reddit.com/r/haskell/comments/380kmq/illustrating_the_problem_with_lazy_io/ for more TL;DR: these kinds of libraries allow you to explicitly state how values are streamed throughout your code rather than relying upon the lazy I/O hacks (which if they work for you, go ahead; but if your code gets too complex they start to fail). > For example, a strict function like > > postprocess :: [a] -> IO () > postprocess = mapM (print . f) > > with some strict f would fit the bill. Did I get the concept of lazy IO wrong? What is the operational semantics of the following fragment? > > x:xs <- someIOaction :: IO [a] > Control.DeepSeq.force x > > I used to think that xs is now a thunk which, when evalated further, may trigger more (read) IO actions. Hence, would behave as if someIOaction was one of your Streams. I do acknowledge, though, that the style above is easy to go wrong [*], whereas explicitly wrapping each list element in its own monadic action makes the intentions more verbose. > > Cheers, > Olaf > > [*] If someIOaction needs to touch every list element in order to ensure the result has the shape _:_ then we will indeed have a huge list of thunks. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ben.franksen at online.de Mon Jun 12 08:53:12 2017 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 12 Jun 2017 10:53:12 +0200 Subject: [Haskell-cafe] use of models in proving program properties Message-ID: This is something that has left me puzzled for years. My understanding is that a model is a concrete realization of an abstract structure in terms of some other mathematical structure, such that all the laws from the first are satisfied in the latter. A simple example might be the abstract (algebraic) structure "group" and a concrete realization e.g. the integers with addition. Finding models for abstract theories is certainly useful, for instance it shows that the theory is actually 'inhabited'; it may also shed light on the theory and give us ideas about new theorems that might generalize to the abstract setting. However, nobody would claim that from a theorem about integers I can deduce one for abstract groups in general. But exactly this kind of reasoning appears to be valid when proving things about e.g. the polymorphic lambda calculus (aka System F). For instance, in the famous "free theorems" paper by Wadler, the free theorems appear as a consequence of modeling types in system F as relations (this is most probably oversimplified, i can't remember the details but I think they are not important here). The question is: How can that imply anything about system F itself? Wouldn't it be necessary to prove that these free theorems hold for /all/ models of System F, not just one particular? Besides, if such proofs using a suitable model are really valid, why does it seem to be impossible to 'translate the proof back' from the model to the original system and thus arrive at a direct proof? I am sure there is something wrong with my understanding of these things but I can't figure out what. Cheers Ben From jozefg at cmu.edu Mon Jun 12 09:09:21 2017 From: jozefg at cmu.edu (Danny Gratzer) Date: Mon, 12 Jun 2017 11:09:21 +0200 Subject: [Haskell-cafe] use of models in proving program properties In-Reply-To: References: Message-ID: Let me fix some notation for my answer, we'll say that our theory validates some proposition/judgment P with |- P and that some model M validates a proposition with M |= P. Now, when we define a model there are two properties which are mainly of interest. - Soundness: the most basic property of a model is that if M |= P then |- P. - Completeness: if |- P then M |= P Do note that which direction is "soundness" and which direction is "completeness" varies wildly between different sources. The idea with something like System F is that we'll establish a sound model and, knowing this, it's sufficient to show that our model validates a given proposition in order to conclude that it holds in System F. In parametricity papers for instance "P" would be something expressing "this program is contextually equivalent to that program". Now most models in programming languages fail to complete, meaning that they might not capture every aspect of the theory in question. When we're discussing mainly equality, this property is called "full abstraction" and is sort of the "holy grail" for a model. Don't let this suggest that sound but incomplete models aren't useful, to the contrary they are often the only known way to establish certain equivalence results when it comes to programming languages. Most logical relations (a form of PER model if you like) for general references are incomplete if we disallow appeals to things like biorthogonality or closure under contextual equivalence. Your example with groups is sort of canonically the opposite, there you have a complete but unsound model. This direction is useful for abstract algebra where the goal is to understand the model using the theory. In programming languages we usually have the opposite problem, we don't understand the theory very well but we have a comparatively strong understanding of the model. As for why it's a useful trick to construct models in the first place, remember that directly showing the proof is often incredibly difficult. While it may be in theory possible to circumvent a model it's often the only feasible way of proving something. Hopefully some of that makes some amount of sense. Danny -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Mon Jun 12 12:37:34 2017 From: publicityifl at gmail.com (publicityifl at gmail.com) Date: Mon, 12 Jun 2017 12:37:34 +0000 Subject: [Haskell-cafe] 1st CfP: IFL 2017 (29th Symposium on Implementation and Application of Functional Languages) Message-ID: <94eb2c07c31853e9e60551c29594@google.com>
Hello,

Please, find below the first call for papers for IFL 2017.
Please forward these to anyone you think may be interested.
Apologies for any duplicates you may receive.

best regards,
Jurriaan Hage
Publicity Chair of IFL

---

IFL 2017 - CALL FOR PAPERS
==========================

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

University of Bristol, UK

In cooperation with ACM SIGPLAN

Wednesday 30 August - Friday 1 September, 2017

http://iflconference.org/

Scope
-----

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

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

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

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

The submissions will be screened by the program committee chair to make sure
they are within the scope of IFL, and will appear in the draft proceedings
distributed at the symposium. Submissions appearing in the draft proceedings
are not peer-reviewed publications. Hence, publications that appear only in the
draft proceedings are not subject to the ACM SIGPLAN republication policy.
After the symposium, authors will be given the opportunity to incorporate the
feedback from discussions at the symposium and will be invited to submit a
revised full article for the formal review process. From the revised
submissions, the program committee will select papers for the formal
proceedings considering their correctness, novelty, originality, relevance,
significance, and clarity. The formal proceedings will appear in the
International Conference Proceedings Series of the ACM Digital Library.

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

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

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

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

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

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

Authors submit through EasyChair:

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

Topics
------

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

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

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

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

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

Chair: Nicolas Wu, University of Bristol, UK

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

Venue
-----

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

 

powered by GSM. Free mail merge and email marketing software for Gmail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Mon Jun 12 17:46:28 2017 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 12 Jun 2017 19:46:28 +0200 Subject: [Haskell-cafe] use of models in proving program properties In-Reply-To: References: Message-ID: Hi Danny thanks for your answer. It confirms the suspicion I had, namely that my understanding of what a model is was wrong or perhaps taken from the wrong context. Wikipedia says (https://en.wikipedia.org/wiki/Model_theory): "A set of sentences in a formal language is called a theory; a model of a theory is a structure (e.g. an interpretation) that satisfies the sentences of that theory." In your diction, this definition of a model implies completeness, but not (necessarily) soundness and this is how I understood the word. So, model means something different in CS or Type Theory than in Model Theory? More concretely, the relational model of System F really is sound (in the sense in which you defined it below), yes? So, using the above Wikipedia definition, it would make more sense to say that System F is a model of "types as relations"... (sorry for being unable to express this more precisely). Cheers Ben Am 12.06.2017 um 11:09 schrieb Danny Gratzer: > Let me fix some notation for my answer, we'll say that our theory validates > some proposition/judgment > P with |- P and that some model M validates a proposition with M |= P. Now, > when we define a model there > are two properties which are mainly of interest. > > - Soundness: the most basic property of a model is that if M |= P then |- > P. > - Completeness: if |- P then M |= P > > Do note that which direction is "soundness" and which direction is > "completeness" varies wildly between different > sources. The idea with something like System F is that we'll establish a > sound model and, knowing this, it's sufficient > to show that our model validates a given proposition in order to conclude > that it holds in System F. In parametricity papers > for instance "P" would be something expressing "this program is > contextually equivalent to that program". Now most models > in programming languages fail to complete, meaning that they might not > capture every aspect of the theory in question. When > we're discussing mainly equality, this property is called "full > abstraction" and is sort of the "holy grail" for a model. Don't let > this suggest that sound but incomplete models aren't useful, to the > contrary they are often the only known way to establish certain > equivalence results when it comes to programming languages. Most logical > relations (a form of PER model if you like) for general > references are incomplete if we disallow appeals to things like > biorthogonality or closure under contextual equivalence. > > Your example with groups is sort of canonically the opposite, there you > have a complete but unsound model. This direction is useful > for abstract algebra where the goal is to understand the model using the > theory. In programming languages we usually have the > opposite problem, we don't understand the theory very well but we have a > comparatively strong understanding of the model. > > As for why it's a useful trick to construct models in the first place, > remember that directly showing the proof is often incredibly difficult. > While it may be in theory possible to circumvent a model it's often the > only feasible way of proving something. > > Hopefully some of that makes some amount of sense. > > Danny > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ivan.perez at keera.co.uk Tue Jun 13 15:14:31 2017 From: ivan.perez at keera.co.uk (Ivan Perez) Date: Tue, 13 Jun 2017 17:14:31 +0200 Subject: [Haskell-cafe] [Announcement] Haskell game for iOS Message-ID: Dear all (I hope this is not seen as spam. My sincere apologies if you see it as such.) This is just to let you know that we have released a Haskell game for iOS on the App Store. https://itunes.apple.com/us/app/magic-cookies/id1244709871 There is also an Android version [1]. It's the same Haskell code with just a few minor adaptations [2] (the iOS version is actually simpler). Issues with either version can be reported online [3]. I hope this is seen as yet another step reached by Haskell. This game is written in the FRP variant Yampa, and uses SDL2 for graphics. While the game is not open source, we've had to extend existing Haskell libraries and tools to make this possible. These changes will now be sent as pull requests to the corresponding projects. We have also developed in-house tooling to make the development, compilation and deployment process for mobile platforms smooth [4]. Recompiling and deploying a new version online is now automatic and takes less than 1 minute. These tools also run directly on Travis and publish new versions of our games directly to stores. We have already started distributing our toolchain to private users, and our plan is to release immediately. We'd like to thank all the users who tried the game before the release, many during Zurihac last weekend. Also, many thanks to the people who worked on GHC and the ARM backends over the years, and to all those who work daily to make Haskell better. We really mean that. Once again, I hope this is not seen as spam, but as something worth celebrating. And, also, that you enjoy playing. Best wishes Ivan -- Keera Studios [1] https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies [2] https://www.facebook.com/keerastudios/photos/a.301326223216244.89053.300854939930039/1701909406491245/?type=3 [3] https://github.com/keera-studios/magic-cookies [4] http://keera.co.uk/blog/2017/06/01/haskell-android-ios/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquagnu at gmail.com Tue Jun 13 15:47:09 2017 From: aquagnu at gmail.com (Baa) Date: Tue, 13 Jun 2017 18:47:09 +0300 Subject: [Haskell-cafe] [Announcement] Haskell game for iOS In-Reply-To: References: Message-ID: <20170613184709.3fbca72a@Pavel> Hello, Ivan. Would you like to describe: how big is your game in Megabytes without any compression (interesting is binaries, not sprites, media, etc assets)? And how many time/human resources did you spent to release it? --- Best regards, Paul > Dear all > > (I hope this is not seen as spam. My sincere apologies if you see it > as such.) > > This is just to let you know that we have released a Haskell game for > iOS on the App Store. > > https://itunes.apple.com/us/app/magic-cookies/id1244709871 > > There is also an Android version [1]. It's the same Haskell code with > just a few minor adaptations [2] (the iOS version is actually > simpler). Issues with either version can be reported online [3]. > > I hope this is seen as yet another step reached by Haskell. This game > is written in the FRP variant Yampa, and uses SDL2 for graphics. > While the game is not open source, we've had to extend existing > Haskell libraries and tools to make this possible. These changes will > now be sent as pull requests to the corresponding projects. > > We have also developed in-house tooling to make the development, > compilation and deployment process for mobile platforms smooth [4]. > Recompiling and deploying a new version online is now automatic and > takes less than 1 minute. These tools also run directly on Travis and > publish new versions of our games directly to stores. We have already > started distributing our toolchain to private users, and our plan is > to release immediately. > > We'd like to thank all the users who tried the game before the > release, many during Zurihac last weekend. Also, many thanks to the > people who worked on GHC and the ARM backends over the years, and to > all those who work daily to make Haskell better. We really mean that. > > Once again, I hope this is not seen as spam, but as something worth > celebrating. > > And, also, that you enjoy playing. > > Best wishes > > Ivan > > -- Keera Studios > > [1] > https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies > > [2] > https://www.facebook.com/keerastudios/photos/a.301326223216244.89053.300854939930039/1701909406491245/?type=3 > > [3] https://github.com/keera-studios/magic-cookies > > [4] http://keera.co.uk/blog/2017/06/01/haskell-android-ios/ From benjamin.redelings at gmail.com Tue Jun 13 15:47:18 2017 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Tue, 13 Jun 2017 11:47:18 -0400 Subject: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy Message-ID: <31991b9f-0389-2807-c74a-c857e3707d71@gmail.com> Hi, I'm working on a project to implement support for probabilistic programming with models written as Haskell programs. This is similar to Bayesian graphical models (e.g. BUGS, JAGS) and to full probabilistic programming systems like Church / Venture. http://www.bali-phy.org/models.php This project is not very mature, but it is used as the core of the MCMC software mentioned above, which is relatively mature. Probabilistic programs are written using the probability monad. I've implemented a Haskell interpreter in C++ that records execution traces of the Haskell programs. These execution traces depend on some number of (random) variables, and when one of the variables is changed (during MCMC), the parts of the execution trace that depend on the changed variables are invalidated and recomputed. This saves work by not recomputing the probability of the new state from scratch. I can provide DOT graphs of the execution traces if anyone is interested. The problem domain I've been focusing on is evolution of DNA sequences on binary trees. You can see some of the code for that problem domain here: https://github.com/bredelings/BAli-Phy/blob/master/modules/ The code for the interpreter is here: https://github.com/bredelings/BAli-Phy/blob/master/src/computation/ -BenRI From sivanov at colimite.fr Tue Jun 13 16:30:55 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Tue, 13 Jun 2017 18:30:55 +0200 Subject: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy In-Reply-To: <31991b9f-0389-2807-c74a-c857e3707d71@gmail.com> References: <31991b9f-0389-2807-c74a-c857e3707d71@gmail.com> Message-ID: <8760fz6e9s.fsf@colimite.fr> Hello Benjamin, Thus quoth Benjamin Redelings at 15:47 on Tue, Jun 13 2017: > > I'm working on a project to implement support for probabilistic > programming with models written as Haskell programs. This is similar to > Bayesian graphical models (e.g. BUGS, JAGS) and to full probabilistic > programming systems like Church / Venture. > > http://www.bali-phy.org/models.php This project looks very interesting to me and seems to be a result of an impressive amount of work! Thank you for the announcement. > Probabilistic programs are written using the probability monad. > > I've implemented a Haskell interpreter in C++ that records execution > traces of the Haskell programs. Is your probability monad an actual monad that you implemented in a Haskell package, or is it a consequence of the fact that you are running Haskell-like programs in your interpreter? More generally: how deep can the interoperability between your project and some other Haskell code go? > These execution traces depend on some number of (random) variables, > and when one of the variables is changed (during MCMC), the parts of > the execution trace that depend on the changed variables are > invalidated and recomputed. This saves work by not recomputing the > probability of the new state from scratch. I can provide DOT graphs > of the execution traces if anyone is interested. That sounds really cool! > The problem domain I've been focusing on is evolution of DNA sequences > on binary trees. I'm very much interested in your project because I often look into non-deterministic evolution of some abstract computing devices, and you actually seem to be focusing on a similar use case. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From olf at aatal-apotheke.de Wed Jun 14 20:58:01 2017 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 14 Jun 2017 22:58:01 +0200 Subject: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy Message-ID: Benjamin, I'm also excited to see more probabilistic programming in Haskell. Adding to Sergiu's questions I'd like to know why you chose to implement a new interpreter instead of making an embedded domain-specific language. Are there C++ libraries that were convenient to use? As theorist I'm curious whether you have a denotational semantics in mind. Can you decribe the building blocks of your language? The examples show primitives for known families of distributions (e.g. beta). Then there is Observe, which seems to compute conditional distributions. What else is there beyond ordinary Haskell? Cheers, Olaf From ivan.miljenovic at gmail.com Thu Jun 15 09:38:22 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 15 Jun 2017 19:38:22 +1000 Subject: [Haskell-cafe] Error-containing Maybes Message-ID: The Maybe type is often (almost always?) used to indicate that a computation may fail; specifically, `Maybe a` typically indicates that it may not be possible to always produce a value of type `a`. However, there are times when the inverse of this is desirable (usually within a monadic/side-effectful context): if Nothing is returned then the computation was a success; otherwise, an error message is returned. Whilst this usage definitely fits the types, it breaks the mould of how we think/use Maybe in most cases and may at times cause confusion. As such, it may be advisable (and I know I've done this at least once) to define a `data Result e = Error e | Success` data type to model this behaviour. Is this a typical enough requirement that would make it worth adding such a datatype to base (despite my usual aversion to piling more things in there) or having a library up on Hackage just for this very simplistic type? (Another option would be to use `Either error ()`, which could be lifted better into an ExceptT result, albeit with the additional useless parameter/value in there.) -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From palotai.robin at gmail.com Thu Jun 15 10:21:17 2017 From: palotai.robin at gmail.com (Robin Palotai) Date: Thu, 15 Jun 2017 12:21:17 +0200 Subject: [Haskell-cafe] Error-containing Maybes In-Reply-To: References: Message-ID: See https://hackage.haskell.org/package/errors-2.2.0/docs/Data-EitherR.html for somewhat related type. How about `type Result e = Either e ()` ? 2017-06-15 11:38 GMT+02:00 Ivan Lazar Miljenovic : > The Maybe type is often (almost always?) used to indicate that a > computation may fail; specifically, `Maybe a` typically indicates that > it may not be possible to always produce a value of type `a`. > > However, there are times when the inverse of this is desirable > (usually within a monadic/side-effectful context): if Nothing is > returned then the computation was a success; otherwise, an error > message is returned. Whilst this usage definitely fits the types, it > breaks the mould of how we think/use Maybe in most cases and may at > times cause confusion. As such, it may be advisable (and I know I've > done this at least once) to define a `data Result e = Error e | > Success` data type to model this behaviour. > > Is this a typical enough requirement that would make it worth adding > such a datatype to base (despite my usual aversion to piling more > things in there) or having a library up on Hackage just for this very > simplistic type? > > (Another option would be to use `Either error ()`, which could be > lifted better into an ExceptT result, albeit with the additional > useless parameter/value in there.) > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlatko.basic at gmail.com Thu Jun 15 10:25:02 2017 From: vlatko.basic at gmail.com (Vlatko Basic) Date: Thu, 15 Jun 2017 12:25:02 +0200 Subject: [Haskell-cafe] Error-containing Maybes In-Reply-To: References: Message-ID: <1d773439-2b27-1ad5-b365-aff204c49ba5@gmail.com> Something similar to what EitherR does? https://hackage.haskell.org/package/errors-2.2.0/docs/Data-EitherR.html -------- Original Message -------- Subject: [Haskell-cafe] Error-containing Maybes From: Ivan Lazar Miljenovic To: Haskell Cafe Date: 15/06/17 11:38 > The Maybe type is often (almost always?) used to indicate that a > computation may fail; specifically, `Maybe a` typically indicates that > it may not be possible to always produce a value of type `a`. > > However, there are times when the inverse of this is desirable > (usually within a monadic/side-effectful context): if Nothing is > returned then the computation was a success; otherwise, an error > message is returned. Whilst this usage definitely fits the types, it > breaks the mould of how we think/use Maybe in most cases and may at > times cause confusion. As such, it may be advisable (and I know I've > done this at least once) to define a `data Result e = Error e | > Success` data type to model this behaviour. > > Is this a typical enough requirement that would make it worth adding > such a datatype to base (despite my usual aversion to piling more > things in there) or having a library up on Hackage just for this very > simplistic type? > > (Another option would be to use `Either error ()`, which could be > lifted better into an ExceptT result, albeit with the additional > useless parameter/value in there.) > From ivan.miljenovic at gmail.com Thu Jun 15 10:30:53 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 15 Jun 2017 20:30:53 +1000 Subject: [Haskell-cafe] Error-containing Maybes In-Reply-To: References: Message-ID: On 15 June 2017 at 20:21, Robin Palotai wrote: > See https://hackage.haskell.org/package/errors-2.2.0/docs/Data-EitherR.html > for somewhat related type. Ahah, wasn't aware of that package. > How about `type Result e = Either e ()` ? I did mention that at the end of my email ;-) > > 2017-06-15 11:38 GMT+02:00 Ivan Lazar Miljenovic > : >> >> The Maybe type is often (almost always?) used to indicate that a >> computation may fail; specifically, `Maybe a` typically indicates that >> it may not be possible to always produce a value of type `a`. >> >> However, there are times when the inverse of this is desirable >> (usually within a monadic/side-effectful context): if Nothing is >> returned then the computation was a success; otherwise, an error >> message is returned. Whilst this usage definitely fits the types, it >> breaks the mould of how we think/use Maybe in most cases and may at >> times cause confusion. As such, it may be advisable (and I know I've >> done this at least once) to define a `data Result e = Error e | >> Success` data type to model this behaviour. >> >> Is this a typical enough requirement that would make it worth adding >> such a datatype to base (despite my usual aversion to piling more >> things in there) or having a library up on Hackage just for this very >> simplistic type? >> >> (Another option would be to use `Either error ()`, which could be >> lifted better into an ExceptT result, albeit with the additional >> useless parameter/value in there.) >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From oleg at okmij.org Thu Jun 15 11:29:13 2017 From: oleg at okmij.org (Oleg) Date: Thu, 15 Jun 2017 20:29:13 +0900 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy Message-ID: <20170615112913.GA7093@Magus.localnet> It seems worth mentioning then another Haskell embedded language for probabilistic programming http://okmij.org/ftp/kakuritu/Hakaru10/index.html It also lets us write probabilistic models as Haskell programs. It supports both discrete and continuous distributions, conditioning, as well as branching (mixing models). It takes care to statically preclude senseless models (forcing conditioning only on external data). The 'Model' is *not* a monad. Not everything can be or should be a monad. Hakaru10 also takes care to avoid the problems that are frequent in implementations of Wingate algorithms. It also uses incremental evaluation. As to semantic problems of probabilistic programming languages, http://okmij.org/ftp/kakuritu/index.html shows a couple of them. From sivanov at colimite.fr Thu Jun 15 11:44:32 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Thu, 15 Jun 2017 13:44:32 +0200 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: <20170615112913.GA7093@Magus.localnet> References: <20170615112913.GA7093@Magus.localnet> Message-ID: <87k24d4grj.fsf@colimite.fr> Hello Oleg, Thus quoth Oleg at 11:29 on Thu, Jun 15 2017: > > It seems worth mentioning then another Haskell embedded language for > probabilistic programming > > http://okmij.org/ftp/kakuritu/Hakaru10/index.html [...] > As to semantic problems of probabilistic programming languages, > http://okmij.org/ftp/kakuritu/index.html > shows a couple of them. Thanks a lot for the references! I'll keep them at hand. (And yes, I do agree that not everything should be a monad :-) ) -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From aquagnu at gmail.com Thu Jun 15 14:11:21 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 15 Jun 2017 17:11:21 +0300 Subject: [Haskell-cafe] MultiCase alternative Message-ID: <20170615171121.556106b0@Pavel> Hello, Everyone! As I understand "MultiCase" proposal was not approved, so my question is: is there alternatives to multi-case? I have code like: case x of A a -> .. B b -> .. C c -> --same-- D c -> --same-- and I want to merge code of "C c" with "D c" branch. Anywhere, in general: is any alternatives to make "OR"s in patterns? I don't see how to do it with pattern guards, pattern synonyms, views extensions and don't see another related extensions. Something like "(C|D) c -> ..." === Best regards, Paul From spam at scientician.net Thu Jun 15 14:31:19 2017 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 15 Jun 2017 16:31:19 +0200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615171121.556106b0@Pavel> References: <20170615171121.556106b0@Pavel> Message-ID: On 2017-06-15 16:11, Baa wrote: > Hello, Everyone! > > As I understand "MultiCase" proposal was not approved, so my question > is: is there alternatives to multi-case? I have code like: > > case x of > A a -> .. > B b -> .. > C c -> --same-- > D c -> --same-- > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > general: is any alternatives to make "OR"s in patterns? I don't see how > to do it with pattern guards, pattern synonyms, views extensions and > don't see another related extensions. > Create a function. Regards, From bneijt at gmail.com Thu Jun 15 14:33:57 2017 From: bneijt at gmail.com (Bram Neijt) Date: Thu, 15 Jun 2017 14:33:57 +0000 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615171121.556106b0@Pavel> References: <20170615171121.556106b0@Pavel> Message-ID: Hi Paul, I'm nit experienced in Haskell, so I don't have a solution. But the following keywords spring to mind: Ignore the syntactic sugar and see if any of the alternative syntaxes are more flexible https://wiki.haskell.org/Case Create a DSL. Greetings, Bram On Thu, 15 Jun 2017, 16:13 Baa, wrote: > Hello, Everyone! > > As I understand "MultiCase" proposal was not approved, so my question > is: is there alternatives to multi-case? I have code like: > > case x of > A a -> .. > B b -> .. > C c -> --same-- > D c -> --same-- > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > general: is any alternatives to make "OR"s in patterns? I don't see how > to do it with pattern guards, pattern synonyms, views extensions and > don't see another related extensions. > > Something like "(C|D) c -> ..." > > > === > Best regards, Paul > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Thu Jun 15 14:42:44 2017 From: lysxia at gmail.com (Li-yao Xia) Date: Thu, 15 Jun 2017 10:42:44 -0400 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615171121.556106b0@Pavel> References: <20170615171121.556106b0@Pavel> Message-ID: <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> Hi Paul, This looks like the or-patterns proposal: https://github.com/ghc-proposals/ghc-proposals/pull/43 I'm not sure what you call MultiCase though. Is the above what you were refering to? Here are some alternatives with current Haskell, the first one is to be preferred: - Factor out the alternatives in a function. ... case x of ... C c -> f c D c -> f c where f c = ... - If your C and D constructors have similar enough meanings, you might want to fuse them into a single constructor with a separate tag: data T = A TA | B TB | CD CorD TC data CorD = C | D so that you can write case x of ... CD _ c -> ... - With pattern synonyms + view patterns, although it takes some effort to set up and confuses the exhaustiveness checker. matchCorD :: T -> Maybe C matchCorD (C c) = Just c matchCorD (D c) = Just c matchCorD _ = Nothing pattern CD :: C -> T pattern CD c <- (matchCorD -> Just c) you can now write case x of ... CD c -> ... Li-yao On 06/15/2017 10:11 AM, Baa wrote: > Hello, Everyone! > > As I understand "MultiCase" proposal was not approved, so my question > is: is there alternatives to multi-case? I have code like: > > case x of > A a -> .. > B b -> .. > C c -> --same-- > D c -> --same-- > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > general: is any alternatives to make "OR"s in patterns? I don't see how > to do it with pattern guards, pattern synonyms, views extensions and > don't see another related extensions. > > Something like "(C|D) c -> ..." > > > === > Best regards, Paul > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From sylvain at haskus.fr Thu Jun 15 14:46:23 2017 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 15 Jun 2017 16:46:23 +0200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615171121.556106b0@Pavel> References: <20170615171121.556106b0@Pavel> Message-ID: <5eb85193-b0ae-cdce-3a76-3afb023e0722@haskus.fr> Hi, You can combine ViewPatterns and PatternSynonyms to obtain this desired effect: {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} data X a b c = A a | B b | C c | D c deriving (Show) cOrD :: X a b c -> Maybe c cOrD (A _) = Nothing cOrD (B _) = Nothing cOrD (C c) = Just c cOrD (D c) = Just c pattern CorD :: c -> X a b c pattern CorD c <- (cOrD -> Just c) main :: IO () main = do let -- x = A "An a" :: X String String String -- x = B "A b" :: X String String String x = C "A c" :: X String String String --x = D "A d" :: X String String String case x of A a -> putStrLn ("A:" ++ show a) B b -> putStrLn ("B:" ++ show b) CorD c -> putStrLn ("CorD:" ++ show c) Note that you lose completeness checking: Test.hs:30:4: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (C _) (D _) Cheers, Sylvain On 15/06/2017 16:11, Baa wrote: > Hello, Everyone! > > As I understand "MultiCase" proposal was not approved, so my question > is: is there alternatives to multi-case? I have code like: > > case x of > A a -> .. > B b -> .. > C c -> --same-- > D c -> --same-- > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > general: is any alternatives to make "OR"s in patterns? I don't see how > to do it with pattern guards, pattern synonyms, views extensions and > don't see another related extensions. > > Something like "(C|D) c -> ..." > > > === > Best regards, Paul > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From aquagnu at gmail.com Thu Jun 15 14:46:41 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 15 Jun 2017 17:46:41 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> Message-ID: <20170615174641.380909d3@Pavel> Hmm, seems there is a way: {-# LANGUAGE ViewPatterns #-} isCD (C c) = c isCD (D c) = c case x of A a -> .. B b -> .. (isCD -> x) -> ..process-x.. > On 2017-06-15 16:11, Baa wrote: > > Hello, Everyone! > > > > As I understand "MultiCase" proposal was not approved, so my > > question is: is there alternatives to multi-case? I have code like: > > > > case x of > > A a -> .. > > B b -> .. > > C c -> --same-- > > D c -> --same-- > > > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > > general: is any alternatives to make "OR"s in patterns? I don't see > > how to do it with pattern guards, pattern synonyms, views > > extensions and don't see another related extensions. > > > > Create a function. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 aquagnu at gmail.com Thu Jun 15 14:54:35 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 15 Jun 2017 17:54:35 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> Message-ID: <20170615175435.0b03f462@Pavel> Hello, Li-yao! I mean this: https://wiki.haskell.org/MultiCase > Hi Paul, > > This looks like the or-patterns proposal: > > https://github.com/ghc-proposals/ghc-proposals/pull/43 > > I'm not sure what you call MultiCase though. Is the above what you > were refering to? > > Here are some alternatives with current Haskell, the first one is to > be preferred: > > - Factor out the alternatives in a function. > > ... > case x of > ... > C c -> f c > D c -> f c > where > f c = ... > > - If your C and D constructors have similar enough meanings, you > might want to fuse them into a single constructor with a separate tag: > > data T = A TA | B TB | CD CorD TC > data CorD = C | D > > so that you can write > > case x of > ... > CD _ c -> ... > > - With pattern synonyms + view patterns, although it takes some > effort to set up and confuses the exhaustiveness checker. > > matchCorD :: T -> Maybe C > matchCorD (C c) = Just c > matchCorD (D c) = Just c > matchCorD _ = Nothing > > pattern CD :: C -> T > pattern CD c <- (matchCorD -> Just c) > > you can now write > > case x of > ... > CD c -> ... > > Li-yao > > > On 06/15/2017 10:11 AM, Baa wrote: > > Hello, Everyone! > > > > As I understand "MultiCase" proposal was not approved, so my > > question is: is there alternatives to multi-case? I have code like: > > > > case x of > > A a -> .. > > B b -> .. > > C c -> --same-- > > D c -> --same-- > > > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > > general: is any alternatives to make "OR"s in patterns? I don't see > > how to do it with pattern guards, pattern synonyms, views > > extensions and don't see another related extensions. > > > > Something like "(C|D) c -> ..." > > > > > > === > > Best regards, Paul > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > From aquagnu at gmail.com Thu Jun 15 14:58:58 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 15 Jun 2017 17:58:58 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <5eb85193-b0ae-cdce-3a76-3afb023e0722@haskus.fr> References: <20170615171121.556106b0@Pavel> <5eb85193-b0ae-cdce-3a76-3afb023e0722@haskus.fr> Message-ID: <20170615175858.165b4423@Pavel> Hmm, Sylvain, this is more interesting than my variant. Thank you a lot! > Hi, > > You can combine ViewPatterns and PatternSynonyms to obtain this > desired effect: > > {-# LANGUAGE ViewPatterns #-} > {-# LANGUAGE PatternSynonyms #-} > > data X a b c > = A a > | B b > | C c > | D c > deriving (Show) > > > cOrD :: X a b c -> Maybe c > cOrD (A _) = Nothing > cOrD (B _) = Nothing > cOrD (C c) = Just c > cOrD (D c) = Just c > > pattern CorD :: c -> X a b c > pattern CorD c <- (cOrD -> Just c) > > main :: IO () > main = do > let > -- x = A "An a" :: X String String String > -- x = B "A b" :: X String String String > x = C "A c" :: X String String String > --x = D "A d" :: X String String String > > case x of > A a -> putStrLn ("A:" ++ show a) > B b -> putStrLn ("B:" ++ show b) > CorD c -> putStrLn ("CorD:" ++ show c) > > > Note that you lose completeness checking: > > Test.hs:30:4: warning: [-Wincomplete-patterns] > Pattern match(es) are non-exhaustive > In a case alternative: > Patterns not matched: > (C _) > (D _) > > Cheers, > Sylvain > > > On 15/06/2017 16:11, Baa wrote: > > Hello, Everyone! > > > > As I understand "MultiCase" proposal was not approved, so my > > question is: is there alternatives to multi-case? I have code like: > > > > case x of > > A a -> .. > > B b -> .. > > C c -> --same-- > > D c -> --same-- > > > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > > general: is any alternatives to make "OR"s in patterns? I don't see > > how to do it with pattern guards, pattern synonyms, views > > extensions and don't see another related extensions. > > > > Something like "(C|D) c -> ..." > > > > > > === > > Best regards, Paul > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 taylor at fausak.me Thu Jun 15 15:08:44 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 15 Jun 2017 10:08:44 -0500 Subject: [Haskell-cafe] Issue 59 :: Haskell Weekly Message-ID: <1497539324.1047371.1010530552.49DB3308@webmail.messagingengine.com> \ Haskell Weekly \/\/ Issue 59 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what's going on in its community. ## Featured - Haskell on Android and iOS > With our framework, writing professional Haskell apps and games becomes a reality. In minutes one can have the complete toolchain and see the first app running on a phone or published on the online store. If you weren't considering using Haskell yet, we hope you soon change your mind. - Translating a C++ parser to Haskell > Recently I translated Nix's derivation parser to Haskell and I thought this would make an instructive example for how C++ idioms map to Haskell idioms. This post targets people who understand Haskell's basic syntax but perhaps have difficulty translating imperative style to a functional style. - The `ReaderT` design pattern > What many languages address via patterns, in Haskell we address via language features (like built-in immutability, lambdas, laziness, etc.). However, I believe there is still room for some high-level guidance on structuring programs, which I'll loosely refer to as a Haskell design pattern. - Front Row is hiring a senior backend Haskell engineer (ad) > Come change how 6.5+ million K-12 US students learn Math, Language Arts, Social Studies and more. Use data, advanced type systems, great product design and deep pedagogy to change lives. - 10 things Idris improved over Haskell > This post describes some of the pleasant surprises you get trying out Idris, coming from the Haskell world. These pleasant surprises have nothing to do with the dependent typing features. They are simple yet impacting modifications, which improve the developer experience substantially. - Migrating text metrics to pure Haskell > text-metrics-0.3.0 is written in pure Haskell, almost as fast as the previous versions (especially for not very long inputs), and is more correct (we handle characters represented as two `Word16` values properly). - ZuriHac 2017 recap > This was my first time attending ZuriHac and it was too much fun --- will definitely be back next year! Big thanks to Jasper Van der Jeugt, Simon Meier, and all of the HSR folks that made the event happen. Props to the Haskell community too for being friendly and inviting. - Haddock markup quick reference > This page is a single-page quick reference for the markup used in GHC's Haddock documentation format. It doesn't list all the details of the format, just the basic markup, so for the vagaries and edge-cases of the syntax, it would be helpful to consult the Haddock user guide. - Haskell Summer of Code > The performance tests do two things: first, they make sure that when people change the compiler, they don't accidentally make it slower; secondly, they make sure that when people change the compiler, they don't accidentally make the generated code less efficient. - Use hpack > One of the remaining problems is that the `project.cabal` file is in a custom format. Custom formats are generally not good because you can't leverage the existing tools and free-ride other people's work. - Haskell taketh away: Limiting side effects for parallel programming > In designing parallel programming abstractions, taking away user capabilities is as important as granting them. In this talk, I'll explain the role of this idea in several different parallel programming libraries for Haskell, C++, and other languages --- spanning from shared memory to big data. ## Package of the week This week's package of the week is generic-lens, a library that exposes generic data structure operations as lenses. ## In brief - Binary instances for GADTs (or: RTTI in Haskell) - Data structures are antithetical to functional programming - Drive-by Haskell contributions - On friendly contributing policies - Taking a close look at lenses - Teaching Haskell for understanding - The Haskell Cast episode 14: Richard Eisenberg on dependent types From malcolm.wallace at me.com Thu Jun 15 14:27:10 2017 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 15 Jun 2017 15:27:10 +0100 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615171121.556106b0@Pavel> References: <20170615171121.556106b0@Pavel> Message-ID: <038A880F-A20F-4AE9-80EA-CF1F754EFC76@me.com> case x of A a -> .. B b -> .. C c -> f c D d -> f d where f cd = ... On 15 Jun 2017, at 15:11, Baa wrote: > Hello, Everyone! > > As I understand "MultiCase" proposal was not approved, so my question > is: is there alternatives to multi-case? I have code like: > > case x of > A a -> .. > B b -> .. > C c -> --same-- > D c -> --same-- > > and I want to merge code of "C c" with "D c" branch. Anywhere, in > general: is any alternatives to make "OR"s in patterns? I don't see how > to do it with pattern guards, pattern synonyms, views extensions and > don't see another related extensions. > > Something like "(C|D) c -> ..." > > > === > Best regards, Paul > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From alexander.kjeldaas at gmail.com Thu Jun 15 18:42:12 2017 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Thu, 15 Jun 2017 20:42:12 +0200 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: <87k24d4grj.fsf@colimite.fr> References: <20170615112913.GA7093@Magus.localnet> <87k24d4grj.fsf@colimite.fr> Message-ID: I guess https://github.com/adscib/monad-bayes is relevant as well. On Thu, Jun 15, 2017 at 1:44 PM, Sergiu Ivanov wrote: > Hello Oleg, > > Thus quoth Oleg at 11:29 on Thu, Jun 15 2017: > > > > It seems worth mentioning then another Haskell embedded language for > > probabilistic programming > > > > http://okmij.org/ftp/kakuritu/Hakaru10/index.html > [...] > > As to semantic problems of probabilistic programming languages, > > http://okmij.org/ftp/kakuritu/index.html > > shows a couple of them. > > Thanks a lot for the references! I'll keep them at hand. > > (And yes, I do agree that not everything should be a monad :-) ) > > -- > Sergiu > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Thu Jun 15 20:16:10 2017 From: monkleyon at gmail.com (MarLinn) Date: Thu, 15 Jun 2017 22:16:10 +0200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170615175435.0b03f462@Pavel> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> Message-ID: <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> > Hello, Li-yao! I mean this: https://wiki.haskell.org/MultiCase > >> Hi Paul, >> >> This looks like the or-patterns proposal: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/43 >> >> You can see on github that it's just "dormant". But the examples in this thread made me have an interesting, even more general idea: we have functions on term-level and type-level – why not on pattern-level? Here's a very rough draft of what I imagine: {-# LANGUAGE PatternFamilies, PatternKinds #-} data Dt a = A a | B a | C a | D a deriving ( Show ) pattern (∥) ∷ (Pattern a → T) → (Pattern a → T) → (T → U) → (a → U) pattern (a ∥ _) f = f a pattern (_ ∥ b) f = f b infixl 2 pattern ∥ foo ∷ (Show a) ⇒ Dt a → String foo (A a) = … foo (B b) = … foo (C c ∥ D d) = … No, I don't think that's worth drawing up a proposal yet. I just want to document the idea. Maybe it can inspire someone who's building their own language or something. Cheers, MarLinn From sivanov at colimite.fr Thu Jun 15 20:42:06 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Thu, 15 Jun 2017 22:42:06 +0200 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: References: <20170615112913.GA7093@Magus.localnet> <87k24d4grj.fsf@colimite.fr> Message-ID: <877f0d3rvl.fsf@colimite.fr> Thus quoth Alexander Kjeldaas at 18:42 on Thu, Jun 15 2017: > > I guess https://github.com/adscib/monad-bayes is relevant as well. Noted, thanks a lot. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From benjamin.redelings at gmail.com Thu Jun 15 20:46:48 2017 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Thu, 15 Jun 2017 16:46:48 -0400 Subject: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy In-Reply-To: <8760fz6e9s.fsf@colimite.fr> References: <31991b9f-0389-2807-c74a-c857e3707d71@gmail.com> <8760fz6e9s.fsf@colimite.fr> Message-ID: Hi Sergiu, Thanks for your interest! On 06/13/2017 12:30 PM, Sergiu Ivanov wrote: > Probabilistic programs are written using the probability monad. >> I've implemented a Haskell interpreter in C++ that records execution >> traces of the Haskell programs. > Is your probability monad an actual monad that you implemented in a > Haskell package, or is it a consequence of the fact that you are running > Haskell-like programs in your interpreter? 1. Its an actual monad. It allows probability distributions to be "performed" by a Haskell function that serves as an interpreter. But I haven't implemented it in GHC. There are actually two interpreters, which are at the top of this file. "IOAndPass" is <<=, and "IOAnd" is <<. Please forgive the extreme hackiness :-P https://github.com/bredelings/BAli-Phy/blob/master/modules/Distributions.hs The (sample) function performs a distribution d by generating an IO action to randomly sample from the distribution. The (sample') function performs a distribution by setting up a node in a (dynamic) graphical model, which is also an IO action. 2. Actions in this monad can either * sample from a distribution. * specify that we should record samples of an expression. * alter properties of variables sampled in a given scope. * observe random outcomes. For example in the code below, I specify that we should sample a dirichlet containing n modifiable variables, but that MCMC should perform resampling of the variables at a rate of 1/sqrt(n). frequencies_model a = do { let {n_letters = alphabetSize a; letters = alphabet_letters a}; SamplingRate (1.0/sqrt(intToDouble n_letters)) $ do { pi <- dirichlet' n_letters 1.0; sequence_ $ zipWith (\p l -> Log l p) pi letters; return pi } }; So, the monad here is mainly used to tag variables sampled in a given scope. It might also be used to specify mcmc transition kernels for these variables. I'm not quite sure how to handle scopes outside monads yet, but Venture does something like that, and it doesn't use monads. 3. The above code is "mochastic" because we perform the distribution in a monadic interpreter in order to sample from it. But we could also do something non-monadic like let x=sample $ normal 0 1 y=sample $ gamma 1 1 in x*y But Haskell itself isn't a monad. For example, x and y aren't sequenced. Are there Haskell libraries to "run" Haskell programs in different interpreters? 4. The low-level C++ interpreter for haskell in bali-phy is not monadic. Its basically a C++ implementation of something like the STG machine, but modified to do incremental computation for generic Haskell. I actually used Sestoft (1997) "Deriving a Lazy Abstract Machine" instead of the STG. I guess I could have tried to do this by modifying GHCi to track execution traces. I'm not really sure if that would be be a good idea or not. Any thoughts? > More generally: how deep can the interoperability between your project > and some other Haskell code go? Hmm.. well I guess we could implement *sampling* from the above monad in GHC just by making the interpreter call unsafePerformIO when it sees a probability distribution. But implementing MCMC inference would require reimplementing incremental computation for Haskell in GHC. > These execution traces depend on some number of (random) variables, >> and when one of the variables is changed (during MCMC), the parts of >> the execution trace that depend on the changed variables are >> invalidated and recomputed. This saves work by not recomputing the >> probability of the new state from scratch. I can provide DOT graphs >> of the execution traces if anyone is interested. > That sounds really cool! > >> The problem domain I've been focusing on is evolution of DNA sequences >> on binary trees. > I'm very much interested in your project because I often look into > non-deterministic evolution of some abstract computing devices, and you > actually seem to be focusing on a similar use case. Hmm... I guess the idea is to represent a distribution on the possible execution histories of non-deterministic haskell programs. So, yeah, maybe there is some overlap. Huh... that actually might work! Do you handle non-determinism probabilistically? Do you want to condition on observations, or just run the abstract machine many times and record the distribution of what happens? -BenRI From ok at cs.otago.ac.nz Thu Jun 15 23:31:32 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 16 Jun 2017 11:31:32 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> Message-ID: <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> There is another elementary alternative. If you need to treat C and D the same in just one place, you don't really have a problem. If you need to treat them the same in several places, do this: data T a b c = A a | B b | C c | D c -- existing type data Which a b c = A' a | B' b | CD Bool c which :: T a b c -> Which a b c which (A a) = A' a which (B b) = B' b which (C c) = CD False c which (D c) = CD True c then case which $ x of A' a -> B' b -> CD _ c -> ... If you want to merge the C and D cases often, I like this approach, otherwise the C c -> f c D c -> f c where f c = ... approach is better. From aquagnu at gmail.com Fri Jun 16 05:27:09 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 16 Jun 2017 08:27:09 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> Message-ID: <20170616082709.74ce9ad7@Pavel> Exactly! "C c | D d" looks super! > > Hello, Li-yao! I mean this: https://wiki.haskell.org/MultiCase > > > >> Hi Paul, > >> > >> This looks like the or-patterns proposal: > >> > >> https://github.com/ghc-proposals/ghc-proposals/pull/43 > >> > >> > > You can see on github that it's just "dormant". But the examples in > this thread made me have an interesting, even more general idea: we > have functions on term-level and type-level – why not on > pattern-level? > > Here's a very rough draft of what I imagine: > > {-# LANGUAGE PatternFamilies, PatternKinds #-} > > > data Dt a = A a | B a | C a | D a deriving ( Show ) > > pattern (∥) ∷ (Pattern a → T) → (Pattern a → T) → (T → U) → > (a → U) pattern (a ∥ _) f = f a > pattern (_ ∥ b) f = f b > > infixl 2 pattern ∥ > > foo ∷ (Show a) ⇒ Dt a → String > foo (A a) = … > foo (B b) = … > foo (C c ∥ D d) = … > > > No, I don't think that's worth drawing up a proposal yet. I just want > to document the idea. Maybe it can inspire someone who's building > their own language or something. > > > Cheers, > MarLinn > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From aquagnu at gmail.com Fri Jun 16 05:43:46 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 16 Jun 2017 08:43:46 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> Message-ID: <20170616084346.5ac51d90@Pavel> Hello, Richard. As a result I did with "...where f c = ..." :) A way with "which" is interesting but duplicates unique constructors (A -> A', B -> B'). Interesting, is F# can solve this problem with active pattern? Pattern matching in Haskell does not seem enought flexible, for example, if I have `data D = D a b c d`, how can I match it without placeholders for `D` args? Something like `D...`? I need to write `D _ _ _ _` if I want to match without to bind args, right? I want to say, that may be (I'm not sure, I'm newbie in Haskell) active patterns can solve this and many other problems, may be active-pattern + reflection. For last example, I create pattern `IsD` in place where `D` is defined and use it - to be more independent on D args (D can be record and I can use getters/lens only to access its args, so I need a way to be similar independent from its args in pattern-matching too). But again, I'm not sure about right approaches - I'm newbie yet. === Best regards, Paul > There is another elementary alternative. If you need to treat C and > D the same in just one place, you don't really have a problem. If > you need to treat them the same in several places, do this: > > data T a b c = A a | B b | C c | D c -- existing type > > data Which a b c = A' a | B' b | CD Bool c > > which :: T a b c -> Which a b c > which (A a) = A' a > which (B b) = B' b > which (C c) = CD False c > which (D c) = CD True c > > then > case which $ x of > A' a -> > B' b -> > CD _ c -> ... > > If you want to merge the C and D cases often, I like this approach, > otherwise the > C c -> f c > D c -> f c > where f c = ... > approach is better. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 clintonmead at gmail.com Fri Jun 16 05:55:04 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Fri, 16 Jun 2017 15:55:04 +1000 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170616084346.5ac51d90@Pavel> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: You can record match like so "x at D{}" but then you'll need someway to access the contents of "x" (if you're interested in the contents, that is). On Fri, Jun 16, 2017 at 3:43 PM, Baa wrote: > Hello, Richard. > > As a result I did with "...where f c = ..." :) A way with "which" is > interesting but duplicates unique constructors (A -> A', B -> B'). > > Interesting, is F# can solve this problem with active pattern? > > Pattern matching in Haskell does not seem enought flexible, for > example, if I have `data D = D a b c d`, how can I match it without > placeholders for `D` args? Something like `D...`? I need to write > `D _ _ _ _` if I want to match without to bind args, right? > > I want to say, that may be (I'm not sure, I'm newbie in Haskell) active > patterns can solve this and many other problems, may be active-pattern > + reflection. For last example, I create pattern `IsD` in place where > `D` is defined and use it - to be more independent on D args (D can be > record and I can use getters/lens only to access its args, so I need a > way to be similar independent from its args in pattern-matching too). > > But again, I'm not sure about right approaches - I'm newbie yet. > > > === > Best regards, Paul > > > There is another elementary alternative. If you need to treat C and > > D the same in just one place, you don't really have a problem. If > > you need to treat them the same in several places, do this: > > > > data T a b c = A a | B b | C c | D c -- existing type > > > > data Which a b c = A' a | B' b | CD Bool c > > > > which :: T a b c -> Which a b c > > which (A a) = A' a > > which (B b) = B' b > > which (C c) = CD False c > > which (D c) = CD True c > > > > then > > case which $ x of > > A' a -> > > B' b -> > > CD _ c -> ... > > > > If you want to merge the C and D cases often, I like this approach, > > otherwise the > > C c -> f c > > D c -> f c > > where f c = ... > > approach is better. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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 konn.jinro at gmail.com Fri Jun 16 07:33:06 2017 From: konn.jinro at gmail.com (Hiromi ISHII) Date: Fri, 16 Jun 2017 16:33:06 +0900 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: <7CC6FCCF-4713-405C-ADA3-C060EF959E12@gmail.com> Hi cafe, Here's another solution using lens (and prisms): ``` {-# LANGUAGE PatternSynonyms, RankNTypes, TemplateHaskell, ViewPatterns #-} module Main where import Control.Lens data F = C Int | D Int | E String Int | F Int | G String deriving (Read, Show, Eq, Ord) makePrisms ''F match = flip (^?) main :: IO () main = case C 2 of (match (_C <|?> _D <|?> _E._2 <|?> _F) -> Just i) -> print i G s -> putStrLn s infixl 8 <|?> (<|?>) :: (Conjoined p, Applicative f) => Traversing p f s t a b -> Over p f s t a b -> Over p f s t a b (<|?>) = failing ``` > 2017/06/16 14:55、Clinton Mead のメール: > > You can record match like so "x at D{}" but then you'll need someway to access the contents of "x" (if you're interested in the contents, that is). > > On Fri, Jun 16, 2017 at 3:43 PM, Baa wrote: > Hello, Richard. > > As a result I did with "...where f c = ..." :) A way with "which" is > interesting but duplicates unique constructors (A -> A', B -> B'). > > Interesting, is F# can solve this problem with active pattern? > > Pattern matching in Haskell does not seem enought flexible, for > example, if I have `data D = D a b c d`, how can I match it without > placeholders for `D` args? Something like `D...`? I need to write > `D _ _ _ _` if I want to match without to bind args, right? > > I want to say, that may be (I'm not sure, I'm newbie in Haskell) active > patterns can solve this and many other problems, may be active-pattern > + reflection. For last example, I create pattern `IsD` in place where > `D` is defined and use it - to be more independent on D args (D can be > record and I can use getters/lens only to access its args, so I need a > way to be similar independent from its args in pattern-matching too). > > But again, I'm not sure about right approaches - I'm newbie yet. > > > === > Best regards, Paul > > > There is another elementary alternative. If you need to treat C and > > D the same in just one place, you don't really have a problem. If > > you need to treat them the same in several places, do this: > > > > data T a b c = A a | B b | C c | D c -- existing type > > > > data Which a b c = A' a | B' b | CD Bool c > > > > which :: T a b c -> Which a b c > > which (A a) = A' a > > which (B b) = B' b > > which (C c) = CD False c > > which (D c) = CD True c > > > > then > > case which $ x of > > A' a -> > > B' b -> > > CD _ c -> ... > > > > If you want to merge the C and D cases often, I like this approach, > > otherwise the > > C c -> f c > > D c -> f c > > where f c = ... > > approach is better. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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. ----- 石井 大海 --------------------------- konn.jinro at gmail.com 筑波大学数理物質科学研究科 数学専攻 博士後期課程二年 ---------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From ok at cs.otago.ac.nz Fri Jun 16 06:21:41 2017 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Fri, 16 Jun 2017 18:21:41 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170616084346.5ac51d90@Pavel> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: > Hello, Richard. > > As a result I did with "...where f c = ..." :) A way with "which" is > interesting but duplicates unique constructors (A -> A', B -> B'). Yes, but if you *often* want to group constructors together, it's still a good idea. The alternative, which has already been suggested, is to group them together in the original type, but you might want to classify the alternatives in more than one way. > > Interesting, is F# can solve this problem with active pattern? Probably. See https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/active-patterns for details of active patterns in F#. The syntax is seriously twisted. You *can* associate data with the partitions, but it's really not obvious. If you want to classify something more than 7 ways F# is unhelpful. F# active patterns are not entirely unlike view patterns https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns only stranger. > > Pattern matching in Haskell does not seem enought flexible, for > example, if I have `data D = D a b c d`, how can I match it without > placeholders for `D` args? Something like `D...`? I need to write > `D _ _ _ _` if I want to match without to bind args, right? Yes, but (a) in all seriousness, that's not much of a problem, surely and (b) there is an alternative. If you write instead data D a b c d = D { f1 :: a, f2 :: b, f3 :: c, f4 :: d } then you can abbreviate patterns like this: f (D{}) = () g (D{f1 = x}) = x If you have enough fields for counting the placeholders to be a problem then you have enough fields that you really *ought* to be naming them anyway. The problem with making pattern matching overly flexible is that people have to read and understand this stuff. It's a bit like regular expressions: POSIX regular expressions can be implemented to take linear time (by simulating an NDFA), but they are a bit limited, whereas Perl regular expressions are very expressive indeed, but they can all too easily take exponential time, and it isn't easy for John and Jane Doe programmers to tell when that is going to happen. Generally speaking, before proposing language changes, it's always a good idea to see if you can solve your problem by factoring out common stuff into a new function (or type, or typeclass) first. From allbery.b at gmail.com Fri Jun 16 09:50:48 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 16 Jun 2017 05:50:48 -0400 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: On Fri, Jun 16, 2017 at 2:21 AM, wrote: > If you write instead > > data D a b c d = D { f1 :: a, f2 :: b, f3 :: c, f4 :: d } > > then you can abbreviate patterns like this: > > f (D{}) = () > As a special case, you can use the no-fields record pattern Cons {} with *any* constructor, regardless of whether it was defined with record syntax or whether it has parameters. -- 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 aquagnu at gmail.com Fri Jun 16 09:58:06 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 16 Jun 2017 12:58:06 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: <20170616125806.6a60228d@Pavel> > On Fri, Jun 16, 2017 at 2:21 AM, wrote: > > > If you write instead > > > > data D a b c d = D { f1 :: a, f2 :: b, f3 :: c, f4 :: d } > > > > then you can abbreviate patterns like this: > > > > f (D{}) = () > > > > As a special case, you can use the no-fields record pattern Cons {} > with *any* constructor, regardless of whether it was defined with > record syntax or whether it has parameters. > Aha, I checked it, good. From aquagnu at gmail.com Fri Jun 16 10:12:32 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 16 Jun 2017 13:12:32 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> Message-ID: <20170616131232.2e2b2c7a@Pavel> > > Interesting, is F# can solve this problem with active pattern? > > Probably. See > https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/active-patterns > for details of active patterns in F#. > The syntax is seriously twisted. You *can* associate > data with the partitions, but it's really not obvious. > If you want to classify something more than 7 ways F# is unhelpful. > F# active patterns are not entirely unlike view patterns > https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns > only stranger. view patterns are "active" too, sure while they are callable :) Unfortunately I am not so familiar with both to compare them in detail. Are they equal in capacity/in general or only partially? I mean, can Haskell view patterns cover all possibilities of Active Patterns of F#? > > > > Pattern matching in Haskell does not seem enought flexible, for > > example, if I have `data D = D a b c d`, how can I match it without > > placeholders for `D` args? Something like `D...`? I need to write > > `D _ _ _ _` if I want to match without to bind args, right? > > Yes, but (a) in all seriousness, that's not much of a problem, > surely and (b) there is an alternative. If you write instead > > data D a b c d = D { f1 :: a, f2 :: b, f3 :: c, f4 :: d } > > then you can abbreviate patterns like this: > > f (D{}) = () > > g (D{f1 = x}) = x > > If you have enough fields for counting the placeholders to be a > problem then you have enough fields that you really *ought* to be > naming them anyway. That it is, good! Thanks for this hint! > The problem with making pattern matching overly flexible is that > people have to read and understand this stuff. It's a bit like > regular expressions: POSIX regular expressions can be implemented > to take linear time (by simulating an NDFA), but they are a bit > limited, whereas Perl regular expressions are very expressive > indeed, but they can all too easily take exponential time, and it > isn't easy for John and Jane Doe programmers to tell when that is > going to happen. Sure, true. > Generally speaking, before proposing language changes, it's > always a good idea to see if you can solve your problem by > factoring out common stuff into a new function (or type, or > typeclass) first. > Sure, but there is another point of view here. Alternative is to have flexible but elegant syntax embedded in language, instead of many-many extensions for any possibility - they "fragment" language. But of course this is controversial and ambiguous :-) === Best regards, Paul From allbery.b at gmail.com Fri Jun 16 10:15:43 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 16 Jun 2017 06:15:43 -0400 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170616131232.2e2b2c7a@Pavel> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: On Fri, Jun 16, 2017 at 6:12 AM, Baa wrote: > > Sure, but there is another point of view here. Alternative is to have > flexible but elegant syntax embedded in language, instead of many-many > extensions for any possibility - they "fragment" language. But of course > this is controversial and ambiguous :-) The active patterns of F# that you mentioned can be seen as a counterargument :) -- 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 ivanperezdominguez at gmail.com Fri Jun 16 12:33:05 2017 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 16 Jun 2017 14:33:05 +0200 Subject: [Haskell-cafe] [Announcement] Haskell game for iOS In-Reply-To: <20170613184709.3fbca72a@Pavel> References: <20170613184709.3fbca72a@Pavel> Message-ID: Hi (I responded to Paul/Baa separately, but maybe this will be of interest to others?) Time: We started this game at the end of 2014, beta tested on Google Play in January 2015, and launched for Android in February 2015. Since then we debugged, rewrote the game's engine completely, and launched for iOS. Both in time and in number of commits, for this particular game, the effort we put after the launch far exceeds the time we put before. The Android ecosystem is quite heterogeneous, and we saw the game crash only in very specific models but not others. This usually had to do with either the RTS or threads. (I wrote this game in other languages before 2014: Java, Scala, frege. But integration was not good enough, compilation was not good enough, and they could only target JVM.) Nevertheless, while it may seem like a simple game, we were among the first to attempt any of this for real. Even more time went into prior games that we threw out, and in making the tools work. We invested so much time in developing tools, libraries and examples to make Haskell game/apps for mobile easy to produce! This is not apparent in the game. Actually, someone wrote last year asking if we'd closed down (ouch!). Writing this and other Haskell games and apps let us understand strengths/weaknesses of Haskell and FRP. That's been also the focus of my PhD [1]. We can't tell people that Haskell "can" be used for real games or apps, give them some tools, and walk away. Many paper examples break under real conditions. When we write games, we also "put the money where our mouths are". Even if this game is not successful in the end, it's given us a lot of experience. We have other, more complex games in the store (one being beta-tested, another is still in development). We are also writing apps. And introducing testing facilities. I hope the effort pays off. I'm really happy with the current state of things: new apps can be created superquickly, and from my machine (I have everything cached) they take less than 1 minute to recompile and upload to the store. It's is a one-liner :) We are creating playable demos and apps in hours/days. And these do not only work on iOS/Android, but also on desktop and web. I've personally been looking for people and companies interested in doing this together. FP and non-FP. Not (just) customers, but also long-term partners that believe in this. And I've been looking for people to work on maintaining the Android/iOS backends, which is super-hard. I know others have too, and I'm hoping we can coordinate on this. Size: Currently, about 20-30MB per architecture. All the best Ivan [1] http://www.cs.nott.ac.uk/~psxip1/ On 13 June 2017 at 17:47, Baa wrote: > Hello, Ivan. Would you like to describe: how big is your game in > Megabytes without any compression (interesting is binaries, not > sprites, media, etc assets)? And how many time/human resources did you > spent to release it? > > --- > Best regards, Paul > > > > Dear all > > > > (I hope this is not seen as spam. My sincere apologies if you see it > > as such.) > > > > This is just to let you know that we have released a Haskell game for > > iOS on the App Store. > > > > https://itunes.apple.com/us/app/magic-cookies/id1244709871 > > > > There is also an Android version [1]. It's the same Haskell code with > > just a few minor adaptations [2] (the iOS version is actually > > simpler). Issues with either version can be reported online [3]. > > > > I hope this is seen as yet another step reached by Haskell. This game > > is written in the FRP variant Yampa, and uses SDL2 for graphics. > > While the game is not open source, we've had to extend existing > > Haskell libraries and tools to make this possible. These changes will > > now be sent as pull requests to the corresponding projects. > > > > We have also developed in-house tooling to make the development, > > compilation and deployment process for mobile platforms smooth [4]. > > Recompiling and deploying a new version online is now automatic and > > takes less than 1 minute. These tools also run directly on Travis and > > publish new versions of our games directly to stores. We have already > > started distributing our toolchain to private users, and our plan is > > to release immediately. > > > > We'd like to thank all the users who tried the game before the > > release, many during Zurihac last weekend. Also, many thanks to the > > people who worked on GHC and the ARM backends over the years, and to > > all those who work daily to make Haskell better. We really mean that. > > > > Once again, I hope this is not seen as spam, but as something worth > > celebrating. > > > > And, also, that you enjoy playing. > > > > Best wishes > > > > Ivan > > > > -- Keera Studios > > > > [1] > > https://play.google.com/store/apps/details?id=uk.co.keera.ga > mes.magiccookies > > > > [2] > > https://www.facebook.com/keerastudios/photos/a.3013262232162 > 44.89053.300854939930039/1701909406491245/?type=3 > > > > [3] https://github.com/keera-studios/magic-cookies > > > > [4] http://keera.co.uk/blog/2017/06/01/haskell-android-ios/ > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 dennis.raddle at gmail.com Fri Jun 16 20:45:22 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 16 Jun 2017 13:45:22 -0700 Subject: [Haskell-cafe] exceptions, errors, random Message-ID: I am wondering what exception/error and random classes I should use for my application. The application will be doing Monte Carlo backtracking search. I want it to be multithreaded and run on all four cores on my MacBook. I need detailed error messages in order to investigate errors. So I will throw errors or exceptions, then catch them in lower functions and annotate them with the parameters or computations within the lower function, then re-throw until finally the exception pops into the terminal. Because it's multi-threaded, at least some parts will needs to be in IO. Also, because it's a Monte Carlo algorithm it will need to make pseudorandom choices. Perhaps I should put everything in the IO monad? This will give me access to threads and the standard generator seed. But how about throwing, catching/rethrowing exceptions in IO? I have done this in pure code before: not sure if it's better to do it that way, in which case I could put some kind of state monad to hold the random seed together with an error monad and IO at the core of the monad stack. Any advice welcome. D -------------- next part -------------- An HTML attachment was scrubbed... URL: From sivanov at colimite.fr Sat Jun 17 18:05:22 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Sat, 17 Jun 2017 20:05:22 +0200 Subject: [Haskell-cafe] Announce: Probablistic programming in Haskell with bali-phy In-Reply-To: References: <31991b9f-0389-2807-c74a-c857e3707d71@gmail.com> <8760fz6e9s.fsf@colimite.fr> Message-ID: <87inju32xp.fsf@colimite.fr> Hi Benjamin, Thus quoth Benjamin Redelings at 20:46 on Thu, Jun 15 2017: > On 06/13/2017 12:30 PM, Sergiu Ivanov wrote: >> >> Probabilistic programs are written using the probability monad. >>> I've implemented a Haskell interpreter in C++ that records execution >>> traces of the Haskell programs. >> Is your probability monad an actual monad that you implemented in a >> Haskell package, or is it a consequence of the fact that you are running >> Haskell-like programs in your interpreter? > > 1. Its an actual monad. It allows probability distributions to be > "performed" by a Haskell function that serves as an interpreter. But I > haven't implemented it in GHC. There are actually two interpreters, > which are at the top of this file. "IOAndPass" is <<=, and "IOAnd" is > <<. Please forgive the extreme hackiness :-P > https://github.com/bredelings/BAli-Phy/blob/master/modules/Distributions.hs OK, I see. (I suppose you meant to say that IOAndPass is =<<). > The (sample) function performs a distribution d by generating an IO > action to randomly sample from the distribution. The (sample') function > performs a distribution by setting up a node in a (dynamic) graphical > model, which is also an IO action. OK, so the difference is in the presence or absence of the graphical representation of the model your are working with? > 2. Actions in this monad can either > * sample from a distribution. > * specify that we should record samples of an expression. Do you mean something like x <- doSomething `fmap` someDistribution where x <- someDistribution would sample someDistribution? > * alter properties of variables sampled in a given scope. Oh, so you have a kind of state baked into your monad as well? > For example in the code below, I specify that we should sample a > dirichlet containing n modifiable variables, but that MCMC should > perform resampling of the variables at a rate of 1/sqrt(n). [...] OK, I see, thanks for the example! What do you mean by "modifiable variables"? Are those just random variables? > So, the monad here is mainly used to tag variables sampled in a given > scope. It might also be used to specify mcmc transition kernels for > these variables. OK. > I'm not quite sure how to handle scopes outside monads yet, but Venture > does something like that, and it doesn't use monads. Not sure what you mean by "handle scopes outside monads". Some kind of scopes are handled without monads in a lot of programming languages/frameworks :-) > 3. The above code is "mochastic" because we perform the distribution in > a monadic interpreter in order to sample from it. But we could also do > something non-monadic like > > let x=sample $ normal 0 1 > y=sample $ gamma 1 1 > in x*y Yeah, sure, because every monad is a functor. > But Haskell itself isn't a monad. For example, x and y aren't > sequenced. Not sure what you mean here again. Something can be a monad or not a monad depending on how you look at it. If you see Haskell code as a sequence of strings fed into the compiler, it's quite monadic to my taste. You probably mean something else. > Are there Haskell libraries to "run" Haskell programs in different > interpreters? There is a number of different Haskell implementations [0] as well as haskell-src-exts [1] which is a parser of Haskell implemented as a Haskell library. But you probably mean something else by "different interpreters". > 4. The low-level C++ interpreter for haskell in bali-phy is not > monadic. Its basically a C++ implementation of something like the STG > machine, but modified to do incremental computation for generic > Haskell. I actually used Sestoft (1997) "Deriving a Lazy Abstract > Machine" instead of the STG. I guess I could have tried to do this by > modifying GHCi to track execution traces. I'm not really sure if that > would be be a good idea or not. Any thoughts? My question here would be: why do you chose to write a Haskell interpreter (or modifying an existing one) instead of writing everything in Haskell? (I believe that's also the question Olaf asked.) (I don't really have any ideas on what would be a good way of implementing a Haskell interpreter.) >> More generally: how deep can the interoperability between your project >> and some other Haskell code go? > Hmm.. well I guess we could implement *sampling* from the above monad in > GHC just by making the interpreter call unsafePerformIO when it sees a > probability distribution. But implementing MCMC inference would require > reimplementing incremental computation for Haskell in GHC. OK, so sampling can be natively implemented in Haskell. What do you mean by "incremental computation"? >>> The problem domain I've been focusing on is evolution of DNA sequences >>> on binary trees. >> I'm very much interested in your project because I often look into >> non-deterministic evolution of some abstract computing devices, and you >> actually seem to be focusing on a similar use case. > Hmm... I guess the idea is to represent a distribution on the possible > execution histories of non-deterministic haskell programs. So, yeah, > maybe there is some overlap. Yes, that's what I kind of had in my brain. > Huh... that actually might work! Do you handle non-determinism > probabilistically? Do you want to condition on observations, or just > run the abstract machine many times and record the distribution of what > happens? When I did similar things for my research, I just explored all the non-deterministic branches of execution for a couple of steps. I used a clot of Perl code which could filter out some branches. I haven't considered using a probabilistic approach, but it may actually be quite interesting, I'll give it a think, thank you :-) -- Sergiu [0] https://wiki.haskell.org/Implementations [1] http://hackage.haskell.org/package/haskell-src-exts -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ok at cs.otago.ac.nz Sun Jun 18 06:17:20 2017 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Sun, 18 Jun 2017 18:17:20 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170616131232.2e2b2c7a@Pavel> References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: "Baa" wrote: > view patterns are "active" too, sure while they are callable :) > Unfortunately I am not so familiar with both to compare them in detail. > Are they equal in capacity/in general or only partially? I mean, can > Haskell view patterns cover all possibilities of Active Patterns of F#? I'm not sure. The idea of something like views has been around for a while. For all I know, F# might have got there first. There were quite a few proposals before all the warts got frozen off and we were blessed with the present deceptively simple scheme. I have a bit of trouble trying to make sense of some of Microsoft's F# documentation, though. Let's compare them! Do you use an ordinary function definition or some weird syntax? Haskell: you use an ordinary function that can be used like an ordinary function AND can be used in (view -> pattern) form F# : weird syntax, not usable as an ordinary function. Is the classification result an ordinary data type that can be used by multiple views, or does each user-defined classifier have to have a different result type? Haskell: it's an ordinary type. F# : if I've understood correctly, no, each active pattern defines its own union type (with parts of the definition scattered). Is it obvious to a human reader when we're doing a plain old "what constructor is this" match and when something fancy is happening? Haskell: yes, with pretty minimal overhead. F# : no, by design. Can the two approaches do the same things? Based on my present wholly inadequate understanding of F# active patterns, Haskell view patterns can do everything they do, but not the other way around. But I must stress that I regard my understanding of F# active patterns as inadequate. Let's take the ABCD example. data ABCD a b c = A a | B b | C c | D c data ABC a b c = A' A | B' b | C c Bool abc :: ABCD a b c -> ABC a b c abc (A a) = A' a abc (B b) = B' b abc (C c) = C' c False abc (D c) = C' c True f (abc -> A' a) = ... f (abc -> B' b) = ... f (abc -> C' c _) = ... This will be compiled as if it read f x = case abc x of {A' a -> ... ; B' b -> ... ; C' c _ -> ...} You define an ordinary type, you define an ordinary function, and you call that ordinary function inside patterns. type abcd<'a,'b,'c> = A of 'a | B of 'b | C of 'c | D of 'c;; let (|A1|B1|C1|) x = match x with | A a -> A1(a) | B b -> B1(b) | C c -> C1(c,false) | D c -> C1(c,true);; let f x = match x with | A1 a -> 1 | B1 b -> 2 | C1 (c,_) -> 3;; This F# code has been tested in fsi 4.1. You define an anonymous ADT with the constructors on one side of the = and their arguments on the other, you define an anonymous function, which is basically the same as the view function, and you call the anonymous function inside pattern matching. >> Generally speaking, before proposing language changes, it's >> always a good idea to see if you can solve your problem by >> factoring out common stuff into a new function (or type, or >> typeclass) first. >> > > Sure, but there is another point of view here. Alternative is to have > flexible but elegant syntax embedded in language, instead of many-many > extensions for any possibility - they "fragment" language. But of course > this is controversial and ambiguous :-) I agree 100%. That's why I prefer Haskell to F#. View patterns are indeed flexible but elegant. However, in this particular example, they are not actually needed. SML/NJ has also extended the syntax of patterns to allow ``or-patterns.'' The basic syntax is: (apat1 | ... | apatn) where the apati are atomic patterns. The other restriction is that the variables bound in each apati must be the same, and have the same type. The MLton compiler also (optionally) supports this. There has been a certain amount of pressure in the Erlang community to add a similar feature to Erlang. In fact, respected Erlang people have claimed to see a lot of repeated cases that OR patterns would avoid. Sometimes pain is Nature's way of telling you you're doing it wrong. If you find two cases in a data type being handled the same way in one place, is this a rare thing, or are they handled very similarly in many places? If so, why are they TWO cases instead of one with a subcase? There's a big problem with F# active patterns, which is shared by view patterns to a lesser degree. That is that a call to an active or view pattern may do arbitrary amounts of work, whereas (after forcing such evaluation as may be needed) ordinary pattern matching does an amount of work proportional to the size of the pattern. In Haskell, view pattern match syntax at least warns you that you *might* have a problem. What evil lurks in the heart of OR-patterns? Let Pi be the pattern (i,_) | (_,i) f P1 ... Pn (0,0) = True f _ ... _ _ = False g = f (1,1) (2,2) ... (n,n) (1,1) What stops this taking time exponential in n to decide which clause to use? And you certainly don't want the compiler to process this by expanding the alternatives out. (So far it has taken 3 minutes on a fast machine to not finish compiling these 3 lines of code... I fear the worst.) I have reluctantly come to the conclusion that OR-patterns fill a much-needed gap. From ok at cs.otago.ac.nz Sun Jun 18 06:42:26 2017 From: ok at cs.otago.ac.nz (ok at cs.otago.ac.nz) Date: Sun, 18 Jun 2017 18:42:26 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: <0b6e6aee43b9790bae0ec9a22b3d9810.squirrel@chasm.otago.ac.nz> > What evil lurks in the heart of OR-patterns? > > Let Pi be the pattern (i,_) | (_,i) In SML, fun f P1 ... Pn (0,0) = true | f _ ... _ _ = false fun g () = f (1,1) (2,2) ... (n,n) (1,1) > (So far it has taken 3 minutes on a fast machine to not > finish compiling these 3 lines of code... I fear the worst.) I killed it after 24 minutes on a 3.2 GHz machine. In Haskell, ok n (x,y) = x == n || y == n f (ok 1 -> True) ... (ok n -> True) (0,0) = true f _ _ _ = false g () = f (1,1) (2,2) ... (n,n) (1,1) compiled and ran in a flash. (Yes, I know that the Haskell version is "committed choice" and the SML/NJ version is "backtracking search", but that's the point: the *syntax* of OR-patterns may be simple but sorting out the *semantics* is not.) From monkleyon at gmail.com Sun Jun 18 13:32:44 2017 From: monkleyon at gmail.com (MarLinn) Date: Sun, 18 Jun 2017 15:32:44 +0200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: <3939f6d3-36f6-e3b3-fb56-55b2d6f32161@gmail.com> > Sometimes pain is Nature's way of telling you you're doing it wrong. > This. This not only goes for or-patterns, but also for the pain that leads you to use View Patterns. They are an interesting concept, and the indirection makes it more "fun" to think about. We like flexing our minds that little bit sometimes. But they are also easily abused to hide shortcomings of the underlying model instead of fixing them. And in the real world, that's often what they end up being used for. Almost all code I have seen that actually used View Patterns got more readable by refactoring. Don't get me wrong: I'm not saying they should never be used. But I've fallen into the trap of overusing this pattern myself, and almost always I regretted it and/or refactored. Of all the code I've seen there has maybe been a handful of instances where View Patterns actually contributed in a positive way. Call me a hypocrite after I brought up the ridiculous concept of "pattern-level functions" earlier in this thread, but that's the difference between theory and practice I suppose. Cheers, MarLinn From carette at mcmaster.ca Sun Jun 18 13:57:19 2017 From: carette at mcmaster.ca (Jacques Carette) Date: Sun, 18 Jun 2017 09:57:19 -0400 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: References: <20170615112913.GA7093@Magus.localnet> <87k24d4grj.fsf@colimite.fr> Message-ID: While we're mentioning Haskell-embedded languages for probabilistic programming, there is yet another, Hakaru. github: https://github.com/hakaru-dev/hakaru docs: https://hakaru-dev.github.io/ hackage: https://hackage.haskell.org/package/hakaru-0.4.0 It can be used either embedded or via an external syntax. It can act as a sampler, but also do code generation (to Haskell, to C, more coming), simplification (via Maple if it is installed) and disintegration (aka conditioning). It uses quite a number of advanced Haskell features (though works in 7.8 onwards) to insure safety of the embedded language. See https://hackage.haskell.org/package/hakaru-0.4.0/docs/Language-Hakaru-Syntax-ABT.html if you are curious about that. Jacques From sivanov at colimite.fr Sun Jun 18 17:59:38 2017 From: sivanov at colimite.fr (Sergiu Ivanov) Date: Sun, 18 Jun 2017 19:59:38 +0200 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: References: <20170615112913.GA7093@Magus.localnet> <87k24d4grj.fsf@colimite.fr> Message-ID: <87h8zd2n3p.fsf@colimite.fr> Hello Jacques, Thus quoth Jacques Carette at 13:57 on Sun, Jun 18 2017: > > While we're mentioning Haskell-embedded languages for probabilistic > programming, there is yet another, Hakaru. > > github: https://github.com/hakaru-dev/hakaru > docs: https://hakaru-dev.github.io/ > hackage: https://hackage.haskell.org/package/hakaru-0.4.0 Thanks for the reference! To my inexperienced eye, this offers somewhat similar functionality to Benjamin's library (the original poster). > It can be used either embedded or via an external syntax. It can act as > a sampler, but also do code generation (to Haskell, to C, more coming), > simplification (via Maple if it is installed) and disintegration (aka > conditioning). Sounds pretty impressive, I'll keep the reference in mind. -- Sergiu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ok at cs.otago.ac.nz Sun Jun 18 22:52:50 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Mon, 19 Jun 2017 10:52:50 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: > On 16/06/2017, at 10:15 PM, Brandon Allbery wrote: > > On Fri, Jun 16, 2017 at 6:12 AM, Baa wrote: > Sure, but there is another point of view here. Alternative is to have > flexible but elegant syntax embedded in language, instead of many-many > extensions for any possibility - they "fragment" language. But of course > this is controversial and ambiguous :-) > > The active patterns of F# that you mentioned can be seen as a counterargument There's an interesting irony here. I'm reading the paper "Extensible Pattern Matching via a Lightweight Language Extension" by Syme, Neverov, and Margetson. The authors propose active patterns as a way of allowing functional code to work with objects using pattern matching. The irony is that doing this clearly violates the Object-Oriented Programming principle "Tell, Don't Ask". That is, according to the OOP gurus, if you have some sort of if or case that classifies an object in some way, you are doing it wrong. That variant- dependent behaviour belongs in the object. I'm agnostic about most OO dogma, so don't take this as my claim. From aquagnu at gmail.com Mon Jun 19 07:44:11 2017 From: aquagnu at gmail.com (Baa) Date: Mon, 19 Jun 2017 10:44:11 +0300 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: References: <20170615171121.556106b0@Pavel> <7a4b4b95-737d-816b-532e-db3b0132c38c@gmail.com> <20170615175435.0b03f462@Pavel> <50f9889d-a8fb-a26a-070c-c2b396be48a2@gmail.com> <9B613941-A514-454F-ACF0-67E0BB99A6AC@cs.otago.ac.nz> <20170616084346.5ac51d90@Pavel> <20170616131232.2e2b2c7a@Pavel> Message-ID: <20170619104411.0018dd6a@Pavel> > Let's take the ABCD example. > data ABCD a b c = A a | B b | C c | D c > data ABC a b c = A' A | B' b | C c Bool You mean data ABC a b c = A' a | B' b | C' c Bool It is very pleasant when a person has such a wide horizon: you compared F#, SML, Erlang and Haskell, IMHO modern FP developer should have basic knowledge about these languages/cultures and to know about their trends/current researches. Example with SML 'OR'-pattern, am I right that this terrible compile time is due search on all permutations of patterns (func arguments)? But what is not obvious to me is what is compiler try to match: P1 P2 ... Pn (0,0) => True _ _ ... _ _ => False (1,1) (2,2) ... (n,n) (1,1) => False is not enought to do depth-first search and to go from P1 to last (0,0)? Or is it try to find all matches, not only one, first successful? May be I miss what is 'Pn', how it's defined. Your example with the introduction of a 'ABC' has good understandable semantic, if they can be united, there is a reason to combine them in new type, semantically it makes sense. And view pattern in your example "unwraps" underlying datatype value to be matched and bound. Good explanation, thanks for it! And from SML example I can understand that obvious solution to the forehead of "OR"-pattern matching can be problematic in practice... === Thanks again, best regards, Paul From oleg at okmij.org Mon Jun 19 09:28:32 2017 From: oleg at okmij.org (Oleg) Date: Mon, 19 Jun 2017 18:28:32 +0900 Subject: [Haskell-cafe] MultiCase alternative Message-ID: <20170619092832.GA2776@Magus.localnet> Richard A. O'Keefe wrote: > Let Pi be the pattern (i,_) | (_,i) > In SML, > fun f P1 ... Pn (0,0) = true > | f _ ... _ _ = false > > fun g () = f (1,1) (2,2) ... (n,n) (1,1) > > (So far it has taken 3 minutes on a fast machine to not > > finish compiling these 3 lines of code... I fear the worst.) I can't speak for SML, but I was curious to try your example in OCaml, which also supports OR patterns. Here is how it looks in OCaml: let f = function ((1,_)|(_,1)), ((2,_)|(_,2)), ((3,_)|(_,3)), ((4,_)|(_,4)), ((5,_)|(_,5)), ((6,_)|(_,6)), ((7,_)|(_,7)), ((8,_)|(_,8)), (0,0) -> true | _ -> false ;; let g () = f ((1,1),(2,2),(3,3),(4,4),(5,5),(6,6),(7,7),(8,8),(1,1)) ;; let _ = g ();; It compiled instantly. I was curious what it is compiled to. Enclosed in the result, in an intermediate language called Lambda (before optimizations). It seems the size of the code is linear in n. Not too bad. BTW, match/1207 is the identifier called match with the timestamp 1207. The timestamps tell distinct identifiers with the same given name apart. Also, 1a means true and 0a means false (and also unit and the empty list). >From personal experience, OR patterns are quite handy when handing an AST where many of the alternatives are to be handled the same. That said, supporting OR patterns in MetaOCaml was responsible for some of the most complex code there. ocamlc -c -dlambda p.ml (setglobal P! (let (f/1199 = (function param/1206 (let (match/1207 =a (field 0 param/1206)) (catch (catch (if (!= (field 0 match/1207) 1) (if (!= (field 1 match/1207) 1) (exit 1) (exit 2)) (exit 2)) with (2) (let (match/1227 =a (field 1 param/1206)) (catch (if (!= (field 0 match/1227) 2) (if (!= (field 1 match/1227) 2) (exit 1) (exit 4)) (exit 4)) with (4) (let (match/1245 =a (field 2 param/1206)) (catch (if (!= (field 0 match/1245) 3) (if (!= (field 1 match/1245) 3) (exit 1) (exit 6)) (exit 6)) with (6) (let (match/1261 =a (field 3 param/1206)) (catch (if (!= (field 0 match/1261) 4) (if (!= (field 1 match/1261) 4) (exit 1) (exit 8)) (exit 8)) with (8) (let (match/1275 =a (field 4 param/1206)) (catch (if (!= (field 0 match/1275) 5) (if (!= (field 1 match/1275) 5) (exit 1) (exit 10)) (exit 10)) with (10) (let (match/1287 =a (field 5 param/1206)) (catch (if (!= (field 0 match/1287) 6) (if (!= (field 1 match/1287) 6) (exit 1) (exit 12)) (exit 12)) with (12) (let (match/1297 =a (field 6 param/1206)) (catch (if (!= (field 0 match/1297) 7) (if (!= (field 1 match/1297) 7) (exit 1) (exit 14)) (exit 14)) with (14) (let (match/1305 =a (field 7 param/1206)) (catch (if (!= (field 0 match/1305) 8) (if (!= (field 1 match/1305) 8) (exit 1) (exit 16)) (exit 16)) with (16) (let (match/1311 =a (field 8 param/1206)) (if (!= (field 0 match/1311) 0) (exit 1) (if (!= (field 1 match/1311) 0) (exit 1) 1a)))))))))))))))))) with (1) 0a))) g/1201 = (function param/1205 (apply f/1199 [0: [0: 1 1] [0: 2 2] [0: 3 3] [0: 4 4] [0: 5 5] [0: 6 6] [0: 7 7] [0: 8 8] [0: 1 1]]))) (seq (apply g/1201 0a) (makeblock 0 f/1199 g/1201)))) From nakov.gl at gmail.com Mon Jun 19 14:51:03 2017 From: nakov.gl at gmail.com (Georgi Nakov) Date: Mon, 19 Jun 2017 17:51:03 +0300 Subject: [Haskell-cafe] Master programme with Haskell prospects Message-ID: Hi all, I was pondering on Master programme with "good" Haskell-related prospects upon completion (regardless whether it's in academia or industry). Currently the only options available to me are Master in Logic at University of Amsterdam and Computing Science at Utrecht. The latter has more emphasis on FP and Haskell while the former seems more concerned with the mathematical/philosophical foundations. Any thoughts or direct observations on these programmes would be greatly appreciated. Thanks. Best regards, Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Mon Jun 19 15:37:33 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Mon, 19 Jun 2017 16:37:33 +0100 Subject: [Haskell-cafe] Probabilistic programming in Haskell with bali-phy In-Reply-To: References: Message-ID: <4B680400-DA85-48FA-9502-0FCDC0AE4510@steinitz.org> > While we're mentioning Haskell-embedded languages for probabilistic > programming, there is yet another, Hakaru. > > github: https://github.com/hakaru-dev/hakaru > docs: https://hakaru-dev.github.io/ > hackage: https://hackage.haskell.org/package/hakaru-0.4.0 > > It can be used either embedded or via an external syntax. It can act as > a sampler, but also do code generation (to Haskell, to C, more coming), > simplification (via Maple if it is installed) and disintegration (aka > conditioning). > > It uses quite a number of advanced Haskell features (though works in 7.8 > onwards) to insure safety of the embedded language. See > https://hackage.haskell.org/package/hakaru-0.4.0/docs/Language-Hakaru-Syntax-ABT.html > if you are curious about that. > > Jacques There are production strength PPLs like Stan and PyMC3. They aren’t Haskell but if you actually want to model something then they are my “go to” tools. There’s also LibBI which uses Sequential Monte Carlo rather than Hamiltonian Monte Carlo. Stan and LibBI are C++ with interfaces (I use the word very loosely) from e.g. R, Python, Matlab, etc. PyMC3 as you might guess is entirely Python. Both have very good communities. In Haskell there is also monad-bayes https://github.com/adscib/monad-bayes and baysig, the latter sadly not publicly available (last time I checked). If you have a hidden state model (e.g. stochastic volatility) then there is also particle filtering (aka Sequential Monte Carlo) using https://hackage.haskell.org/package/kalman-1.0.0.2 . I just looked at the commit log for monad-bayes and it seems to use HMC these days :) and supports ADVI. I spent a bit of time at the recent Zurihac with Alexander Vershilov making some very small steps towards a symplectic integrator package which could form the basis for HMC in Haskell. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Tue Jun 20 01:38:39 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 20 Jun 2017 13:38:39 +1200 Subject: [Haskell-cafe] MultiCase alternative In-Reply-To: <20170619092832.GA2776@Magus.localnet> References: <20170619092832.GA2776@Magus.localnet> Message-ID: <127CE07F-20D0-4667-9BF0-36F206BBC5C6@cs.otago.ac.nz> > On 19/06/2017, at 9:28 PM, Oleg wrote: > > > Richard A. O'Keefe wrote: > >> Let Pi be the pattern (i,_) | (_,i) >> In SML, >> fun f P1 ... Pn (0,0) = true >> | f _ ... _ _ = false >> >> fun g () = f (1,1) (2,2) ... (n,n) (1,1) >>> (So far it has taken 3 minutes on a fast machine to not >>> finish compiling these 3 lines of code... I fear the worst.) > > I can't speak for SML, but I was curious to try your example in OCaml, > which also supports OR patterns. My test case went up to ((20,_)|(_,20)). Your example goes up only to ((8,_)|(0,8)). Your version worked fast in F#. I'm currently trying a full scale example. F# ground away for a couple of minutes and then ran out of memory. ocamlc compiled it too fast to measure accurately. From romanandreg at gmail.com Tue Jun 20 02:15:48 2017 From: romanandreg at gmail.com (=?UTF-8?B?Um9tw6FuIEdvbnrDoWxleg==?=) Date: Mon, 19 Jun 2017 19:15:48 -0700 Subject: [Haskell-cafe] Vancouver Haskell Meetup session - Jun 22, 2017 Message-ID: Dear All, I'm happy to announce there will be a Haskell Meetup that is going to be held at Unbounce HQ this Thursday, Jun 22, 2017 This is intended to be a Newcomer friendly session, so basics of Why Haskell and Haskell used in production will be the main topics of the event. If you live in Vancouver, would hope to see you there. https://www.meetup.com/Vancouver-Haskell-Unmeetup/ Cheers. Roman.- -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Tue Jun 20 05:53:05 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Mon, 19 Jun 2017 22:53:05 -0700 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: Just want to bump this request as I have not gotten a reply. On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle wrote: > I am wondering what exception/error and random classes I should use for my > application. > > The application will be doing Monte Carlo backtracking search. I want it > to be multithreaded and run on all four cores on my MacBook. > > I need detailed error messages in order to investigate errors. So I will > throw errors or exceptions, then catch them in lower functions and annotate > them with the parameters or computations within the lower function, then > re-throw until finally the exception pops into the terminal. > > Because it's multi-threaded, at least some parts will needs to be in IO. > Also, because it's a Monte Carlo algorithm it will need to make > pseudorandom choices. > > Perhaps I should put everything in the IO monad? This will give me access > to threads and the standard generator seed. But how about throwing, > catching/rethrowing exceptions in IO? I have done this in pure code before: > not sure if it's better to do it that way, in which case I could put some > kind of state monad to hold the random seed together with an error monad > and IO at the core of the monad stack. > > Any advice welcome. > D > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asiamgenius at gmail.com Tue Jun 20 06:28:04 2017 From: asiamgenius at gmail.com (Abhiroop Sarkar) Date: Tue, 20 Jun 2017 11:58:04 +0530 Subject: [Haskell-cafe] Master programme with Haskell prospects In-Reply-To: References: Message-ID: Hi Georgi, I have similar interests as you and I am going to University of Nottingham for a Masters in Computer Science. Nottingham has a functional programming laboratory led by Prof. Graham Hutton and Prof. Thorsten Altenkirch : http://fp.cs.nott.ac.uk/ The programme has lots of interesting elective courses on functional programming, Logic, Mathematics etc. And also at the end of the course you do a thesis project with one of the research groups. Thanks Abhiroop On Mon, Jun 19, 2017 at 8:21 PM, Georgi Nakov wrote: > Hi all, > > I was pondering on Master programme with "good" Haskell-related prospects > upon completion (regardless whether it's in academia or industry). > Currently the only options available to me are Master in Logic at > University of Amsterdam and Computing Science at Utrecht. The latter has > more emphasis on FP and Haskell while the former seems more concerned with > the mathematical/philosophical foundations. Any thoughts or direct > observations on these programmes would be greatly appreciated. Thanks. > > Best regards, > Georgi > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -- Kloona - Coming Soon! -------------- next part -------------- An HTML attachment was scrubbed... URL: From doaitse.swierstra at gmail.com Tue Jun 20 07:06:23 2017 From: doaitse.swierstra at gmail.com (S D Swierstra) Date: Tue, 20 Jun 2017 09:06:23 +0200 Subject: [Haskell-cafe] Master programme with Haskell prospects In-Reply-To: References: Message-ID: <58E81465-4E68-4FD6-8412-F6BD439F608E@gmail.com> Keep in mind that the Netherlands are a small country, with Amsterdam close to Utrecht and vice versa, with the possibility to take courses in the other city as part of your program. In Utrecht there is Logic Department too. If your emphasis is on CS and Haskell and you want to pursue a career in industry (think Stadard Chartered and the like) I think Utrecht is the thing to choose. You will get a firm background in FP. If you want to pursue a career in Logic at some university Amsterdam is probably the thing to choose. I personally think that what a student learns depends largely on the way he manages to consume what is on offer and to choose from all the options. The fact that you are apparently asking such questions before chossing whete to go makes me feel optimistic. Doaitse Swierstra, emeritus from Utrecht so probably a bit biased. > Op 20 jun. 2017 om 08:28 heeft Abhiroop Sarkar het volgende geschreven: > > Hi Georgi, > > I have similar interests as you and I am going to University of Nottingham for a Masters in Computer Science. Nottingham has a functional programming laboratory led by Prof. Graham Hutton and Prof. Thorsten Altenkirch : http://fp.cs.nott.ac.uk/ The programme has lots of interesting elective courses on functional programming, Logic, Mathematics etc. And also at the end of the course you do a thesis project with one of the research groups. > > Thanks > Abhiroop > >> On Mon, Jun 19, 2017 at 8:21 PM, Georgi Nakov wrote: >> Hi all, >> >> I was pondering on Master programme with "good" Haskell-related prospects upon completion (regardless whether it's in academia or industry). Currently the only options available to me are Master in Logic at University of Amsterdam and Computing Science at Utrecht. The latter has more emphasis on FP and Haskell while the former seems more concerned with the mathematical/philosophical foundations. Any thoughts or direct observations on these programmes would be greatly appreciated. Thanks. >> >> >> Best regards, >> Georgi >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Kloona - Coming Soon! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ivan.miljenovic at gmail.com Tue Jun 20 08:40:35 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Tue, 20 Jun 2017 18:40:35 +1000 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: There are two general schools of thought as to how to deal with exceptions: * ExceptT/MonadError from transformers/mtl: http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html * The exceptions package (which is a lifted variant of Control.Exception in base): https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell On 20 June 2017 at 15:53, Dennis Raddle wrote: > Just want to bump this request as I have not gotten a reply. > > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle > wrote: >> >> I am wondering what exception/error and random classes I should use for my >> application. >> >> The application will be doing Monte Carlo backtracking search. I want it >> to be multithreaded and run on all four cores on my MacBook. >> >> I need detailed error messages in order to investigate errors. So I will >> throw errors or exceptions, then catch them in lower functions and annotate >> them with the parameters or computations within the lower function, then >> re-throw until finally the exception pops into the terminal. >> >> Because it's multi-threaded, at least some parts will needs to be in IO. >> Also, because it's a Monte Carlo algorithm it will need to make pseudorandom >> choices. >> >> Perhaps I should put everything in the IO monad? This will give me access >> to threads and the standard generator seed. But how about throwing, >> catching/rethrowing exceptions in IO? I have done this in pure code before: >> not sure if it's better to do it that way, in which case I could put some >> kind of state monad to hold the random seed together with an error monad and >> IO at the core of the monad stack. >> >> Any advice welcome. >> D >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From yotam2206 at gmail.com Tue Jun 20 09:28:15 2017 From: yotam2206 at gmail.com (Yotam Ohad) Date: Tue, 20 Jun 2017 09:28:15 +0000 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case Message-ID: Hi, After reading "Push-Pull Functional Reactive Programming " I had an idea about deciding which, of two events, comes first. Instead of using forkIO, I tried something like the following: infi :: Maybe Int infi = infi stop :: Maybe Int stop = Nothing test :: Int test = case (infi, stop) of (Nothing, Just _) -> 1 (_, _) -> 2 Here, infi is an action that never ends, and stop a function that ends immediately. I thought that the compiler would see that stop evaluates immediately to Nothing and thus will return 2, but it tries to evaluate infi and get stuck. I think it happens because I am using a tuple to hold both values (but not really sure about it). Do you know a way to make this arrangement work? Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From anselm.scholl at tu-harburg.de Tue Jun 20 10:07:42 2017 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Tue, 20 Jun 2017 12:07:42 +0200 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: References: Message-ID: <1d409030-9f82-a4f4-364b-db494e509cfa@tu-harburg.de> You have to keep in mind that you can only pattern match against a single thing at once. If you match at multiple things like you are doing, this is just syntactic sugar for the following: test = case (infi, stop) of (a, b) -> case a of Nothing -> case b of Just _ -> 1 _ -> 2 _ -> 2 The Haskell report states this in section 3.17.2 ("Pattern matching proceeds from left to right, and outside to inside") resp. section 3.17.3. To match with stop first, you either need to put it left of infi, or use multiple case statements. However, if you do not know, which of stop and infi will run forever (or throw an exception or behave like _|_ in any other way), you are stuck, because now you need to pick one to evaluate and if it is the wrong one, there is nothing you can do. If you want to leave the sane world, you could try to see if one of the arguments is already evaluated. However, your code would then be neither portable nor pure anymore. GHC tags pointers to evaluated values, so you can actually see if a value is evaluated without entering (evaluating) it - but there can be false negatives, not every evaluated closure is guaranteed to have the tag bits set and if neither of infi and stop has them set, you are back at square one. On 06/20/2017 11:28 AM, Yotam Ohad wrote: > Hi, > After reading "Push-Pull Functional Reactive Programming > " > I had an idea about deciding which, of two events, comes first. Instead > of using forkIO, I tried something like the following: > > infi :: Maybe Int > infi = infi > > stop :: Maybe Int > stop = Nothing > > test :: Int > test = case (infi, stop) of > (Nothing, Just _) -> 1 > (_, _) -> 2 > > Here, infi is an action that never ends, and stop a function that ends > immediately. I thought that the compiler would see that stop evaluates > immediately to Nothing and thus will return 2, but it tries to evaluate > infi and get stuck. > > I think it happens because I am using a tuple to hold both values (but > not really sure about it). Do you know a way to make this arrangement work? > > Yotam > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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: 488 bytes Desc: OpenPGP digital signature URL: From isaace71295 at gmail.com Tue Jun 20 10:10:07 2017 From: isaace71295 at gmail.com (Isaac Elliott) Date: Tue, 20 Jun 2017 10:10:07 +0000 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: References: Message-ID: Hey Yotam, Pattern matching clauses evaluate from left to right. You can get the behavour you're after by swapping the arguments in the tuple: case (stop, infi) of (Just _, Nothing) -> 1 (_, _) -> 2 Evaluates to 2 On Tue, 20 Jun. 2017, 7:29 pm Yotam Ohad, wrote: > Hi, > After reading "Push-Pull Functional Reactive Programming > " > I had an idea about deciding which, of two events, comes first. Instead of > using forkIO, I tried something like the following: > > infi :: Maybe Int > infi = infi > > stop :: Maybe Int > stop = Nothing > > test :: Int > test = case (infi, stop) of > (Nothing, Just _) -> 1 > (_, _) -> 2 > > Here, infi is an action that never ends, and stop a function that ends > immediately. I thought that the compiler would see that stop evaluates > immediately to Nothing and thus will return 2, but it tries to evaluate > infi and get stuck. > > I think it happens because I am using a tuple to hold both values (but not > really sure about it). Do you know a way to make this arrangement work? > > Yotam > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintonmead at gmail.com Tue Jun 20 11:18:55 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Tue, 20 Jun 2017 21:18:55 +1000 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: References: Message-ID: I don't think you're going to be able to achieve this with pattern matches. What may be useful is some of the stuff in the package unamb . On Tue, Jun 20, 2017 at 8:10 PM, Isaac Elliott wrote: > Hey Yotam, > > Pattern matching clauses evaluate from left to right. You can get the > behavour you're after by swapping the arguments in the tuple: > > case (stop, infi) of > (Just _, Nothing) -> 1 > (_, _) -> 2 > > Evaluates to 2 > > On Tue, 20 Jun. 2017, 7:29 pm Yotam Ohad, wrote: > >> Hi, >> After reading "Push-Pull Functional Reactive Programming >> " >> I had an idea about deciding which, of two events, comes first. Instead of >> using forkIO, I tried something like the following: >> >> infi :: Maybe Int >> infi = infi >> >> stop :: Maybe Int >> stop = Nothing >> >> test :: Int >> test = case (infi, stop) of >> (Nothing, Just _) -> 1 >> (_, _) -> 2 >> >> Here, infi is an action that never ends, and stop a function that ends >> immediately. I thought that the compiler would see that stop evaluates >> immediately to Nothing and thus will return 2, but it tries to evaluate >> infi and get stuck. >> >> I think it happens because I am using a tuple to hold both values (but >> not really sure about it). Do you know a way to make this arrangement work? >> >> Yotam >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 Tue Jun 20 15:23:23 2017 From: simon at joyful.com (Simon Michael) Date: Tue, 20 Jun 2017 08:23:23 -0700 Subject: [Haskell-cafe] [Announcement] Haskell game for iOS In-Reply-To: References: <20170613184709.3fbca72a@Pavel> Message-ID: Hi Ivan, that's really interesting and exciting. Thanks for persevering, writing about it, and sharing tools! Best -Simon From dennis.raddle at gmail.com Tue Jun 20 17:19:45 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Tue, 20 Jun 2017 10:19:45 -0700 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: Looking at my application needs, such as access to pseudorandom numbers and threads, does this suggest a particular course of action? D On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > There are two general schools of thought as to how to deal with exceptions: > > * ExceptT/MonadError from transformers/mtl: > http://www.mega-nerd.com/erikd/Blog/CodeHacking/ > Haskell/what_do_you_mean.html > > * The exceptions package (which is a lifted variant of > Control.Exception in base): > https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell > > On 20 June 2017 at 15:53, Dennis Raddle wrote: > > Just want to bump this request as I have not gotten a reply. > > > > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle > > wrote: > >> > >> I am wondering what exception/error and random classes I should use for > my > >> application. > >> > >> The application will be doing Monte Carlo backtracking search. I want it > >> to be multithreaded and run on all four cores on my MacBook. > >> > >> I need detailed error messages in order to investigate errors. So I will > >> throw errors or exceptions, then catch them in lower functions and > annotate > >> them with the parameters or computations within the lower function, then > >> re-throw until finally the exception pops into the terminal. > >> > >> Because it's multi-threaded, at least some parts will needs to be in IO. > >> Also, because it's a Monte Carlo algorithm it will need to make > pseudorandom > >> choices. > >> > >> Perhaps I should put everything in the IO monad? This will give me > access > >> to threads and the standard generator seed. But how about throwing, > >> catching/rethrowing exceptions in IO? I have done this in pure code > before: > >> not sure if it's better to do it that way, in which case I could put > some > >> kind of state monad to hold the random seed together with an error > monad and > >> IO at the core of the monad stack. > >> > >> Any advice welcome. > >> D > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Tue Jun 20 22:23:39 2017 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Wed, 21 Jun 2017 10:23:39 +1200 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: References: Message-ID: As I understand it, the original poster wanted the arguments to be evaluated *concurrently* and to catch whichever of them finished first. (OK, define "finished" to be "evaluated to WHNF".) Years ago people used to discuss the question of whether it was possible to define or True _ = True or _ True = True or False x = x or x False = x symmetrically, so that if *either* argument returned True, the result True would be delivered, even if the other argument diverged. As I recall it, the answer was "NO", but I don't recall the proof. From ivan.miljenovic at gmail.com Tue Jun 20 22:59:32 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 21 Jun 2017 08:59:32 +1000 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: On 21 June 2017 at 03:19, Dennis Raddle wrote: > Looking at my application needs, such as access to pseudorandom numbers and > threads, does this suggest a particular course of action? For randomness, probably mwc-random, carrying the seed around in a StateT with IO on the bottom of the stack. For multi-threaded: parallelism or concurrency? Simon Marlow's Parallel and Concurrent Programming in Haskell is an excellent book on the topic: http://shop.oreilly.com/product/0636920026365.do > > D > > > On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic > wrote: >> >> There are two general schools of thought as to how to deal with >> exceptions: >> >> * ExceptT/MonadError from transformers/mtl: >> >> http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html >> >> * The exceptions package (which is a lifted variant of >> Control.Exception in base): >> https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell >> >> On 20 June 2017 at 15:53, Dennis Raddle wrote: >> > Just want to bump this request as I have not gotten a reply. >> > >> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle >> > wrote: >> >> >> >> I am wondering what exception/error and random classes I should use for >> >> my >> >> application. >> >> >> >> The application will be doing Monte Carlo backtracking search. I want >> >> it >> >> to be multithreaded and run on all four cores on my MacBook. >> >> >> >> I need detailed error messages in order to investigate errors. So I >> >> will >> >> throw errors or exceptions, then catch them in lower functions and >> >> annotate >> >> them with the parameters or computations within the lower function, >> >> then >> >> re-throw until finally the exception pops into the terminal. >> >> >> >> Because it's multi-threaded, at least some parts will needs to be in >> >> IO. >> >> Also, because it's a Monte Carlo algorithm it will need to make >> >> pseudorandom >> >> choices. >> >> >> >> Perhaps I should put everything in the IO monad? This will give me >> >> access >> >> to threads and the standard generator seed. But how about throwing, >> >> catching/rethrowing exceptions in IO? I have done this in pure code >> >> before: >> >> not sure if it's better to do it that way, in which case I could put >> >> some >> >> kind of state monad to hold the random seed together with an error >> >> monad and >> >> IO at the core of the monad stack. >> >> >> >> Any advice welcome. >> >> D >> >> >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From lindsey at composition.al Tue Jun 20 23:08:08 2017 From: lindsey at composition.al (Lindsey Kuper) Date: Tue, 20 Jun 2017 16:08:08 -0700 Subject: [Haskell-cafe] DSLDI 2017: Call for Talk Proposals Message-ID: ********************************************************************* FIRST CALL FOR TALK PROPOSALS DSLDI 2017 Fifth Workshop on Domain-Specific Language Design and Implementation October 22, 2017 Vancouver, Canada Co-located with SPLASH http://2017.splashcon.org/track/dsldi-2017 https://twitter.com/wsdsldi ********************************************************************* Deadline for talk proposals: 7th of August, 2017 Well-designed and implemented domain-specific languages (DSLs) can achieve both usability and performance benefits over general-purpose programming languages. By raising the level of abstraction and exploiting domain knowledge, DSLs can make programming more accessible, increase programmer productivity, and support domain-specific optimizations. ## Workshop Goal Domain-Specific Language Design and Implementation (DSLDI) is a workshop intended to bring together researchers and practitioners interested in discussing how DSLs should be designed, implemented, supported by tools, and applied in realistic contexts. The focus of the workshop is on all aspects of this process, from soliciting domain knowledge from experts, through the design and implementation of the language, to evaluating whether and how a DSL is successful. More generally, we are interested in continuing to build a community that can drive forward the development of modern DSLs. ## Workshop Format DSLDI is a single-day workshop and will consist of an invited speaker followed by moderated audience discussions structured around a series of short talks. The role of the talks is to facilitate interesting and substantive discussion. Therefore, we welcome and encourage talks that express strong opinions, describe open problems, propose new research directions, and report on early research in progress. Proposed talks should be on topics within DSLDI’s area of interest, which include but are not limited to: * solicitation and representation of domain knowledge * DSL design principles and processes * DSL implementation techniques and language workbenches * domain-specific optimizations * human factors of DSLs * tool support for DSL users * community and educational support for DSL users * applications of DSLs to existing and emerging domains * studies of usability, performance, or other benefits of DSLs * experience reports of DSLs deployed in practice ## Call for Talk Proposals We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, open problem, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * Deadline for talk proposals: August 7th, 2017 * Notification: September 11th, 2017 * Workshop: October 22nd, 2017 * Submission website: https://dsldi17.hotcrp.com/ ## Workshop Organization Co-chairs: * Lindsey Kuper (lindsey at composition.al), Intel Labs * Eric Walkingshaw (eric.walkingshaw at oregonstate.edu), Oregon State University Follow us on Twitter at https://twitter.com/wsdsldi Program committee: * Nada Amin (EPFL/University of Cambridge) * Eric Holk (Google) * Gabriele Keller (Data61, CSIRO (formerly NICTA) and UNSW) * Rebekah Leslie-Hurd (Intel Labs) * Chris Martens (NCSU) * Lee Pike (Galois) * Jonathan Ragan-Kelley (UC Berkeley) * Jesús Sánchez Cuadrado (Autonomous University of Madrid) * Vincent St-Amour (Northwestern University) * Philip Wadler (University of Edinburgh) From jo at durchholz.org Tue Jun 20 23:28:49 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 21 Jun 2017 01:28:49 +0200 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: References: Message-ID: <2afbb416-1c6d-1991-26e7-f41b25aca522@durchholz.org> Am 21.06.2017 um 00:23 schrieb Richard A. O'Keefe: > As I understand it, the original poster wanted the arguments > to be evaluated *concurrently* and to catch whichever of them > finished first. (OK, define "finished" to be "evaluated to > WHNF".) Years ago people used to discuss the question of > whether it was possible to define > > or True _ = True > or _ True = True > or False x = x > or x False = x > > symmetrically, so that if *either* argument returned True, > the result True would be delivered, even if the other > argument diverged. As I recall it, the answer was "NO", > but I don't recall the proof. It depends on evaluation strategy I'd say. If evaluation is sequential ("depth-first"), if the first argument diverges, then the whole expression diverges and you never get to inspect the second argument to see whether it evaluates to True. If evaluation alternates ("breadth-first", "concurrently"), then infinities-caused divergence does not matter. Divergence due to invalid operations (division by zero, taking the head of an empty list etc.) will still cause failure. Of course this means evaluating both parameters, which is less efficient than just evaluating one of them and touch the second one only if needed. To capture invalidity divergence, you'll need to modify evaluation strategy further by allowing "known to diverge" as if it were an ordinary result (similar to NaN values in IEEE arithmetic). Actually SQL defines such a strategy, it assumes that divergence is equivalent to "this might be any value", which gives us counterintuitive answers like NULL == NULL evaluating to False, which is a well-known and rich source of bugs in any but the most trivial SQL statements. So this approach isn't a good idea at all. From taylor at fausak.me Thu Jun 22 15:38:07 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 22 Jun 2017 10:38:07 -0500 Subject: [Haskell-cafe] Issue 60 :: Haskell Weekly Message-ID: <1498145887.3025017.1018024368.2F571B85@webmail.messagingengine.com> \ Haskell Weekly \/\/ Issue 60 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what's going on in its community. ## Featured ## - Understanding ResourceT > Instead of just teaching you how to use the library, this post will demonstrate why you need it and how it works internally, to help you avoid some of the potential pitfalls of the library. - Announcing Weeder: dead export detection > Most projects accumulate code over time. To combat that, I've written Weeder which detects unused Haskell exports, allowing dead code to be removed (pulling up the weeds). - Dhall is now a template engine > Now you can use Dhall as a template engine with the newly released dhall-text library which provides a dhall-to-text executable for templating text. - Front Row is hiring a senior backend Haskell engineer > Come change how 6.5+ million K-12 US students learn Math, Language Arts, Social Studies and more. Use data, advanced type systems, great product design and deep pedagogy to change lives. - Testing PostgreSQL for fun > In this post I'll show how to make database programming fun by using packages that make testing easy. I'll walk through a example of building a durable queue backed with PostgreSQL. - Exceptional Servant handling > There are various good reasons why you might want to strip ExceptT from your Servant handlers. There are various good reasons why you wouldn't want to do that. I'm in the first camp --- I don't want ExceptT over IO. - On competing with C using Haskell > By writing very straight-forward pure, functional Haskell code without any special trickery, you can get performance equivalent to what you'd get by calling out to a C function, which is also in the same order of magnitude as the same algorithm implemented in a program completely written in C. - How well does it work? Profiling in Haskell > This is where benchmarking and profiling come in. We're going to take a specific problem and learn how we can use some Haskell tools to zero in on the problem point. - The chain in blockchain > This post develops a simple blockchain with the goal of understanding the basics of the chain. The most straightforward part of a blockchain is the chain itself, a sequence of blocks. - Mezzo: type-safe music composition > Its novelty is in the fact that it can enforce various rules of music composition statically, that is, at compile-time. This effectively means that if you write "bad" music, your composition will not compile --- think of it as a very strict spell-checker for music. - Linear types 101 and its relevance to streams > It creates a resource aware type system, which not only knows types of values but also number of uses; a linearly typed value is guaranteed to only have one reference to it at any time, duplication or ignoring will not compile. ## Package of the week ## This week's package of the week is async, a library that allows you to run IO operations asynchronously and wait for their results. ## In brief ## - An alternate definition of Haskell's Functor type class - Configurable data types - Generic unification - The linearity monad - A terminal interface for Tetris From mail at nh2.me Thu Jun 22 16:14:40 2017 From: mail at nh2.me (=?UTF-8?Q?Niklas_Hamb=c3=bcchen?=) Date: Thu, 22 Jun 2017 18:14:40 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently Message-ID: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> I'm writing this after having spent many hours of debugging why the packages "entropy" and "happy" have different compile-time behaviour when taken from Hackage vs when taken from their upstream git repositories. After lots of frustration, I finally figured out the problem: These packages have "Hackage revisions", where their cabal files were modified from its upstream equivalent: * https://hackage.haskell.org/package/happy-1.19.5/revisions/ * https://hackage.haskell.org/package/entropy-0.3.7/revisions/ Here, "setup-depends" were added to the cabal file, in order to make the package build correctly. These changes are on Hackage only, they cannot be found in the equivalent release of the upstream git repository. This is *extremely* confusing. The practice of "fixing up" other people's cabal files behind their back instead of making those fixes upstream prevents me to use their upstream git packages to reproduce my issues. It hides the fact that there is a problem with the upstream package. In the case of happy, there is not even any upstream fix in the master branch for the missing setup-depends: * https://hackage.haskell.org/package/happy-1.19.5/revision/2.cabal vs * https://github.com/simonmar/happy/blob/2d84ca0/happy.cabal So in this case, I suspect that the silent "fix" has prevented the upstream maintainer to even notice that there is a problem with his package, and so it will be broken again when he uploads the next version. I understand that the concept of Hackage revisions was introduced in a commendable effort to improve the package users' experience: Nobody likes when packages they want to use are broken. And it is clear that something has to be done when upstream authors don't reply to pull requests. But I believe this is not the case here. The upstream maintainers of "happy" and "entropy" are Simon Marlow and Thomas M. DuBuisson, who are very reliable getting stuff fixed (if they know about it!) and they apply PRs quickly and their repositories are well and alive. I believe we're shooting ourselves in the foot with these fixes: The time it takes to make an upstream fix and release it as a proper revision is dwarfed by the time it takes you to figure out bugs when the code you download from Hackage is not the code that the maintainer put there, and when package maintainers don't even notice that their packages are broken because of "silent fixing". So I would welcome if we could make use of the "Hackage revisions" feature only in the utmost necessary cases, or even better, never, and always make properly versioned releases, where a change to any file implies a bump of the version, so that one can clearly see if one is dealing with the unmodified upstream code or not. Greetings, Niklas From benno.fuenfstueck at gmail.com Thu Jun 22 16:59:31 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Thu, 22 Jun 2017 16:59:31 +0000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: At the very least, we should make sure that each revision is accompanied by an upstream PR if it is for the latest release (or any other still supported branch) and the project is hosted on some VCS service that supports PRs. Regards, Benno Niklas Hambüchen schrieb am Do., 22. Juni 2017, 18:16: > I'm writing this after having spent many hours of debugging why the > packages "entropy" and "happy" have different compile-time behaviour > when taken from Hackage vs when taken from their upstream git repositories. > > After lots of frustration, I finally figured out the problem: > > These packages have "Hackage revisions", where their cabal files were > modified from its upstream equivalent: > > * https://hackage.haskell.org/package/happy-1.19.5/revisions/ > * https://hackage.haskell.org/package/entropy-0.3.7/revisions/ > > Here, "setup-depends" were added to the cabal file, in order to make the > package build correctly. These changes are on Hackage only, they cannot > be found in the equivalent release of the upstream git repository. > > This is *extremely* confusing. > > The practice of "fixing up" other people's cabal files behind their back > instead of making those fixes upstream prevents me to use their upstream > git packages to reproduce my issues. > > It hides the fact that there is a problem with the upstream package. > > In the case of happy, there is not even any upstream fix in the master > branch for the missing setup-depends: > > * https://hackage.haskell.org/package/happy-1.19.5/revision/2.cabal vs > * https://github.com/simonmar/happy/blob/2d84ca0/happy.cabal > > So in this case, I suspect that the silent "fix" has prevented the > upstream maintainer to even notice that there is a problem with his > package, and so it will be broken again when he uploads the next version. > > I understand that the concept of Hackage revisions was introduced in a > commendable effort to improve the package users' experience: Nobody > likes when packages they want to use are broken. And it is clear that > something has to be done when upstream authors don't reply to pull > requests. > > But I believe this is not the case here. > The upstream maintainers of "happy" and "entropy" are Simon Marlow and > Thomas M. DuBuisson, who are very reliable getting stuff fixed (if they > know about it!) and they apply PRs quickly and their repositories are > well and alive. > > I believe we're shooting ourselves in the foot with these fixes: The > time it takes to make an upstream fix and release it as a proper > revision is dwarfed by the time it takes you to figure out bugs when the > code you download from Hackage is not the code that the maintainer put > there, and when package maintainers don't even notice that their > packages are broken because of "silent fixing". > > So I would welcome if we could make use of the "Hackage revisions" > feature only in the utmost necessary cases, or even better, never, and > always make properly versioned releases, where a change to any file > implies a bump of the version, so that one can clearly see if one is > dealing with the unmodified upstream code or not. > > Greetings, > Niklas > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Thu Jun 22 17:47:47 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 22 Jun 2017 19:47:47 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: ("Benno \=\?utf-8\?B\?RsO8bmZzdMO8Y2siJ3M\=\?\= message of "Thu, 22 Jun 2017 16:59:31 +0000") References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: <87zicz52yk.fsf@gmail.com> Hi, On 2017-06-22 at 18:59:31 +0200, Benno Fünfstück wrote: > At the very least, we should make sure that each revision is accompanied by > an upstream PR if it is for the latest release (or any other still > supported branch) and the project is hosted on some VCS service that > supports PRs. Yes! It's obviously good practice to inform maintainers about problems with their meta-data which require changes! And in fact, here's the ticket where it was discussed for entropy https://github.com/TomMD/entropy/issues/32 ...and as for happy (since I'm in frequent communication with Simon) I just left a note to pursue this at our next discussion https://github.com/simonmar/happy/issues/61#issuecomment-309669819 Cheers, Herbert From monkleyon at gmail.com Thu Jun 22 18:19:19 2017 From: monkleyon at gmail.com (MarLinn) Date: Thu, 22 Jun 2017 20:19:19 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: <830669c2-c794-a028-adc0-8f245155f51b@gmail.com> > At the very least, we should make sure that each revision is > accompanied by an upstream PR if it is for the latest release (or any > other still supported branch) and the project is hosted on some VCS > service that supports PRs. > Why "and" instead of "if"? A VCS is certainly a good idea. But a (public) VCS service? Why? Keep in mind that Github and its clones are only one of many options for software management. So why force maintainers to keep up with yet another service if they don't really want or need it? That only reduces the number of willing contributers and forces people into systems that they won't really use, so it wouldn't even solve the problem. I get the sentiment, but if email is good enough as a last-stage PR-queue for the Linux Kernel, we should allow package maintainers the same. If that makes it harder for them to integrate changes, that's their problem. (But one could always use a format that's easy to parse.) Bonus: automatic "PR's" via email should be dead-easy to implement and maintain compared to all alternatives. Cheers, MarLinn From jo at durchholz.org Thu Jun 22 19:07:22 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Thu, 22 Jun 2017 21:07:22 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen: > So I would welcome if we could make use of the "Hackage revisions" > feature only in the utmost necessary cases, or even better, never, and > always make properly versioned releases, where a change to any file > implies a bump of the version, so that one can clearly see if one is > dealing with the unmodified upstream code or not. I'd like to recommend the approach taken by Linux distros: If the package is modified vs. the original code, use a version numbering scheme that clearly indicates both the original version and a "packaging revision number". https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) updates should really be three revisions: happy-1.19.5 (original version uploaded by Simon) happy-1.19.5-hackage-1 (2015 update) happy-1.19.5-hackage-2 (2017 update) The assumption here is that Simon will bump the version to happy-1.19.6 before uploading the fixed package. From benno.fuenfstueck at gmail.com Thu Jun 22 19:22:43 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Thu, 22 Jun 2017 19:22:43 +0000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: <830669c2-c794-a028-adc0-8f245155f51b@gmail.com> References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> <830669c2-c794-a028-adc0-8f245155f51b@gmail.com> Message-ID: That should be read as "if (... And ...)" So I'm not recommending to force anyone to use a public VCS, I only wanted to express that revisions should be fine if there is no way to contact upstream devs (no public VCS was just an example here) MarLinn schrieb am Do., 22. Juni 2017, 20:20: > > > At the very least, we should make sure that each revision is > > accompanied by an upstream PR if it is for the latest release (or any > > other still supported branch) and the project is hosted on some VCS > > service that supports PRs. > > > > Why "and" instead of "if"? > > A VCS is certainly a good idea. But a (public) VCS service? Why? Keep in > mind that Github and its clones are only one of many options for > software management. So why force maintainers to keep up with yet > another service if they don't really want or need it? That only reduces > the number of willing contributers and forces people into systems that > they won't really use, so it wouldn't even solve the problem. > > I get the sentiment, but if email is good enough as a last-stage > PR-queue for the Linux Kernel, we should allow package maintainers the > same. If that makes it harder for them to integrate changes, that's > their problem. (But one could always use a format that's easy to parse.) > > Bonus: automatic "PR's" via email should be dead-easy to implement and > maintain compared to all alternatives. > > Cheers, > MarLinn > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benno.fuenfstueck at gmail.com Thu Jun 22 19:25:45 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Thu, 22 Jun 2017 19:25:45 +0000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: There is an X-Revision field in the cabal file, perhaps cabal-install should display it more prominently ( is it even displayed at all right now? ) https://hackage.haskell.org/package/happy-1.19.5/happy.cabal Joachim Durchholz schrieb am Do., 22. Juni 2017, 21:08: > Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen: > > So I would welcome if we could make use of the "Hackage revisions" > > feature only in the utmost necessary cases, or even better, never, and > > always make properly versioned releases, where a change to any file > > implies a bump of the version, so that one can clearly see if one is > > dealing with the unmodified upstream code or not. > > I'd like to recommend the approach taken by Linux distros: If the > package is modified vs. the original code, use a version numbering > scheme that clearly indicates both the original version and a "packaging > revision number". > https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) > updates should really be three revisions: > happy-1.19.5 (original version uploaded by Simon) > happy-1.19.5-hackage-1 (2015 update) > happy-1.19.5-hackage-2 (2017 update) > > The assumption here is that Simon will bump the version to happy-1.19.6 > before uploading the fixed package. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Thu Jun 22 22:54:00 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 23 Jun 2017 00:54:00 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: People expect the version number to uniquely identify the version of the package, so I think the Hackage revision should be included in the version number. If that means ugly version numbers: So be it, it's an incentive to tell upstream to update their code :-) Am 22.06.2017 um 21:25 schrieb Benno Fünfstück: > There is an X-Revision field in the cabal file, perhaps cabal-install > should display it more prominently ( is it even displayed at all right > now? ) > > https://hackage.haskell.org/package/happy-1.19.5/happy.cabal > > > Joachim Durchholz > schrieb > am Do., 22. Juni 2017, 21:08: > > Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen: > > So I would welcome if we could make use of the "Hackage revisions" > > feature only in the utmost necessary cases, or even better, > never, and > > always make properly versioned releases, where a change to any file > > implies a bump of the version, so that one can clearly see if one is > > dealing with the unmodified upstream code or not. > > I'd like to recommend the approach taken by Linux distros: If the > package is modified vs. the original code, use a version numbering > scheme that clearly indicates both the original version and a "packaging > revision number". > https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) > updates should really be three revisions: > happy-1.19.5 (original version uploaded by Simon) > happy-1.19.5-hackage-1 (2015 update) > happy-1.19.5-hackage-2 (2017 update) > > The assumption here is that Simon will bump the version to happy-1.19.6 > before uploading the fixed package. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 spam at scientician.net Fri Jun 23 03:45:46 2017 From: spam at scientician.net (Bardur Arantsson) Date: Fri, 23 Jun 2017 05:45:46 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: On 2017-06-22 21:07, Joachim Durchholz wrote: > Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen: >> So I would welcome if we could make use of the "Hackage revisions" >> feature only in the utmost necessary cases, or even better, never, and >> always make properly versioned releases, where a change to any file >> implies a bump of the version, so that one can clearly see if one is >> dealing with the unmodified upstream code or not. > > I'd like to recommend the approach taken by Linux distros: If the > package is modified vs. the original code, use a version numbering > scheme that clearly indicates both the original version and a "packaging > revision number". > https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) > updates should really be three revisions: > happy-1.19.5 (original version uploaded by Simon) > happy-1.19.5-hackage-1 (2015 update) > happy-1.19.5-hackage-2 (2017 update) > > The assumption here is that Simon will bump the version to happy-1.19.6 > before uploading the fixed package. +1000 Regards, From ivan.miljenovic at gmail.com Fri Jun 23 04:08:53 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 23 Jun 2017 14:08:53 +1000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: On 23 June 2017 at 05:07, Joachim Durchholz wrote: > Am 22.06.2017 um 18:14 schrieb Niklas Hambüchen: >> >> So I would welcome if we could make use of the "Hackage revisions" >> feature only in the utmost necessary cases, or even better, never, and >> always make properly versioned releases, where a change to any file >> implies a bump of the version, so that one can clearly see if one is >> dealing with the unmodified upstream code or not. > > > I'd like to recommend the approach taken by Linux distros: If the package is > modified vs. the original code, use a version numbering scheme that clearly > indicates both the original version and a "packaging revision number". > https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) > updates should really be three revisions: > happy-1.19.5 (original version uploaded by Simon) > happy-1.19.5-hackage-1 (2015 update) > happy-1.19.5-hackage-2 (2017 update) The problem being that Data.Version has deprecated the tags field, so we can't have that format. What about just appending one extra version field (assuming PVP, so bump/add field n >= 5) ? > > The assumption here is that Simon will bump the version to happy-1.19.6 > before uploading the fixed package. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 dennis.raddle at gmail.com Fri Jun 23 04:54:38 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 22 Jun 2017 21:54:38 -0700 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: Thanks for pointing me to mwc-random. I like that they provide a normal distribution; that is handy. I think by asking me parallelism or concurrency, you mean do I have algorithms that interact as they run in separate threads? This is a backtracking search algorithm, so each thread can explore a subset of the search space with no need to communicate with other threads. Does that mean "concurrency"? This is a pretty simple task. I hope that I don't have to delve deeply into concurrency/parallelism. D On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > On 21 June 2017 at 03:19, Dennis Raddle wrote: > > Looking at my application needs, such as access to pseudorandom numbers > and > > threads, does this suggest a particular course of action? > > For randomness, probably mwc-random, carrying the seed around in a > StateT with IO on the bottom of the stack. > > For multi-threaded: parallelism or concurrency? Simon Marlow's > Parallel and Concurrent Programming in Haskell is an excellent book on > the topic: http://shop.oreilly.com/product/0636920026365.do > > > > > D > > > > > > On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic > > wrote: > >> > >> There are two general schools of thought as to how to deal with > >> exceptions: > >> > >> * ExceptT/MonadError from transformers/mtl: > >> > >> http://www.mega-nerd.com/erikd/Blog/CodeHacking/ > Haskell/what_do_you_mean.html > >> > >> * The exceptions package (which is a lifted variant of > >> Control.Exception in base): > >> https://www.fpcomplete.com/blog/2016/11/exceptions-best- > practices-haskell > >> > >> On 20 June 2017 at 15:53, Dennis Raddle > wrote: > >> > Just want to bump this request as I have not gotten a reply. > >> > > >> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle < > dennis.raddle at gmail.com> > >> > wrote: > >> >> > >> >> I am wondering what exception/error and random classes I should use > for > >> >> my > >> >> application. > >> >> > >> >> The application will be doing Monte Carlo backtracking search. I want > >> >> it > >> >> to be multithreaded and run on all four cores on my MacBook. > >> >> > >> >> I need detailed error messages in order to investigate errors. So I > >> >> will > >> >> throw errors or exceptions, then catch them in lower functions and > >> >> annotate > >> >> them with the parameters or computations within the lower function, > >> >> then > >> >> re-throw until finally the exception pops into the terminal. > >> >> > >> >> Because it's multi-threaded, at least some parts will needs to be in > >> >> IO. > >> >> Also, because it's a Monte Carlo algorithm it will need to make > >> >> pseudorandom > >> >> choices. > >> >> > >> >> Perhaps I should put everything in the IO monad? This will give me > >> >> access > >> >> to threads and the standard generator seed. But how about throwing, > >> >> catching/rethrowing exceptions in IO? I have done this in pure code > >> >> before: > >> >> not sure if it's better to do it that way, in which case I could put > >> >> some > >> >> kind of state monad to hold the random seed together with an error > >> >> monad and > >> >> IO at the core of the monad stack. > >> >> > >> >> Any advice welcome. > >> >> D > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Haskell-Cafe mailing list > >> > To (un)subscribe, modify options or view archives go to: > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > Only members subscribed via the mailman list are allowed to post. > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Fri Jun 23 05:16:08 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 23 Jun 2017 15:16:08 +1000 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: On 23 June 2017 at 14:54, Dennis Raddle wrote: > Thanks for pointing me to mwc-random. I like that they provide a normal > distribution; that is handy. > > I think by asking me parallelism or concurrency, you mean do I have > algorithms that interact as they run in separate threads? > > This is a backtracking search algorithm, so each thread can explore a subset > of the search space with no need to communicate with other threads. Does > that mean "concurrency"? > > This is a pretty simple task. I hope that I don't have to delve deeply into > concurrency/parallelism. Parallelism: split data set up, run the same operation on each sub-set. Concurrency: do multiple things at once, possibly unrelated. Many languages use concurrency to implement parallelism; Haskell doesn't: see https://wiki.haskell.org/Parallelism_vs._Concurrency and https://wiki.haskell.org/Parallel For a start, have a look at the parallel package: http://hackage.haskell.org/package/parallel ; in particular, par can be used to fork off a new thread, and pseq can be used to ensure a thread finishes before you continue. > > D > > On Tue, Jun 20, 2017 at 3:59 PM, Ivan Lazar Miljenovic > wrote: >> >> On 21 June 2017 at 03:19, Dennis Raddle wrote: >> > Looking at my application needs, such as access to pseudorandom numbers >> > and >> > threads, does this suggest a particular course of action? >> >> For randomness, probably mwc-random, carrying the seed around in a >> StateT with IO on the bottom of the stack. >> >> For multi-threaded: parallelism or concurrency? Simon Marlow's >> Parallel and Concurrent Programming in Haskell is an excellent book on >> the topic: http://shop.oreilly.com/product/0636920026365.do >> >> > >> > D >> > >> > >> > On Tue, Jun 20, 2017 at 1:40 AM, Ivan Lazar Miljenovic >> > wrote: >> >> >> >> There are two general schools of thought as to how to deal with >> >> exceptions: >> >> >> >> * ExceptT/MonadError from transformers/mtl: >> >> >> >> >> >> http://www.mega-nerd.com/erikd/Blog/CodeHacking/Haskell/what_do_you_mean.html >> >> >> >> * The exceptions package (which is a lifted variant of >> >> Control.Exception in base): >> >> >> >> https://www.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell >> >> >> >> On 20 June 2017 at 15:53, Dennis Raddle >> >> wrote: >> >> > Just want to bump this request as I have not gotten a reply. >> >> > >> >> > On Fri, Jun 16, 2017 at 1:45 PM, Dennis Raddle >> >> > >> >> > wrote: >> >> >> >> >> >> I am wondering what exception/error and random classes I should use >> >> >> for >> >> >> my >> >> >> application. >> >> >> >> >> >> The application will be doing Monte Carlo backtracking search. I >> >> >> want >> >> >> it >> >> >> to be multithreaded and run on all four cores on my MacBook. >> >> >> >> >> >> I need detailed error messages in order to investigate errors. So I >> >> >> will >> >> >> throw errors or exceptions, then catch them in lower functions and >> >> >> annotate >> >> >> them with the parameters or computations within the lower function, >> >> >> then >> >> >> re-throw until finally the exception pops into the terminal. >> >> >> >> >> >> Because it's multi-threaded, at least some parts will needs to be in >> >> >> IO. >> >> >> Also, because it's a Monte Carlo algorithm it will need to make >> >> >> pseudorandom >> >> >> choices. >> >> >> >> >> >> Perhaps I should put everything in the IO monad? This will give me >> >> >> access >> >> >> to threads and the standard generator seed. But how about throwing, >> >> >> catching/rethrowing exceptions in IO? I have done this in pure code >> >> >> before: >> >> >> not sure if it's better to do it that way, in which case I could put >> >> >> some >> >> >> kind of state monad to hold the random seed together with an error >> >> >> monad and >> >> >> IO at the core of the monad stack. >> >> >> >> >> >> Any advice welcome. >> >> >> D >> >> >> >> >> > >> >> > >> >> > _______________________________________________ >> >> > Haskell-Cafe mailing list >> >> > To (un)subscribe, modify options or view archives go to: >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > Only members subscribed via the mailman list are allowed to post. >> >> >> >> >> >> >> >> -- >> >> Ivan Lazar Miljenovic >> >> Ivan.Miljenovic at gmail.com >> >> http://IvanMiljenovic.wordpress.com >> > >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com > > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From dennis.raddle at gmail.com Fri Jun 23 06:10:28 2017 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 22 Jun 2017 23:10:28 -0700 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: Thanks! Quick question, if I can split my task into 4 completely independent subtasks, what if I code a single program, then invoke this program on each of the 4 subtasks and let the OS give each program a CPU core (there are 4 cores on my MacBook)? Would that be a simple way to take advantage of parallelism? Note that it's always a good idea to start with a simpler prototype anyway ("solve a simpler problem first" in the words of Poyla) so it's a good idea for me to write a prototype that does not use parallelism. If I can then make it parallel just by invoking it four times and let the OS do its thing, that would be nice. D -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Fri Jun 23 06:26:14 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 23 Jun 2017 01:26:14 -0500 Subject: [Haskell-cafe] Having trouble with this recursive Parsec parser Message-ID: Hi all, I'm having trouble with a recursive parsec parser that keeps recursing on one type of end tag and terminates on another type of end tag. I'm sure I'm stuck on something silly, but here's what I have so far. Git repo with stack/cabal project: https://github.com/codygman/megaparsectest/blob/master/library/Example.hs Code I have so far (I deleted a few different approaches I tried because I thought they would clutter things up and make it harder to assist me with this issue): {-# LANGUAGE QuasiQuotes #-} -- | An example module. module Example where import Text.Megaparsec import Text.RawString.QQ import Text.Megaparsec.String -- input stream is of the type ‘String’ import qualified Text.Megaparsec.Lexer as L import Control.Monad (void, join) ex :: String ex = [r| begin field1 string begin field11 int field12 string end subsection; // optional end; |] data Field = Field String String deriving Show data Block = Fields [Field] | Block [Field] deriving Show sc :: Parser () sc = L.space (void spaceChar) lineCmnt blockCmnt where lineCmnt = L.skipLineComment "//" blockCmnt = L.skipBlockComment "/*" "*/" field :: Parser Field field = dbg "field" $ do sc Field <$> someTill ((oneOf' (['a'..'z'] ++ ['0'..'9']))) spaceChar <*> some ((oneOf' (['a'..'z'] ++ ['0'..'9']))) endEof = do sc *> string "end" *> char ';' *> sc *> eof pure "" endIdent = do string "end" *> sc ident <- someTill ((oneOf' (['a'..'z'] ++ ['0'..'9']))) (char ';') sc *> eof pure ident block = error "TODO implement" -- Thanks, -- Cody -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Fri Jun 23 06:31:02 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 23 Jun 2017 16:31:02 +1000 Subject: [Haskell-cafe] exceptions, errors, random In-Reply-To: References: Message-ID: On 23 June 2017 at 16:10, Dennis Raddle wrote: > Thanks! Quick question, if I can split my task into 4 completely independent > subtasks, what if I code a single program, then invoke this program on each > of the 4 subtasks and let the OS give each program a CPU core (there are 4 > cores on my MacBook)? Would that be a simple way to take advantage of > parallelism? Not a very efficient method, but in essence yes. > > Note that it's always a good idea to start with a simpler prototype anyway > ("solve a simpler problem first" in the words of Poyla) so it's a good idea > for me to write a prototype that does not use parallelism. If I can then > make it parallel just by invoking it four times and let the OS do its thing, > that would be nice. My take would be "build a non-threaded/serial solution, then try and parallelise different parts". > > D > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jo at durchholz.org Fri Jun 23 08:03:01 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 23 Jun 2017 10:03:01 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic: > On 23 June 2017 at 05:07, Joachim Durchholz wrote: >> I'd like to recommend the approach taken by Linux distros: If the package is >> modified vs. the original code, use a version numbering scheme that clearly >> indicates both the original version and a "packaging revision number". >> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) >> updates should really be three revisions: >> happy-1.19.5 (original version uploaded by Simon) >> happy-1.19.5-hackage-1 (2015 update) >> happy-1.19.5-hackage-2 (2017 update) > > The problem being that Data.Version has deprecated the tags field, so > we can't have that format. I gather that the tags are about to be dropped because they don't participate in ordering, violating either Eq or Ord requirements. Tags could be included in ordering to fix that; however, this would get the wrong order when comparing these two: 1.19.5-hackage-9 -> ([1, 19, 5), ["hackage", "9"]) 1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"]) The standard version comparison semantics is: * Split the string at digit/nondigit boundaries into subsequences * Digit subsequences are always greater than nondigit ones (this deals with projects that release 1.19 initially and then continue with 1.19.1, and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0) * If both subsequences are digits, use numeric comparison, otherwise use string comparison. This turns 1.19.5-hackage-2 into 1 . 19 . 5 -hackage- 2 This looks weird, but not so much if you consider that in practice, you never write down or see individual components but prefixes: 1 1.19 1.19.5 1.19.5-hackage 1.19.5-hackage-2 Version comparison specs usually omit the following situations because you never care about them in practice: - how to compare "007" and "7" (there are arguments for all three of <, =, and > so you can expect inconsistencies between ecosystems here) - whether to handle punctuation differently from letters or not (usually it's "use the simplest implementation", i.e. handle them as if they were letters) - how to deal with Unicode characters in nondigits subsequences (again, "simplest implementation", i.e. just use ByteString semantics) Disclaimer: The above is what I have been observing the version number comparisons converge to, in the the Linux package and the Java library ecosystems. Reports about ecosystems with different version "number" comparison conventions would be interesting to me. > What about just appending one extra version field (assuming PVP, so > bump/add field n >= 5) ? I don't know what PVP and n are in this context. From benno.fuenfstueck at gmail.com Fri Jun 23 08:27:38 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Fri, 23 Jun 2017 08:27:38 +0000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> Message-ID: Why would it need to be included in the version number? Note that, compared to version numbers, the revision number does not take part in dependency resolution (cabal always picks the latest revision AFAIK) I suggest that cabal should print something like: Building foo-1.2.3 (revision 2) If it uses a revision. This does not require the version number to change, it only changes the output of cabal so it should be uncontroversial and simple to implement. This would increase visibility in the case that a revision is used. There may be more places where this output makes sense, not just when printing the Building... Message Regards, Benno Joachim Durchholz schrieb am Fr., 23. Juni 2017, 10:05: > Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic: > > On 23 June 2017 at 05:07, Joachim Durchholz wrote: > >> I'd like to recommend the approach taken by Linux distros: If the > package is > >> modified vs. the original code, use a version numbering scheme that > clearly > >> indicates both the original version and a "packaging revision number". > >> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with two(!) > >> updates should really be three revisions: > >> happy-1.19.5 (original version uploaded by Simon) > >> happy-1.19.5-hackage-1 (2015 update) > >> happy-1.19.5-hackage-2 (2017 update) > > > > The problem being that Data.Version has deprecated the tags field, so > > we can't have that format. > > I gather that the tags are about to be dropped because they don't > participate in ordering, violating either Eq or Ord requirements. > Tags could be included in ordering to fix that; however, this would get > the wrong order when comparing these two: > 1.19.5-hackage-9 -> ([1, 19, 5), ["hackage", "9"]) > 1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"]) > > The standard version comparison semantics is: > * Split the string at digit/nondigit boundaries into subsequences > * Digit subsequences are always greater than nondigit ones (this deals > with projects that release 1.19 initially and then continue with 1.19.1, > and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0) > * If both subsequences are digits, use numeric comparison, otherwise use > string comparison. > > This turns > 1.19.5-hackage-2 > into > 1 > . > 19 > . > 5 > -hackage- > 2 > > This looks weird, but not so much if you consider that in practice, you > never write down or see individual components but prefixes: > 1 > 1.19 > 1.19.5 > 1.19.5-hackage > 1.19.5-hackage-2 > > Version comparison specs usually omit the following situations because > you never care about them in practice: > - how to compare "007" and "7" (there are arguments for all three of <, > =, and > so you can expect inconsistencies between ecosystems here) > - whether to handle punctuation differently from letters or not (usually > it's "use the simplest implementation", i.e. handle them as if they were > letters) > - how to deal with Unicode characters in nondigits subsequences (again, > "simplest implementation", i.e. just use ByteString semantics) > > Disclaimer: The above is what I have been observing the version number > comparisons converge to, in the the Linux package and the Java library > ecosystems. Reports about ecosystems with different version "number" > comparison conventions would be interesting to me. > > > What about just appending one extra version field (assuming PVP, so > > bump/add field n >= 5) ? > > I don't know what PVP and n are in this context. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ivan.miljenovic at gmail.com Fri Jun 23 08:40:08 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 23 Jun 2017 18:40:08 +1000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> Message-ID: On 23 June 2017 at 18:03, Joachim Durchholz wrote: > Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic: >> What about just appending one extra version field (assuming PVP, so >> bump/add field n >= 5) ? > > > I don't know what PVP and n are in this context. The Package Versioning Policy and "field n" (or "nth component of the version"). -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From clintonmead at gmail.com Fri Jun 23 09:43:10 2017 From: clintonmead at gmail.com (Clinton Mead) Date: Fri, 23 Jun 2017 19:43:10 +1000 Subject: [Haskell-cafe] Why can't GHC infer record fields? Message-ID: I asked this below question on Stack Overflow and I got an answer suggesting that GHC doesn't support type inference of overloaded record fields. But I'm wondering why this is the case. Consider the following: {-# LANGUAGE DuplicateRecordFields #-} data A = A { name :: String } data B = B { name :: String } main = print $ name (A "Alice") When compiled, I get the following message (on GHC 8.0.2) duplicatedrecords.hs:7:16: error: Ambiguous occurrence ‘name’ It could refer to either the field ‘name’, defined at duplicatedrecords.hs:5:14 or the field ‘name’, defined at duplicatedrecords.hs:3:14 But if I modify the main line as follows: main = print $ name ((A "Alice") :: A) Compilation proceeds successfully. I'm not sure why I need the :: A here, it seems to be clear that (A "Alice") is of type A due to the A constructor. It's worth noting that the following compiles fine: data A = A { a_name :: String }data B = B { b_name :: String } class Name t where name :: t -> String instance Name A where name = a_nameinstance Name B where name = b_name main = print $ name (A "Alice") We can even go further as follows, allowing different result types: {-# LANGUAGE TypeFamilies #-} data A = A { a_name :: String }data B = B { b_name :: Int } class Name t where type family T t name :: t -> T t instance Name A where type T A = String name = a_name instance Name B where type T B = Int name = b_name main = print $ name (A "Alice") It seems like GHC just has to mechanically add a class for each unique record name and an instance for each record in each data type. This will mean however that name x == name y not implying that the types of x and y are the same but I'd expect that when using this extension anyway. Just wondering if there's anything tricky I'm missing here regarding the implementation or that it just needs someone to implement it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Fri Jun 23 11:34:38 2017 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Fri, 23 Jun 2017 12:34:38 +0100 Subject: [Haskell-cafe] Why can't GHC infer record fields? In-Reply-To: References: Message-ID: Seems related to https://ghc.haskell.org/trac/ghc/ticket/11343 Matt On Fri, Jun 23, 2017 at 10:43 AM, Clinton Mead wrote: > I asked this below question on Stack Overflow and I got an answer suggesting > that GHC doesn't support type inference of overloaded record fields. But I'm > wondering why this is the case. > > Consider the following: > > {-# LANGUAGE DuplicateRecordFields #-} > > data A = A { name :: String } > > data B = B { name :: String } > > main = print $ name (A "Alice") > > When compiled, I get the following message (on GHC 8.0.2) > > duplicatedrecords.hs:7:16: error: > Ambiguous occurrence ‘name’ > It could refer to either the field ‘name’, > defined at duplicatedrecords.hs:5:14 > or the field ‘name’, defined at > duplicatedrecords.hs:3:14 > > But if I modify the main line as follows: > > main = print $ name ((A "Alice") :: A) > > Compilation proceeds successfully. I'm not sure why I need the :: A here, it > seems to be clear that (A "Alice") is of type A due to the A constructor. > > It's worth noting that the following compiles fine: > > data A = A { a_name :: String } > data B = B { b_name :: String } > > class Name t where > name :: t -> String > > instance Name A where name = a_name > instance Name B where name = b_name > > main = print $ name (A "Alice") > > We can even go further as follows, allowing different result types: > > {-# LANGUAGE TypeFamilies #-} > > data A = A { a_name :: String } > data B = B { b_name :: Int } > > class Name t where > type family T t > name :: t -> T t > > instance Name A where > type T A = String > name = a_name > > instance Name B where > type T B = Int > name = b_name > > main = print $ name (A "Alice") > > It seems like GHC just has to mechanically add a class for each unique > record name and an instance for each record in each data type. This will > mean however that name x == name y not implying that the types of x and y > are the same but I'd expect that when using this extension anyway. > > Just wondering if there's anything tricky I'm missing here regarding the > implementation or that it just needs someone to implement it? > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ryan.trinkle at gmail.com Fri Jun 23 15:31:37 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Fri, 23 Jun 2017 11:31:37 -0400 Subject: [Haskell-cafe] Dynamically linking frameworks on macOS Message-ID: Hi everyone, I'm trying to ensure that beginner-level code that uses reflex-dom can be built by simply calling 'ghc myFile.hs', provided that all the necessary libraries are available in ghc-pkg. This works on linux, but on macOS, it's currently necessary for the user to add '-dynamic' to the command line. In particular, without -dynamic, the linker fails to find "_OBJC_CLASS_$_NSURL", which is a symbol in the Foundation system framework. Apple doesn't support (and strongly discourages) statically linked executables[1], so it's not terribly surprising that this doesn't work. Is there anything I can do to avoid the need for -dynamic here? Thanks, Ryan [1] https://developer.apple.com/library/content/qa/qa1118/_index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Fri Jun 23 18:36:54 2017 From: trebla at vex.net (Albert Y. C. Lai) Date: Fri, 23 Jun 2017 14:36:54 -0400 Subject: [Haskell-cafe] Implicit Multi Threading in Switch Case In-Reply-To: <2afbb416-1c6d-1991-26e7-f41b25aca522@durchholz.org> References: <2afbb416-1c6d-1991-26e7-f41b25aca522@durchholz.org> Message-ID: <6b056427-fbf0-160c-d406-2326eda531dc@vex.net> On 2017-06-20 07:28 PM, Joachim Durchholz wrote: > It depends on evaluation strategy I'd say. No, without nailing an evaluation strategy, Haskell 2010 (and 98, and ...) still manages to denotationally rule out the parallel-or example. From jo at durchholz.org Fri Jun 23 20:13:00 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Fri, 23 Jun 2017 22:13:00 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> <0b0d88f9-9590-1233-9bbf-58ed562fbd5b@durchholz.org> Message-ID: <29696307-26ba-e191-d330-ca51ddaade83@durchholz.org> Am 23.06.2017 um 10:27 schrieb Benno Fünfstück: > Why would it need to be included in the version number? Note that, > compared to version numbers, the revision number does not take part in > dependency resolution (cabal always picks the latest revision AFAIK) Dependencies specify minimum and/or maximum revisions, so revision ordering is really important. > I suggest that cabal should print something like: > > Building foo-1.2.3 (revision 2) > > If it uses a revision. This does not require the version number to > change, it only changes the output of cabal so it should be > uncontroversial and simple to implement. I'm feeling uneasy about that, for various reasons. 1) "Revision" is a somewhat vague terminology here. It's unclear what kind of revision, and how that's different from a version. From what I gather, it's essentially just a sub-version of 1.2.3 created by the Hackage people instead of original upstream. 2) Having a version and a revision works fine if there are two parties involved (in this case: upstream and Hackage guys). The approach doesn't scale to more parties, which is rare but does happen. 3) Also, "revision" might not just cut it. E.g. Maven (Java's moral equivalent of Hackage) offers two kinds of modules, productive (never ever change) and snapshot (may change at the drop of the hat), and snapshot versions/revisions are simply marked by a SNAPSHOT part in the version number. If a repository offers more module categories, it will want to differentiate between them; since the set of categories may grow over time, and different repositories may offer different categories, you want that to be extensible. Essentially, it boils down to "there should a single identifier for a specific build of a module, let's call that the module version; and different repositories may have different needs so a mere integer list doesn't but it". From another perspective, allowing strings in versions subsumes tags, but in a semantically clean way. Just my 2 cents. > This would increase visibility in the case that a revision is used. > There may be more places where this output makes sense, not just when > printing the Building... Message > > Regards, > > Benno > > > Joachim Durchholz > schrieb > am Fr., 23. Juni 2017, 10:05: > > Am 23.06.2017 um 06:08 schrieb Ivan Lazar Miljenovic: > > On 23 June 2017 at 05:07, Joachim Durchholz > wrote: > >> I'd like to recommend the approach taken by Linux distros: If > the package is > >> modified vs. the original code, use a version numbering scheme > that clearly > >> indicates both the original version and a "packaging revision > number". > >> https://hackage.haskell.org/package/happy-1.19.5/revisions/ with > two(!) > >> updates should really be three revisions: > >> happy-1.19.5 (original version uploaded by Simon) > >> happy-1.19.5-hackage-1 (2015 update) > >> happy-1.19.5-hackage-2 (2017 update) > > > > The problem being that Data.Version has deprecated the tags field, so > > we can't have that format. > > I gather that the tags are about to be dropped because they don't > participate in ordering, violating either Eq or Ord requirements. > Tags could be included in ordering to fix that; however, this would get > the wrong order when comparing these two: > 1.19.5-hackage-9 -> ([1, 19, 5), ["hackage", "9"]) > 1.19.5-hackage-10 -> ([1, 19, 5), ["hackage", "10"]) > > The standard version comparison semantics is: > * Split the string at digit/nondigit boundaries into subsequences > * Digit subsequences are always greater than nondigit ones (this deals > with projects that release 1.19 initially and then continue with 1.19.1, > and also correctly sorts 1.19-hackage-0 before 1.19.1-hackage-0) > * If both subsequences are digits, use numeric comparison, otherwise use > string comparison. > > This turns > 1.19.5-hackage-2 > into > 1 > . > 19 > . > 5 > -hackage- > 2 > > This looks weird, but not so much if you consider that in practice, you > never write down or see individual components but prefixes: > 1 > 1.19 > 1.19.5 > 1.19.5-hackage > 1.19.5-hackage-2 > > Version comparison specs usually omit the following situations because > you never care about them in practice: > - how to compare "007" and "7" (there are arguments for all three of <, > =, and > so you can expect inconsistencies between ecosystems here) > - whether to handle punctuation differently from letters or not (usually > it's "use the simplest implementation", i.e. handle them as if they were > letters) > - how to deal with Unicode characters in nondigits subsequences (again, > "simplest implementation", i.e. just use ByteString semantics) > > Disclaimer: The above is what I have been observing the version number > comparisons converge to, in the the Linux package and the Java library > ecosystems. Reports about ecosystems with different version "number" > comparison conventions would be interesting to me. > > > What about just appending one extra version field (assuming PVP, so > > bump/add field n >= 5) ? > > I don't know what PVP and n are in this context. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 anthony_clayden at clear.net.nz Sat Jun 24 00:44:30 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 24 Jun 2017 12:44:30 +1200 Subject: [Haskell-cafe] Proposal: Instance apartness guards Message-ID: <594db5ee.312.4d.22425@clear.net.nz> After years of pondering this idea (in various forms), and several rounds of discussion on several forums, I've written it up. "This proposal tackles the thorny topic of Overlapping instances, for both type classes and Type Families/Associated types, by annotating instance heads with type-level apartness Guards. Type-level disequality predicates appear in Sulzmann & Stuckey 2002; in the type-level ‘case selection’ in HList 2004; and in various guises in Haskell cafe discussions in following years. This proposal builds on the apartness testing implemented as part of the Closed Type Families work." All feedback welcome. https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/proposals/0000-instance-apartness-guards.rst AntC From chneukirchen at gmail.com Sun Jun 25 13:46:40 2017 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sun, 25 Jun 2017 15:46:40 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2017-06-27 @ 19:30 Message-ID: <87zicwxjr3.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 27 at Hirschgarten (self-service area) 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-jun-2017/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From ivan.miljenovic at gmail.com Mon Jun 26 03:59:38 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 26 Jun 2017 13:59:38 +1000 Subject: [Haskell-cafe] External scripts for use in testing Message-ID: I'm trying to write a test suite for a package, but to properly ensure it's working I need to have some sample script/program for it to interact with. What would be the best way to ship this script/program? I was considering using extra-source-files but the Paths_* support from Cabal doesn't seem to list those. So should I ship them as a data file (which could have an issue if they aren't marked executable and installed globally)? Or blindly trust that the test suite is being run from within the source directory and try to guess/determine it's location from that? Furthermore, what about if it's an actual (small) program that requires compilation? Or am I completely out of luck at this point? -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From tjakway at nyu.edu Mon Jun 26 06:26:59 2017 From: tjakway at nyu.edu (Thomas Jakway) Date: Mon, 26 Jun 2017 02:26:59 -0400 Subject: [Haskell-cafe] Dynamically linking frameworks on macOS (Ryan Trinkle) Message-ID: <63ad5401-9bcf-db46-01a2-bf8f0b23030c@nyu.edu> You could provide a wrapper script around ghc to pass -dynamic automatically. Or when installing append alias ghc="ghc -dynamic" to their bashrc. Not elegant but it's probably easier than any other solution. On 06/24/2017 08:00 AM, haskell-cafe-request at haskell.org wrote: > Message: 1 > Date: Fri, 23 Jun 2017 11:31:37 -0400 > From: Ryan Trinkle > To: Haskell Cafe > Subject: [Haskell-cafe] Dynamically linking frameworks on macOS > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > I'm trying to ensure that beginner-level code that uses reflex-dom can be > built by simply calling 'ghc myFile.hs', provided that all the necessary > libraries are available in ghc-pkg. This works on linux, but on macOS, > it's currently necessary for the user to add '-dynamic' to the command > line. In particular, without -dynamic, the linker fails to find > "_OBJC_CLASS_$_NSURL", which is a symbol in the Foundation system > framework. Apple doesn't support (and strongly discourages) statically > linked executables[1], so it's not terribly surprising that this doesn't > work. > > Is there anything I can do to avoid the need for -dynamic here? > > > Thanks, > Ryan > > [1]https://developer.apple.com/library/content/qa/qa1118/_index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From simons at nospf.cryp.to Mon Jun 26 07:40:15 2017 From: simons at nospf.cryp.to (Peter Simons) Date: Mon, 26 Jun 2017 09:40:15 +0200 Subject: [Haskell-cafe] External scripts for use in testing References: Message-ID: <87shinnqn4.fsf@write-only.cryp.to> Hi Ivan, > Or blindly trust that the test suite is being run from within the > source directory and try to guess/determine it's location from that? yes, that is the way to go. "cabal check" has its current working directory in the directory that contains your cabal file, so you can refer to contents of your release tarball by relative path from there. Best regards, Peter From magnus at therning.org Mon Jun 26 08:40:11 2017 From: magnus at therning.org (Magnus Therning) Date: Mon, 26 Jun 2017 10:40:11 +0200 Subject: [Haskell-cafe] stack, git, directory structure In-Reply-To: References: Message-ID: <87shinrvkk.fsf@therning.org> Dennis Raddle writes: > I got a private reply which helps but it made me think of another question. > > In the stack demo, there's one executable 'helloworld-exe' which is > compiled from app/Main.hs. > > If I'm going to have several executables, what do I call the source files, > and how do I control the file name of the executable that gets built? AFAIU that's what the `executable: ` in your .cabal does. This is the text describing executable sections at [1]. Executable sections (if present) describe executable programs contained in the package and must have an argument after the section label, which defines the name of the executable. This is a freeform argument but may not contain spaces. And you control the source files using `main-is:` and `other-modules:`. One common pattern I've seen is to put most source files into a library and then have each executable use that library and have a very "thin" main source file. /M [1]: https://www.haskell.org/cabal/users-guide/developing-packages.html#executables -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus The greatest performance improvement of all is when a system goes from not-working to working. — John Ousterhout -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: From heraldhoi at gmail.com Mon Jun 26 11:09:12 2017 From: heraldhoi at gmail.com (Geraldus) Date: Mon, 26 Jun 2017 11:09:12 +0000 Subject: [Haskell-cafe] OpenCV Haskell: Missing C libraries (macOS) Message-ID: Hi folks! I'm trying to build opencv as dependency on my macOS Sierra. I stuck with missing _contrib and _legacy C libraries. I've installed OpenCV with contrib packages via brew. Here are the steps I've done. Installation I have installed opencv via brew (with some patches of brew formula): brew install opencv3 --with-contrib --with-python3 python Python 3.6.1 (default, Apr 4 2017, 09:40:21) [GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.38)] on darwin Type "help", "copyright", "credits" or "license" for more information.>>> import cv2>>> cv2.__version__'3.2.0' I have not installed Python 2.7 bindings. Python 3.6 only. Now stack build need some attention too: stack build opencv-0.0.1.0: configure Progress: 1/2 -- While building package opencv-0.0.1.0 using: Configuring opencv-0.0.1.0... setup: Missing dependencies on foreign libraries: * Missing C libraries: opencv_calib3d, opencv_imgproc, opencv_contrib, opencv_legacy, This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. Following suggestion I've tried specify include and lib dirs: stack build --extra-lib-dirs=/usr/local/opt/opencv3/lib --extra-include-dirs=/usr/local/opt/opencv3/include opencv-0.0.1.0: configure Progress: 1/2 -- While building package opencv-0.0.1.0 using: Configuring opencv-0.0.1.0... setup: Missing dependencies on foreign libraries: * Missing C libraries: opencv_contrib, opencv_legacy, This problem can usually be solved by installing the system packages that provide these libraries (you may need the "-dev" versions). If the libraries are already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are. I have no idea how to find where missing libraries are located. Would appreciate any help! Arthur! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Mon Jun 26 20:35:20 2017 From: rf at rufflewind.com (Phil Ruffwind) Date: Mon, 26 Jun 2017 16:35:20 -0400 Subject: [Haskell-cafe] Dynamically linking frameworks on macOS (Ryan Trinkle) In-Reply-To: <63ad5401-9bcf-db46-01a2-bf8f0b23030c@nyu.edu> References: <63ad5401-9bcf-db46-01a2-bf8f0b23030c@nyu.edu> Message-ID: <1498509320.2454991.1022021640.7002C09F@webmail.messagingengine.com> Ryan Trinkle wrote: > Is there anything I can do to avoid the need for -dynamic here? Heh, I was finagling with this yesterday for different reasons (Arch removed static boot libs from GHC). I found that there's a pc_DYNAMIC_BY_DEFAULT flag in /usr/lib/ghc-*.*.*/platformConstants which turns on -dynamic by default. I can't say if this will break anything (Cabal in particular) though, given that "DynamicByDefault" does not seem to have received much dev attention in recent years. From wybitul.evzen at gmail.com Tue Jun 27 03:45:14 2017 From: wybitul.evzen at gmail.com (=?utf-8?Q?Ev=C5=BEen_Wybitul?=) Date: Tue, 27 Jun 2017 05:45:14 +0200 Subject: [Haskell-cafe] Using Intero on latest MacOS Message-ID: I’m using the latest developer beta of MacOS High Sierra. There are some problems with new Clang/LLVM; I can’t install terminfo, because of this problem: https://ghc.haskell.org/trac/ghc/ticket/13805 . It seems it's been already fixed (and that it can be fixed by passing an argument to CFLAGS) - I don’t really know what CFLAGS are, though, and I also don’t know how can I update my local Clang/LLVM to include the new patch. Is somebody in a similar situation? I’d welcome any help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From istathar at gmail.com Tue Jun 27 05:10:21 2017 From: istathar at gmail.com (Andrew Cowie) Date: Tue, 27 Jun 2017 05:10:21 +0000 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > The problem being that Data.Version has deprecated the tags field, So, undeprecate it. AfC -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Tue Jun 27 12:29:03 2017 From: J.Hage at uu.nl (Jurriaan Hage) Date: Tue, 27 Jun 2017 14:29:03 +0200 Subject: [Haskell-cafe] Domain specific error diagnosis in Haskell, a video recorded at Curry On! Message-ID: <6874E05D-9EF6-436E-B710-DD5FFD3CCA32@uu.nl> Dear Haskellers, The work of Alejandro Serrano Mena and myself on domain-specific error diagnosis in GHC was accepted for a presentation at Curry On! in Barcelona, co-located with ECOOP. I gave the talk last week on what you can do with our branch of GHC. A few well-known Haskellers were around. They had some good questions, and were generally quite positive. In case you missed it, there is a video of the whole affair on YouTube. Here is the link: https://www.youtube.com/watch?v=LuqSkWOcnSA&feature=youtu.be best regards, Jur From pumpkingod at gmail.com Tue Jun 27 14:33:16 2017 From: pumpkingod at gmail.com (Daniel Peebles) Date: Tue, 27 Jun 2017 10:33:16 -0400 Subject: [Haskell-cafe] Dynamically linking frameworks on macOS In-Reply-To: References: Message-ID: I don't know about your specific issue with Foundation.framework, but regarding "Apple doesn't support (and strongly discourages) statically linked executables[1], so it's not terribly surprising that this doesn't work." I think you're interpreting it a bit more broadly than intended. Apple's point in that tech note is that you shouldn't statically link what most people think of as libc (called libSystem on macOS). You can statically link anything else because that's basically just you deciding how you want to organize your software. The reason for this is that libSystem is where the kernel syscall wrappers live, and they don't want you to make syscalls directly because they don't want to commit to a particular kernel ABI. That's why they don't ship a static libSystem or any of that crt0.o stuff, but if you have a ton of .a libraries you want to link into your executable that's fine because it'll still be linking to libSystem.dylib when it wants to make syscalls. The only mainstream project I know that actively ignores this advice is Go, which has implemented its own syscall wrappers for macOS and as such occasionally gets weird bugs when Apple makes changes to the kernel ABI. On Fri, Jun 23, 2017 at 11:31 AM, Ryan Trinkle wrote: > Hi everyone, > > I'm trying to ensure that beginner-level code that uses reflex-dom can be > built by simply calling 'ghc myFile.hs', provided that all the necessary > libraries are available in ghc-pkg. This works on linux, but on macOS, > it's currently necessary for the user to add '-dynamic' to the command > line. In particular, without -dynamic, the linker fails to find > "_OBJC_CLASS_$_NSURL", which is a symbol in the Foundation system > framework. Apple doesn't support (and strongly discourages) statically > linked executables[1], so it's not terribly surprising that this doesn't > work. > > Is there anything I can do to avoid the need for -dynamic here? > > > Thanks, > Ryan > > [1] https://developer.apple.com/library/content/qa/qa1118/_index.html > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruben.astud at gmail.com Tue Jun 27 17:13:57 2017 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Tue, 27 Jun 2017 13:13:57 -0400 Subject: [Haskell-cafe] +RTS -n option Message-ID: <01711fa0-77d9-ac40-a05c-84d78448a8e2@gmail.com> Dear list I got a doubt on how the -n flag works. With 2 capabilities, is -A2m -n512k equivalent to just -A512k and 4 less times the garbage collection? It seems a win on every situation. I know I am being naive, but I don't know what could be missing. Care to share your thought on this? -- -- Ruben Astudillo -- PGP: 4EE9 28F7 932E F4AD From allbery.b at gmail.com Tue Jun 27 17:51:51 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 27 Jun 2017 13:51:51 -0400 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: On Tue, Jun 27, 2017 at 1:10 AM, Andrew Cowie wrote: > On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> wrote: > >> The problem being that Data.Version has deprecated the tags field, > > > So, undeprecate it. > Only if you can define a sensible behavior for it; the main reason for deprecating it, as I understand it, is its semantics were never defined and it could therefore never be actually used for anything. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Tue Jun 27 17:58:29 2017 From: jo at durchholz.org (Joachim Durchholz) Date: Tue, 27 Jun 2017 19:58:29 +0200 Subject: [Haskell-cafe] I think we should stop "fixing" other people's packages on Hackage silently In-Reply-To: References: <20a427ce-8304-70c2-ce1f-8b4362a1eaac@nh2.me> Message-ID: Am 27.06.2017 um 07:10 schrieb Andrew Cowie: > On Fri, 23 Jun 2017 at 14:10 Ivan Lazar Miljenovic > > wrote: > > The problem being that Data.Version has deprecated the tags field, > > > So, undeprecate it. The patch that deprecates it mentions problems with Eq and Ord. I suspect the implementation is inconsistent with the axioms. Also, a list of tags independent of version numbers isn't exactly what would be needed to differentiate between two versions on Hackage, you actually need an "upstream" and a "Hackage" version number, plus maybe more version numbers if a piece of code goes through more stations. I.e. that wouldn't solve the problem, it needs to be replaced with something better. From mookerji at gmail.com Tue Jun 27 19:39:54 2017 From: mookerji at gmail.com (Bhaskar Mookerji) Date: Tue, 27 Jun 2017 12:39:54 -0700 Subject: [Haskell-cafe] Haskell Infrastructure Jobs @ Swift Navigation (SF) Message-ID: Hello! I work at Swift Navigation, a high-accuracy GPS receiver manufacturer in San Francisco. We are currently looking to grow out our platform infrastructure team in the next few months and have **several positions** open for experienced Haskell developers. We definitely are open to remote candidates. You can **apply through the posting** here: https://jobs.lever.co/swift-nav/eb80d943-8157-4c9b-afef-8fe98d287c28. The text of this is reproduced at the end of the email. If you have any questions, feel free to comment or email me directly at mookerji at swiftnav.com. * About the Work We are a very small team supporting a zoo of libraries and internal services at Swift, including a mature ETL pipeline for evaluating our hardware product, as well an upcoming real-time GPS data product. We open source our work where possible and appropriate (https://github.com/swift-nav?utf8=%E2%9C%93&q=&type=&language=haskell). The ideal candidate will have experience designing and implementing Haskell backends in a commercial web services environment. A Haskell open-source background or production experience using another functional programming language (Scala, Clojure, Erlang, etc.). would also work. We value good communication skills, technical fluency, and responsibility in our day-to-day, and would enjoy seeing these personal qualities in future contributors. * About the Company We design, test, manufacture, and sell a Linux-based GPS/GLONASS receiver for machine automation applications, specifically targeting the autonomous vehicle market. Our work environment is very multidisciplinary, with ~30 engineers covering many areas of engineering (electrical/firmware, embedded Linux, statistics, satellite navigation, web, etc.). You definitely don't need knowledge of these subjects to work here, but you may find it a refreshing change of pace from typical web app development. You can read more about the product here: https://www.swiftnav.com/sites/default/files/piksi_multi_product_summary.pdf Thanks, Buro ================= Swift Navigation is looking for an outstanding software engineer in web infrastructure. You will work with a small team to push the state of the art in satellite navigation technology, making high accuracy positioning ubiquitous and easy to use across a wide variety of industries and applications in unmanned aerial vehicles, robotics, and autonomous transportation. As a member of the infrastructure team, you'll contribute to software services for upcoming networking services as well as internal infrastructure shared broadly by Swift's R&D teams: * Services for Networked Sensors. Service-oriented architecture, scientific modeling services, and distributed message brokers for connected satellite navigation receivers. * Integration Infrastructure. Much of our current work involves rigorously demonstrating that our hardware product works as intended when leaving the lab for a variety of customer scenarios in real-world environments. You'll build and use automation frameworks and assemble instrumentation for hardware-in-the-loop testing, fault injection, and regression testing across these scenarios, as well as data analysis pipelines and metrics monitoring for test units under firmware and manufacturing validation. Candidates should have skills and experience with: - Software engineering in a production environment (commercial web services) - Algorithms, data structures, distributed systems, and relational databases - Haskell, or other typed functional programming languages - Amazon Web Services (AWS) and its related ecosystem (Docker, etc.) for application automation and monitoring - Exceptional problem solving, communication, and collaboration skills. Flexibility and enthusiasm for learning new programming languages, tools, and ideas. Strong candidates will also possess skills in one or more of - Infrastructure engineering for "real-time" sensor networks - Python / NumPy / SciPy / Pandas, R and other analysis/scripting platforms - Version control tools (git), software automation - Open-source development -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Wed Jun 28 15:16:46 2017 From: J.Hage at uu.nl (Jurriaan Hage) Date: Wed, 28 Jun 2017 17:16:46 +0200 Subject: [Haskell-cafe] Any ideas on what this should generate and not generate...? Message-ID: We had a strange phenomenon while debugging a large compiler. This is the smallest example, but we have seen this behavior in our own monad. module TracEx where import Debug.Trace runit :: IO () runit = traceShow "Bla" $ do traceShow "Bloe” runit and this generates Bla Bloe and then it hangs. Nothing else is generated. We are guessing this has to do with optimisations of some kind. And what about runit :: IO () runit = traceShow "Bla" $ do n <- traceShow "Num" print 2 traceShow "Bloe” runit Now we get Bla Num 2 Bloe 2 Bloe 2 … No more Bla and no more Num. Any ideas whether this is a bug or a feature? Jur and Tibor From jaccokrijnen at gmail.com Wed Jun 28 18:37:26 2017 From: jaccokrijnen at gmail.com (Jacco Krijnen) Date: Wed, 28 Jun 2017 19:37:26 +0100 Subject: [Haskell-cafe] Any ideas on what this should generate and not generate...? In-Reply-To: References: Message-ID: Hi, In the first example the traceShows are only called as a side effect of evaluating the IO expression (traceShow "Bla" $ do traceShow "Bloe" runit) which happens only once (runit is a top-level binding). I assume that for the second example GHC lifts (traceShow "Num" print 2) out of the do block and similarly evaluates it only once. The traceShow "Bloe" is not lifted out of there because it's under a lambda. E.g. if you do this instead: runit :: IO () runit = traceShow "Bla" $ do traceShow "Num" (print 2) traceShow "Bloe" runit You get "Bla" "Num" 2 "Bloe" 2 2 2 2 ... Jacco 2017-06-28 16:16 GMT+01:00 Jurriaan Hage : > We had a strange phenomenon while debugging a large compiler. > This is the smallest example, but we have seen this behavior in our own > monad. > > module TracEx where > > import Debug.Trace > > runit :: IO () > runit = traceShow "Bla" $ do > traceShow "Bloe” runit > > > and this generates > Bla > Bloe > > and then it hangs. Nothing else is generated. > We are guessing this has to do with optimisations of some kind. > > And what about > > runit :: IO () > runit = traceShow "Bla" $ do > n <- traceShow "Num" print 2 > traceShow "Bloe” runit > > Now we get > Bla > Num > 2 > Bloe > 2 > Bloe > 2 > … > No more Bla and no more Num. > > Any ideas whether this is a bug or a feature? > > Jur and Tibor > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 toad3k at gmail.com Wed Jun 28 18:48:56 2017 From: toad3k at gmail.com (David McBride) Date: Wed, 28 Jun 2017 14:48:56 -0400 Subject: [Haskell-cafe] Any ideas on what this should generate and not generate...? In-Reply-To: References: Message-ID: http://hackage.haskell.org/package/base-4.9.1.0/docs/Debug-Trace.html#v:traceM My sense is that you should probably be using traceIO rather than the pure trace functions. The pure functions do not sequence with respect to IO and once the expression you are tracing has been fully evaluated, they will never take effect again. On Wed, Jun 28, 2017 at 11:16 AM, Jurriaan Hage wrote: > We had a strange phenomenon while debugging a large compiler. > This is the smallest example, but we have seen this behavior in our own monad. > > module TracEx where > > import Debug.Trace > > runit :: IO () > runit = traceShow "Bla" $ do > traceShow "Bloe” runit > > > and this generates > Bla > Bloe > > and then it hangs. Nothing else is generated. > We are guessing this has to do with optimisations of some kind. > > And what about > > runit :: IO () > runit = traceShow "Bla" $ do > n <- traceShow "Num" print 2 > traceShow "Bloe” runit > > Now we get > Bla > Num > 2 > Bloe > 2 > Bloe > 2 > … > No more Bla and no more Num. > > Any ideas whether this is a bug or a feature? > > Jur and Tibor > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From allbery.b at gmail.com Wed Jun 28 19:05:49 2017 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 28 Jun 2017 15:05:49 -0400 Subject: [Haskell-cafe] Any ideas on what this should generate and not generate...? In-Reply-To: References: Message-ID: On Wed, Jun 28, 2017 at 2:48 PM, David McBride wrote: > http://hackage.haskell.org/package/base-4.9.1.0/docs/ > Debug-Trace.html#v:traceM > > My sense is that you should probably be using traceIO rather than the > pure trace functions. The pure functions do not sequence with respect > to IO and once the expression you are tracing has been fully > evaluated, they will never take effect again. This, and remember that IO is a bit of a trick: the expressions you build are in fact pure, they are *descriptions* of impure computations. Once a pure description produces a description of a low-level, impure I/O action, the *evaluation* is done. *Execution* is separate and not affected (or for that matter effected). (As if we had: data IO a = GetChar | PutChar c | ... except typing that would get 'interesting'.) So things like 'traceShow' are done once in the process of evaluating your IO down to a sequence of low-level actions, and actually performing those actions is distinct from this and done later. -- 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 maydwell at gmail.com Thu Jun 29 08:04:00 2017 From: maydwell at gmail.com (Lyndon Maydwell) Date: Thu, 29 Jun 2017 18:04:00 +1000 Subject: [Haskell-cafe] [ANN] Compose :: Melbourne, 2017, Call for Presentations Extension - Monday, 10th of July Message-ID: Hi All! We're extending the Compose :: Melbourne CFP until Monday, 10th of July. Details follow: (Web version: http://www.composeconference.org/2017-melbourne/cfp/) # Compose :: Melbourne Call for Presentations Compose :: Melbourne - http://www.composeconference.org/ - was closing its call for presentations at the end of the month... BUT, now we are extending the CFP until Monday, 10th of July, 2017! Submit your presentation proposal here: https://easychair.org/conferences/?conf=cmc20170 ## About Compose :: Melbourne Compose :: Melbourne is a functional-programming conference returning for its second year which is focused on developing the community and bringing functional-programming to a wider audience. It is a 2-day event being held in Melbourne, Australia on the 28th and 29th of August 2017 at RMIT University. The first day will feature a single track of presentations followed by a second day of workshops and unconference. Compose :: Melbourne is the sister-conference of the NY based Compose :: Conference. # Important Dates - CFP Extended Until - Monday 10th July, 2017 - Notify Presenters - July 20th, 2017 - Conference Day 1: Presentations - Monday, 28th August, 2017 - Conference Day 2: Unconference - Tuesday, 29th August, 2017 # Talk and Workshop Submission ## Day 1 - Presentations Submit a Presentation Proposal via Easy Chair: https://easychair.org/conferences/?conf=cmc20170 ## Day 2 - Unconference and Workshops Contact us (composemel-admin at googlegroups.com) with your workshop proposals, or talk-ideas. Although we don't require ahead-of-time talk information, if you tell us about your unconference talk, we will promote it! # Submission Guidelines Talk slots will be 30 minutes: 25 minute talk and 5 minutes for questions. Provide sufficient detail in your submission to enable the reviewers to understand your proposal and clearly identify what an attendee will gain from attending your session. You should include the following information in the submission system: - Authors - The details of each of the presenters - Title - Title of the presentation (please keep it brief and specific) - Abstract - A 300-500 word description of your presentation, ideally including... - Description of the content - Keywords - List any keywords that will help the program committee and attendees categorise your presentation. For example: proofs, Haskell, music. Please keep the content of your talk on-topic and do not use this speaking opportunity as a sales pitch. # Feel We want Compose Melbourne to be all about the community. We're aiming to help foster the growth of Functional Programming in Melbourne and unite all interested parties to spark a unified presence and a feeling of camaraderie amongst FP and Theory proponents in this wonderful city! Talks should help inspire and promote this goal. # Audience Functional-Programming and Programming-Language-Theory professionals and enthusiasts. Newcomers, experts, anyone from other disciplines of fields who is interested in what FP is or how it could help them with their work, or simply make life more enjoyable! # Diversity Just like Compose-Conference, we would also like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome *all* (new and established) contributions and encourage you to apply! # Day One ## Keynote Day One will kick-off with a mind-blowing excursion into the realm of function live-coded music artistry by the living legend, Andrew Sorensen! Look him up on YouTube! ## Talks All topics for proposals for presentations are invited, but not limited to explore the following topics: ## New Languages The development of new and emerging Functional Languages, and the toolsets around them. ## Libraries and Tools Exploring the use and development of new and underrepresented tools and libraries. ## Production Systems 2017 continues the trend of many previously undeployed languages and systems breaking through into production. We're looking for war-stories, success-stories and sob-stories! ## Theory Theory is the cutting edge of new functional programming. Show the world what is rising over the horizon. ## Art and Music Exciting and innovative usage of functional programming language in the arts! # Day Two The second day will be dedicated to workshops and unconference. ## Workshops If you wish to run a workshop on the second day of the conference, then please let us know. Alternatively, if there is a workshop that would interest you as an attendee, then please also let us know. Last year, there were 5 workshops, including: * Intro to Haskell * FreeMonad FreeApplicative FreeWorkshop * Writing games for Android in Haskell * Intro to Purescript * Intro to the J language ## Unconference Got something random you want to talk about? The unconference will run the second day. There will be a whiteboard with spaces where anyone can write their name down to speak. There's no need to bring anything but yourself and your ideas and speaking voice. # Sponsors We are seeking sponsors to support us in putting on this conference. If you or your company would like to sponsor us, please get in contact via composemel-admin at googlegroups.com. You can find info on our sponsorship tiers here: https://github.com/composeconference/Compose-Melbourne-2017/wiki/Sponsorship-Tiers -- Compose Conference Melbourne Organising Committee http://www.composeconference.org/ From claude at mathr.co.uk Thu Jun 29 08:48:03 2017 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Thu, 29 Jun 2017 09:48:03 +0100 Subject: [Haskell-cafe] [ann] hp2pretty-0.8 Message-ID: <644e12ae-c71e-5035-7321-c302d90b61b6@mathr.co.uk> Hi all, hp2pretty is a program to graph heap profiles output by Haskell programs compiled by GHC. New features in this 0.8 release: * --sort size|stddev|name and --reverse to change output order * --trace [percent] and --bands [count] to adjust output bands * --pattern to fill with patterns instead of solid colour The last option should help a lot if you want to print without using too much ink. More information and pictures exhbiting the new features: https://mathr.co.uk/blog/2017-06-29_hp2pretty-0.8_released.html There were also minor changes in the 0.7 release (earlier this week): * parsing bugfix (don't use `read` to drop quotes) thanks to Pepe Iborra * don't stroke text (fill is enough) * use HTTPS in the packaging hp2pretty still misses features from hp2ps including: * monochrome output * multipage (separate page for key) * page size options * header size options * (encapsulated) Postscript support (hp2pretty is still SVG-only) Another feature that might be nice is: * choose font(s) from command line, to be consistent across a document Patches welcome, or even just votes for which features would be most useful to you so I can prioritise my efforts next time I feel like hacking on it. Thanks, Claude -- https://mathr.co.uk From sylvain at haskus.fr Thu Jun 29 10:52:23 2017 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 29 Jun 2017 12:52:23 +0200 Subject: [Haskell-cafe] [ANN] haskus-system 0.7 Message-ID: <6473b649-3323-3ed8-b18d-d0698e1ace29@haskus.fr> Hi all, I have released haskus-system 0.7. haskus-system is a Haskell library for system programming on top of the Linux kernel. You can use it to build systems that only use: * the Linux kernel * the haskus-system library * your code This release features a new build tool that automatically downloads, configures and builds Linux, SysLinux, etc. It can also execute your system within QEMU, build ISO images and even create bootable devices. For instance, to test the Demo example from https://github.com/haskus/haskus-system-examples/ with QEMU, you just have to type: > haskus-system-build test --init Demo The full announce with some screenshots and a video: http://hsyl20.fr/home/posts/2017-06-29-announcing-haskussystem-07.html Cheers, Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From raould at gmail.com Thu Jun 29 13:56:12 2017 From: raould at gmail.com (Raoul Duke) Date: Thu, 29 Jun 2017 09:56:12 -0400 Subject: [Haskell-cafe] dsl for atari 2600 vcs? In-Reply-To: References: Message-ID: Along the lines of atom & ivory & tower, has anyone (I haven't turned up any hits online so I guess not) worked on a dsl in haskell for generating racing-the-beam code? Feels like all the book keeping might be something haskell could do, giving a dsl that is more high level than manual mental cycle counting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From taylor at fausak.me Thu Jun 29 15:21:22 2017 From: taylor at fausak.me (Taylor Fausak) Date: Thu, 29 Jun 2017 10:21:22 -0500 Subject: [Haskell-cafe] Issue 61 :: Haskell Weekly Message-ID: <1498749682.1255916.1025419136.2F2905C3@webmail.messagingengine.com> \ Haskell Weekly \/\/ Issue 61 Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on robustness, concision, and correctness. This is a weekly summary of what's going on in its community. ## Featured ## - Haxl: Making concurrency unreasonably easy > Haxl is a big hammer for doing I/O concurrently, testing I/O, and modularity (caching & memoization). - Introduction to Brick > I'm going to give a short introduction to Brick, a Haskell library for building terminal user interfaces. So far I've used brick to implement Conway's Game of Life and a Tetris clone. I'll explain the basics, walk through an example snake application, and then explain some more complicated scenarios. - Simplexhc: An STG to LLVM compiler > STG's lowering to C-- and the decisions taken when implementing it were based in the '90s. That's not to say that the GHC team hasn't done an awesome job keeping it up to date; they have! But, I wonder what a complete rewrite of this lowering would look like. Hence, I'm trying to experiment in this space and see what happens. - Front Row is hiring a senior backend Haskell engineer > Come change how 6.5+ million K-12 US students learn Math, Language Arts, Social Studies and more. Use data, advanced type systems, great product design and deep pedagogy to change lives. - Threading responsibly: `forkIO` considered harmful > In this post I want to argue that threads are also a resource, in the sense that they require management after we've created them. A stray thread will consume memory, CPU cycles, and really whatever resource it might need to execute. - The `Has` type class pattern > The value in this approach is that I don't have to think about what functions to call to collect the images: it's always `images`. In the prior example, I had to think about the how to collect the images each time, and it took brain power better spent elsewhere. - A tale of two brackets > I hope the primary thing you take away from it is a deeper understanding of how monad transformer stacks interact with operations in the base monad, and how monad-control works in general. - `RecordWildCards` and binary parsing > `RecordWildCards` is a GHC extension that makes working with Haskell records more convenient. The extension has been blogged about in a few places already, so this post intends to provide a different motivating example: binary parsing. - On naming things: Library design > I've written a few libraries now and have tried out different naming and exporting conventions. I've developed a bit of a feel for how it is to write and use them, and I'm going to put out my personal preferences and opinions on library design here. - Haskell Bits #6: A guide to mutable references > There are quite a few ways to store mutable data in Haskell. Let's talk about some of them! Specifically, we will focus on mutable containers that store a single value that can be modified by one or more threads at any given time. I'm not going to go into a ton of detail here --- I just want to give an overview. - Interfaces and type classes: Number APIs in C# and Haskell > In C# sometimes I sorely miss something like an `INumber` interface with methods add, subtract, multiply, and others. The lack of this means it is cumbersome to write generic code on numbers. ## Package of the week ## This week's package of the week is data-has, a library that provides a simple extensible product system. ## In brief ## - Announcing haskus-system 0.7 - Defeating evil with data structures - stack2nix first public release - Streaming combinators and extracting flat parallelism - Typing Nix - When competing with C, fudge the benchmark ## Events ## - Berlin Functional Programming Group's first meeting July 1 - Haskell.SG's July meetup July 5 From marty.alain at free.fr Thu Jun 29 19:05:14 2017 From: marty.alain at free.fr (marty.alain) Date: Thu, 29 Jun 2017 21:05:14 +0200 Subject: [Haskell-cafe] on the {lambda way} Message-ID: <14851C92-CCB8-40F9-87C0-3AF4F6E59F4D@free.fr> Dear Haskell-Café mailing list, Please excuse me if the Haskell-Café is not the appropriate place to post this question in but, following the advice of M. Simon Peyton Jones, I would like to know if one of you could tell me his opinion about such a work - http://lambdaway.free.fr/lambdaway/data/lambdatalk_20170615.pdf a PDF file directly printed from this wiki page - http://lambdaway.free.fr/lambdaway/?view=oxford introducing an “iconoclastic” approach detailed in long in this workshop - http://lambdaway.free.fr/ transforming a web markup syntax into a small functional programming language that an eleven years old child could understand: - http://lambdaway.free.fr/lambdaway/?view=teaching Best regards Alain Marty engineer architect -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Fri Jun 30 05:08:44 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 30 Jun 2017 00:08:44 -0500 Subject: [Haskell-cafe] Problem with pipe/Is there a function that "lifts" functions to Producers? Message-ID: Hi all, I have a function from Text -> Text which I want to apply to each line using pipes-text and pipes-group. I'm pretty sure my pipe is not doing what I expect. I'm going back over the pipes tutorial now, but I think I could use some help figuring it out. I have the following (buildable github project: https://github.com/codygman/fixedWidthToDelimited) code: import Data.Monoid import Pipes import qualified Pipes.Text as Text import qualified Pipes.Text.IO as Text import System.IO import Lens.Family import qualified Pipes.Group as Group import qualified Data.Text as T appendAt :: Int -> T.Text -> T.Text -> (T.Text,T.Text) appendAt i appendBS bs = let (first, rest) = T.splitAt i bs in (first <> appendBS <> rest,rest) -- TODO figure out how to test a pipe (I'm sure pipes-text or any other libraries test their pipes) toDelimPipe :: Monad m => [Int] -> Pipe T.Text T.Text m r toDelimPipe offsets = do chunk <- await let text = (fixedWidthLine offsets) chunk if T.null text then (toDelimPipe offsets) else do yield text cat fixedWidthLine :: [Int] -> T.Text -> T.Text fixedWidthLine offsets bs = fst $ go offsets ("" :: T.Text,bs) where go :: [Int] -> (T.Text,T.Text) -> (T.Text,T.Text) go [] x = x go (x:xs) (acc,rest) = let (newAcc,newRest) = T.splitAt x rest in go xs (acc <> (fst $ appendAt x "|" newAcc),newRest) {- got: runEffect $ over Text.lines (Group.maps (>-> toDelimPipe [2,2,2] )) (Text.fromLazy (LT.replicate 2 "x" <> LT.replicate 2 "y" <> LT.replicate 2 "z")) >-> Text.stdout xx|||yyzz Expected: xx|yy|zz| When I use fixedWidthLine alone with the same offsets I get: λ> fixedWidthLine [2,2,2] (T.replicate 2 "x" <> T.replicate 2 "y" <> T.replicate 2 "z") "xx|yy|zz|" I think my pipe is wrong -} -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Fri Jun 30 05:15:53 2017 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 30 Jun 2017 00:15:53 -0500 Subject: [Haskell-cafe] Problem with pipe/Is there a function that "lifts" functions to Producers? In-Reply-To: References: Message-ID: My first problem is that I was assuming each chunk was the entire line. On Fri, Jun 30, 2017 at 12:08 AM, Cody Goodman < codygman.consulting at gmail.com> wrote: > Hi all, > > I have a function from Text -> Text which I want to apply to each line > using pipes-text and pipes-group. > > > I'm pretty sure my pipe is not doing what I expect. I'm going back over > the pipes tutorial now, but I think I could use some help figuring it out. > > I have the following (buildable github project: > https://github.com/codygman/fixedWidthToDelimited) code: > > import Data.Monoid > import Pipes > import qualified Pipes.Text as Text > import qualified Pipes.Text.IO as Text > import System.IO > import Lens.Family > import qualified Pipes.Group as Group > import qualified Data.Text as T > > > > appendAt :: Int -> T.Text -> T.Text -> (T.Text,T.Text) > appendAt i appendBS bs = let (first, rest) = T.splitAt i bs in (first <> > appendBS <> rest,rest) > > -- TODO figure out how to test a pipe (I'm sure pipes-text or any other > libraries test their pipes) > toDelimPipe :: Monad m => [Int] -> Pipe T.Text T.Text m r > toDelimPipe offsets = do > chunk <- await > let text = (fixedWidthLine offsets) chunk > if T.null text > then (toDelimPipe offsets) > else do yield text > cat > > fixedWidthLine :: [Int] -> T.Text -> T.Text > fixedWidthLine offsets bs = fst $ go offsets ("" :: T.Text,bs) > where go :: [Int] -> (T.Text,T.Text) -> (T.Text,T.Text) > go [] x = x > go (x:xs) (acc,rest) = let (newAcc,newRest) = T.splitAt x rest in > go xs (acc <> (fst $ appendAt x "|" newAcc),newRest) > > {- > got: > runEffect $ over Text.lines (Group.maps (>-> toDelimPipe [2,2,2] )) > (Text.fromLazy (LT.replicate 2 "x" <> LT.replicate 2 "y" <> LT.replicate 2 > "z")) >-> Text.stdout > xx|||yyzz > > Expected: > > xx|yy|zz| > > When I use fixedWidthLine alone with the same offsets I get: > > λ> fixedWidthLine [2,2,2] (T.replicate 2 "x" <> T.replicate 2 "y" <> > T.replicate 2 "z") > "xx|yy|zz|" > > I think my pipe is wrong > > -} > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Jun 30 12:26:45 2017 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 30 Jun 2017 13:26:45 +0100 Subject: [Haskell-cafe] Source code location in IO? In-Reply-To: <22B950C955F8AB4196E72698FBD00002D03349D2@UKWPISXMB01B.zone1.scb.net> References: <20160620150356.GB16525@weber> <22B950C955F8AB4196E72698FBD00002D03349D2@UKWPISXMB01B.zone1.scb.net> Message-ID: <20170630122645.GB4530@weber> A year has passed and I have just discovered that you had exactly the same idea two years before me! http://augustss.blogspot.se/2014/04/haskell-error-reporting-with-locations_5.html On Tue, Jun 21, 2016 at 01:45:13AM +0000, Augustsson, Lennart wrote: > It's totally compatible with Haskell semantics, since Haskell does not give any semantics to IO. > Anything can happen when you do IO. But it's still a bit weird. :) > > -----Original Message----- > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Tom Ellis > Sent: 20 June 2016 16:04 > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] Source code location in IO? > > Is it compatible with the semantics of Haskell to have a function > > sourceLocation :: IO String > > which when run returns the source file location at which it is used? For > example, suppose Main.hs is > > module Main where > > main = do > putStrLn =<< sourceLocation > putStrLn "Hello" > putStrLn =<< sourceLocation > > It would print the following when run > > Main.hs:4 > Hello > Main.hs:6 > > and > > module Main where > > main = do > let s = sourceLocation > putStrLn =<< s > putStrLn "Hello" > putStrLn =<< s > > It would print the following when run > > Main.hs:4 > Hello > Main.hs:4 > > If this is not compatible with the semantics of Haskell, why not? I agree > that the two programs must have the same denotation, but is there anything > that requires them to have the same output when run? From trupill at gmail.com Fri Jun 30 14:21:35 2017 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 30 Jun 2017 16:21:35 +0200 Subject: [Haskell-cafe] Domain specific error diagnosis in Haskell, a proposal Message-ID: Dear Haskellers, Some days ago Jurriaan Hage posted a video of our work on adding custom type error diagnosis to GHC. Here is a GHC proposal for incorporating this support in the mainline compiler: https://github.com/ghc-proposals/ghc-proposals/pull/59 Suggestions, criticisms and ideas are welcome. Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From han.joosten.han at gmail.com Fri Jun 30 18:33:29 2017 From: han.joosten.han at gmail.com (Han Joosten) Date: Fri, 30 Jun 2017 20:33:29 +0200 Subject: [Haskell-cafe] Nice clean code example? Message-ID: I'd like to showoff some nice Haskell code to a CTO with no experience with FP. I promised to send him a small piece of Haskell so he could get an idea. The code should be easy to read, without obscure looking operators (so sorry, no lens, arrows stuff like that), optionally even do something interesting. Who has the nicest example laying around? (and yes, I need it by yesterday ;-) ) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Fri Jun 30 19:08:15 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 30 Jun 2017 21:08:15 +0200 Subject: [Haskell-cafe] Nice clean code example? In-Reply-To: References: Message-ID: <20170630190815.rtkr7n3iubtadwap@x60s.casa> On Fri, Jun 30, 2017 at 08:33:29PM +0200, Han Joosten wrote: > I'd like to showoff some nice Haskell code to a CTO with no experience with > FP. I promised to send him a small piece of Haskell so he could get an > idea. The code should be easy to read, without obscure looking operators > (so sorry, no lens, arrows stuff like that), optionally even do something > interesting. > Who has the nicest example laying around? Some ideas: - a wrongly typed piece of code: then show him a) how ghc(i) pinpoints the problem part and is very clear in its demands ("I wanted this, you gave me this") and b) how malleable the type system is. - a declarative graph made with diagrams (with a graphical result displayed) - parsec (even if you go with applicative style, the code is very readable) From ryan.trinkle at gmail.com Fri Jun 30 19:34:55 2017 From: ryan.trinkle at gmail.com (Ryan Trinkle) Date: Fri, 30 Jun 2017 15:34:55 -0400 Subject: [Haskell-cafe] Dynamically linking frameworks on macOS In-Reply-To: References: Message-ID: Ah, interesting; thanks for the info! In that case, I'll just go back to debugging that issue the old fashioned way. Best, Ryan On Tue, Jun 27, 2017 at 10:33 AM, Daniel Peebles wrote: > I don't know about your specific issue with Foundation.framework, but > regarding "Apple doesn't support (and strongly discourages) statically > linked executables[1], so it's not terribly surprising that this doesn't > work." I think you're interpreting it a bit more broadly than intended. > > Apple's point in that tech note is that you shouldn't statically link what > most people think of as libc (called libSystem on macOS). You can > statically link anything else because that's basically just you deciding > how you want to organize your software. The reason for this is that > libSystem is where the kernel syscall wrappers live, and they don't want > you to make syscalls directly because they don't want to commit to a > particular kernel ABI. That's why they don't ship a static libSystem or any > of that crt0.o stuff, but if you have a ton of .a libraries you want to > link into your executable that's fine because it'll still be linking to > libSystem.dylib when it wants to make syscalls. > > The only mainstream project I know that actively ignores this advice is > Go, which has implemented its own syscall wrappers for macOS and as such > occasionally gets weird bugs when Apple makes changes to the kernel ABI. > > > On Fri, Jun 23, 2017 at 11:31 AM, Ryan Trinkle > wrote: > >> Hi everyone, >> >> I'm trying to ensure that beginner-level code that uses reflex-dom can be >> built by simply calling 'ghc myFile.hs', provided that all the necessary >> libraries are available in ghc-pkg. This works on linux, but on macOS, >> it's currently necessary for the user to add '-dynamic' to the command >> line. In particular, without -dynamic, the linker fails to find >> "_OBJC_CLASS_$_NSURL", which is a symbol in the Foundation system >> framework. Apple doesn't support (and strongly discourages) statically >> linked executables[1], so it's not terribly surprising that this doesn't >> work. >> >> Is there anything I can do to avoid the need for -dynamic here? >> >> >> Thanks, >> Ryan >> >> [1] https://developer.apple.com/library/content/qa/qa1118/_index.html >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bneijt at gmail.com Fri Jun 30 20:46:55 2017 From: bneijt at gmail.com (Bram Neijt) Date: Fri, 30 Jun 2017 22:46:55 +0200 Subject: [Haskell-cafe] Nice clean code example? In-Reply-To: <20170630190815.rtkr7n3iubtadwap@x60s.casa> References: <20170630190815.rtkr7n3iubtadwap@x60s.casa> Message-ID: I have no idea what you consider clean. I have some ugly code that shows off some Haskell features: https://github.com/BigDataRepublic/hanon/blob/master/src/Mapper.hs I think it shows off: - Introducing types to create a language - Explicit IO, allowing for clear contract exposure to the user of the library? - defaultHighlighters is a subset of defaultInputPaths through a simple map allowing for easily exposing constrained subsets of code (not data)?? if I would force myself to continue, the number of question marks would just increase, so I'll stop here. Best of luck! Bram On Fri, Jun 30, 2017 at 9:08 PM, Francesco Ariis wrote: > On Fri, Jun 30, 2017 at 08:33:29PM +0200, Han Joosten wrote: >> I'd like to showoff some nice Haskell code to a CTO with no experience with >> FP. I promised to send him a small piece of Haskell so he could get an >> idea. The code should be easy to read, without obscure looking operators >> (so sorry, no lens, arrows stuff like that), optionally even do something >> interesting. >> Who has the nicest example laying around? > > Some ideas: > > - a wrongly typed piece of code: then show him a) how ghc(i) pinpoints > the problem part and is very clear in its demands ("I wanted this, you > gave me this") and b) how malleable the type system is. > > - a declarative graph made with diagrams (with a graphical result > displayed) > > - parsec (even if you go with applicative style, the code is very readable) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jeffbrown.the at gmail.com Fri Jun 30 21:39:22 2017 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Fri, 30 Jun 2017 14:39:22 -0700 Subject: [Haskell-cafe] Nice clean code example? In-Reply-To: References: <20170630190815.rtkr7n3iubtadwap@x60s.casa> Message-ID: Jake Brownson wrote a game of tic-tac-toe in 160 lines[1] that I thought was beautiful. I forked it to make it a little more readable[2]. [1] https://gist.github.com/jbrownson/712ddafd1cb3388cd827 [2] https://github.com/JeffreyBenjaminBrown/play/blob/master/_not_music/jbrownson_tictactoe/it_modified.hs On Fri, Jun 30, 2017 at 1:46 PM, Bram Neijt wrote: > I have no idea what you consider clean. I have some ugly code that > shows off some Haskell features: > > https://github.com/BigDataRepublic/hanon/blob/master/src/Mapper.hs > > I think it shows off: > - Introducing types to create a language > - Explicit IO, allowing for clear contract exposure to the user of the > library? > - defaultHighlighters is a subset of defaultInputPaths through a > simple map allowing for easily exposing constrained subsets of code > (not data)?? > > if I would force myself to continue, the number of question marks > would just increase, so I'll stop here. > > Best of luck! > > Bram > > > > On Fri, Jun 30, 2017 at 9:08 PM, Francesco Ariis wrote: > > On Fri, Jun 30, 2017 at 08:33:29PM +0200, Han Joosten wrote: > >> I'd like to showoff some nice Haskell code to a CTO with no experience > with > >> FP. I promised to send him a small piece of Haskell so he could get an > >> idea. The code should be easy to read, without obscure looking operators > >> (so sorry, no lens, arrows stuff like that), optionally even do > something > >> interesting. > >> Who has the nicest example laying around? > > > > Some ideas: > > > > - a wrongly typed piece of code: then show him a) how ghc(i) pinpoints > > the problem part and is very clear in its demands ("I wanted this, you > > gave me this") and b) how malleable the type system is. > > > > - a declarative graph made with diagrams (with a graphical result > > displayed) > > > > - parsec (even if you go with applicative style, the code is very > readable) > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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. > -- Jeff Brown | Jeffrey Benjamin Brown Website | Facebook | LinkedIn (spammy, so I often miss messages here) | Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Fri Jun 30 22:02:20 2017 From: lambda.fairy at gmail.com (Chris Wong) Date: Sat, 1 Jul 2017 10:02:20 +1200 Subject: [Haskell-cafe] Nice clean code example? In-Reply-To: References: Message-ID: How about Hackagebot? https://github.com/lfairy/hircine/blob/master/brigitte/Hackagebot.hs https://github.com/lfairy/hircine/blob/master/brigitte/Utils.hs It involves a lot of concurrency, networking, and data structure manipulation -- all areas Haskell excels in. It avoids using advanced features as well (except maybe pattern synonyms, but those aren't visible in the code that uses them) Here are some numbers: its sibling Cargobot boasts 3+ months continuous uptime, with memory usage never going beyond 12 MB. It has never crashed. I expect Hackagebot to have similar metrics. On Jul 1, 2017 06:34, "Han Joosten" wrote: I'd like to showoff some nice Haskell code to a CTO with no experience with FP. I promised to send him a small piece of Haskell so he could get an idea. The code should be easy to read, without obscure looking operators (so sorry, no lens, arrows stuff like that), optionally even do something interesting. Who has the nicest example laying around? (and yes, I need it by yesterday ;-) ) Thanks! _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: