From anton.kholomiov at gmail.com Tue Feb 1 15:07:07 2022 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Tue, 1 Feb 2022 18:07:07 +0300 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP Message-ID: Hi! I'm trying to write a paper for ICFP, This is my first paper of this kind. Can you please help me to choose the right category for it? The paper is about a novel technique of implementation of FRP. I've studied the Haskell FRP zoo and I can confirm that it's novel. In my opinion it's very elegant and simple, but of course I'm biased :) So far so good. Can you please help me to choose the right category for it? Is it a normal research paper or is it a functional pearl? So the FRP is an old technique, but I propose a novel variant of implementation which I hope is easy to study even in normal class rooms and does not contain unsafePerform tricks. Cheers, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Tue Feb 1 15:56:54 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 1 Feb 2022 15:56:54 +0000 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: References: Message-ID: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> This is a good question, and there's no easy answer. My first impression is that a new implementation of an existing idea probably would not qualify as a big enough contribution to be accepted at ICFP -- but I don't know FRP well enough to really know (and I certainly don't know how impactful your new approach is). It's plausible that a new implementation of an existing idea would be accepted, but it would have to be pretty thought-provoking. A good rule-of-thumb is: if a reader had no particular interest in using your implementation or writing their own FRP implementation, is there something for them to learn? That is, does your approach generalize to non-FRP tasks? Does it use a feature of Haskell or of a lazy programming language or of a functional programming language in a new, surprising way? Does your approach to analyzing why your implementation is better than others offer insight? If the answers to these (or similar) questions is "yes", then perhaps a research paper would work. On the other hand, a key attribute of a functional pearl is its elegance and beauty. Does your approach take a knot of complication in other FRP implementations and make it go away by construction? Is your approach guaranteed faster by some aspect of its design? Would a reader (who doesn't know about FRP implementations) read what you've written and smile at the ingenuity of it all? Positive answers to these types of question suggest that a functional pearl is best. Sadly, there are many neat ideas that fit neither of these molds -- implementation-oriented work often doesn't. And, if you don't fit the mold of the category you're writing for, your paper may well get rejected, even if it's a good contribution. I don't have a solution here; I think this is a weakness of the current publication model. I hope this advice is helpful! Richard > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov wrote: > > Hi! > > I'm trying to write a paper for ICFP, This is my first paper of this kind. > Can you please help me to choose the right category for it? > > The paper is about a novel technique of implementation of FRP. > I've studied the Haskell FRP zoo and I can confirm that it's novel. > In my opinion it's very elegant and simple, but of course I'm biased :) > > So far so good. Can you please help me to choose the right category for it? > Is it a normal research paper or is it a functional pearl? > > So the FRP is an old technique, but I propose a novel variant of implementation > which I hope is easy to study even in normal class rooms and does not contain > unsafePerform tricks. > > Cheers, > Anton > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 anton.kholomiov at gmail.com Tue Feb 1 18:01:39 2022 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Tue, 1 Feb 2022 21:01:39 +0300 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> References: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> Message-ID: Thanks for the answer Richard! For now I have some guide points and questions to think about. I did bindings to gloss and brick to elaborate the ideas, and it seems to be fun to use. Even if it will get rejected I'll just release it for others. вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg : > This is a good question, and there's no easy answer. My first impression > is that a new implementation of an existing idea probably would not qualify > as a big enough contribution to be accepted at ICFP -- but I don't know FRP > well enough to really know (and I certainly don't know how impactful your > new approach is). It's plausible that a new implementation of an existing > idea would be accepted, but it would have to be pretty thought-provoking. A > good rule-of-thumb is: if a reader had no particular interest in using your > implementation or writing their own FRP implementation, is there something > for them to learn? That is, does your approach generalize to non-FRP tasks? > Does it use a feature of Haskell or of a lazy programming language or of a > functional programming language in a new, surprising way? Does your > approach to analyzing why your implementation is better than others offer > insight? If the answers to these (or similar) questions is "yes", then > perhaps a research paper would work. > > On the other hand, a key attribute of a functional pearl is its elegance > and beauty. Does your approach take a knot of complication in other FRP > implementations and make it go away by construction? Is your approach > guaranteed faster by some aspect of its design? Would a reader (who doesn't > know about FRP implementations) read what you've written and smile at the > ingenuity of it all? Positive answers to these types of question suggest > that a functional pearl is best. > > Sadly, there are many neat ideas that fit neither of these molds -- > implementation-oriented work often doesn't. And, if you don't fit the mold > of the category you're writing for, your paper may well get rejected, even > if it's a good contribution. I don't have a solution here; I think this is > a weakness of the current publication model. > > I hope this advice is helpful! > Richard > > > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov > wrote: > > > > Hi! > > > > I'm trying to write a paper for ICFP, This is my first paper of this > kind. > > Can you please help me to choose the right category for it? > > > > The paper is about a novel technique of implementation of FRP. > > I've studied the Haskell FRP zoo and I can confirm that it's novel. > > In my opinion it's very elegant and simple, but of course I'm biased :) > > > > So far so good. Can you please help me to choose the right category for > it? > > Is it a normal research paper or is it a functional pearl? > > > > So the FRP is an old technique, but I propose a novel variant of > implementation > > which I hope is easy to study even in normal class rooms and does not > contain > > unsafePerform tricks. > > > > Cheers, > > Anton > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Tue Feb 1 18:10:55 2022 From: ollie at ocharles.org.uk (Oliver Charles) Date: Tue, 01 Feb 2022 18:10:55 +0000 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: References: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> Message-ID: <6fd6e38c-de83-48c6-a162-7d81f16c4658@www.fastmail.com> At the very least, please do release it! I would be very interested to see what you've got :) Ollie On Tue, 1 Feb 2022, at 6:01 PM, Anton Kholomiov wrote: > Thanks for the answer Richard! > For now I have some guide points and questions to think about. > > I did bindings to gloss and brick to elaborate the ideas, and it seems to be fun to use. > Even if it will get rejected I'll just release it for others. > > вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg : >> This is a good question, and there's no easy answer. My first impression is that a new implementation of an existing idea probably would not qualify as a big enough contribution to be accepted at ICFP -- but I don't know FRP well enough to really know (and I certainly don't know how impactful your new approach is). It's plausible that a new implementation of an existing idea would be accepted, but it would have to be pretty thought-provoking. A good rule-of-thumb is: if a reader had no particular interest in using your implementation or writing their own FRP implementation, is there something for them to learn? That is, does your approach generalize to non-FRP tasks? Does it use a feature of Haskell or of a lazy programming language or of a functional programming language in a new, surprising way? Does your approach to analyzing why your implementation is better than others offer insight? If the answers to these (or similar) questions is "yes", then perhaps a research paper would work. >> >> On the other hand, a key attribute of a functional pearl is its elegance and beauty. Does your approach take a knot of complication in other FRP implementations and make it go away by construction? Is your approach guaranteed faster by some aspect of its design? Would a reader (who doesn't know about FRP implementations) read what you've written and smile at the ingenuity of it all? Positive answers to these types of question suggest that a functional pearl is best. >> >> Sadly, there are many neat ideas that fit neither of these molds -- implementation-oriented work often doesn't. And, if you don't fit the mold of the category you're writing for, your paper may well get rejected, even if it's a good contribution. I don't have a solution here; I think this is a weakness of the current publication model. >> >> I hope this advice is helpful! >> Richard >> >> > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov wrote: >> > >> > Hi! >> > >> > I'm trying to write a paper for ICFP, This is my first paper of this kind. >> > Can you please help me to choose the right category for it? >> > >> > The paper is about a novel technique of implementation of FRP. >> > I've studied the Haskell FRP zoo and I can confirm that it's novel. >> > In my opinion it's very elegant and simple, but of course I'm biased :) >> > >> > So far so good. Can you please help me to choose the right category for it? >> > Is it a normal research paper or is it a functional pearl? >> > >> > So the FRP is an old technique, but I propose a novel variant of implementation >> > which I hope is easy to study even in normal class rooms and does not contain >> > unsafePerform tricks. >> > >> > Cheers, >> > Anton >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view 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 amindfv at mailbox.org Tue Feb 1 18:35:57 2022 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Tue, 1 Feb 2022 10:35:57 -0800 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: References: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> Message-ID: Hi Anton, Based on your description, this sounds like it could possibly be a good fit for FARM (https://icfp20.sigplan.org/series/farm, https://functional-art.org), which is co-located with ICFP. I've seen a few novel FRP systems presented there (and a few years back presented one myself). Tom On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote: > Thanks for the answer Richard! > For now I have some guide points and questions to think about. > > I did bindings to gloss and brick to elaborate the ideas, and it seems to > be fun to use. > Even if it will get rejected I'll just release it for others. > > вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg : > > > This is a good question, and there's no easy answer. My first impression > > is that a new implementation of an existing idea probably would not qualify > > as a big enough contribution to be accepted at ICFP -- but I don't know FRP > > well enough to really know (and I certainly don't know how impactful your > > new approach is). It's plausible that a new implementation of an existing > > idea would be accepted, but it would have to be pretty thought-provoking. A > > good rule-of-thumb is: if a reader had no particular interest in using your > > implementation or writing their own FRP implementation, is there something > > for them to learn? That is, does your approach generalize to non-FRP tasks? > > Does it use a feature of Haskell or of a lazy programming language or of a > > functional programming language in a new, surprising way? Does your > > approach to analyzing why your implementation is better than others offer > > insight? If the answers to these (or similar) questions is "yes", then > > perhaps a research paper would work. > > > > On the other hand, a key attribute of a functional pearl is its elegance > > and beauty. Does your approach take a knot of complication in other FRP > > implementations and make it go away by construction? Is your approach > > guaranteed faster by some aspect of its design? Would a reader (who doesn't > > know about FRP implementations) read what you've written and smile at the > > ingenuity of it all? Positive answers to these types of question suggest > > that a functional pearl is best. > > > > Sadly, there are many neat ideas that fit neither of these molds -- > > implementation-oriented work often doesn't. And, if you don't fit the mold > > of the category you're writing for, your paper may well get rejected, even > > if it's a good contribution. I don't have a solution here; I think this is > > a weakness of the current publication model. > > > > I hope this advice is helpful! > > Richard > > > > > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov > > wrote: > > > > > > Hi! > > > > > > I'm trying to write a paper for ICFP, This is my first paper of this > > kind. > > > Can you please help me to choose the right category for it? > > > > > > The paper is about a novel technique of implementation of FRP. > > > I've studied the Haskell FRP zoo and I can confirm that it's novel. > > > In my opinion it's very elegant and simple, but of course I'm biased :) > > > > > > So far so good. Can you please help me to choose the right category for > > it? > > > Is it a normal research paper or is it a functional pearl? > > > > > > So the FRP is an old technique, but I propose a novel variant of > > implementation > > > which I hope is easy to study even in normal class rooms and does not > > contain > > > unsafePerform tricks. > > > > > > Cheers, > > > Anton > > > _______________________________________________ > > > Haskell-Cafe mailing list > > > To (un)subscribe, modify options or view 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 ivanperezdominguez at gmail.com Tue Feb 1 19:20:30 2022 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 1 Feb 2022 20:20:30 +0100 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: References: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> Message-ID: Depending on what it is, it may be a good fit. Feel free to send details (publicly, privately). I have presented several papers on novel implementations and extensions/uses of FRP, at the Haskell Symposium and ICFP, some built around very simple concepts. >From https://github.com/ivanperez-keera/dunai/#reading - Hλ Sym: Functional Reactive Programming, Refactored (official ACM page ) (mirror ) - ICFP Pearl: Fault Tolerant Functional Reactive Programming - Hλ Sym: Rhine: FRP with type-level clocks - Hλ Sym: Back to the Future: time travel inIn case it helps: FRP (mirror ) - ICFP: Testing and Debugging Functional Reactive Programming Sometimes, what you lack in theoretical contribution you can make up with use cases or real-world use. There's also REBLS, co-located with OOPSLA. I'd love to see it your solution. Many I find in the FRP zoo can be reduced to an MSF with a specific monad or extended in some way. There was a paper at REBLS 2019 (?) on async FRP that could be expressed as an MSF on the continuation monad. That possibility, if it applies, should be encouraging not discouraging. The FRP land is overpopulated. If you can build your solution as an extension to or specialization of an existing one, it makes using and comparing them much easier. As a frequent reviewer in FP/FM conferences, I'd be more likely to accept a solution expressed that way. Ivan On Tue, 1 Feb 2022 at 19:38, amindfv--- via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hi Anton, > > Based on your description, this sounds like it could possibly be a good > fit for FARM (https://icfp20.sigplan.org/series/farm, > https://functional-art.org), which is co-located with ICFP. I've seen a > few novel FRP systems presented there (and a few years back presented one > myself). > > Tom > > > On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote: > > Thanks for the answer Richard! > > For now I have some guide points and questions to think about. > > > > I did bindings to gloss and brick to elaborate the ideas, and it seems to > > be fun to use. > > Even if it will get rejected I'll just release it for others. > > > > вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg : > > > > > This is a good question, and there's no easy answer. My first > impression > > > is that a new implementation of an existing idea probably would not > qualify > > > as a big enough contribution to be accepted at ICFP -- but I don't > know FRP > > > well enough to really know (and I certainly don't know how impactful > your > > > new approach is). It's plausible that a new implementation of an > existing > > > idea would be accepted, but it would have to be pretty > thought-provoking. A > > > good rule-of-thumb is: if a reader had no particular interest in using > your > > > implementation or writing their own FRP implementation, is there > something > > > for them to learn? That is, does your approach generalize to non-FRP > tasks? > > > Does it use a feature of Haskell or of a lazy programming language or > of a > > > functional programming language in a new, surprising way? Does your > > > approach to analyzing why your implementation is better than others > offer > > > insight? If the answers to these (or similar) questions is "yes", then > > > perhaps a research paper would work. > > > > > > On the other hand, a key attribute of a functional pearl is its > elegance > > > and beauty. Does your approach take a knot of complication in other FRP > > > implementations and make it go away by construction? Is your approach > > > guaranteed faster by some aspect of its design? Would a reader (who > doesn't > > > know about FRP implementations) read what you've written and smile at > the > > > ingenuity of it all? Positive answers to these types of question > suggest > > > that a functional pearl is best. > > > > > > Sadly, there are many neat ideas that fit neither of these molds -- > > > implementation-oriented work often doesn't. And, if you don't fit the > mold > > > of the category you're writing for, your paper may well get rejected, > even > > > if it's a good contribution. I don't have a solution here; I think > this is > > > a weakness of the current publication model. > > > > > > I hope this advice is helpful! > > > Richard > > > > > > > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov < > anton.kholomiov at gmail.com> > > > wrote: > > > > > > > > Hi! > > > > > > > > I'm trying to write a paper for ICFP, This is my first paper of this > > > kind. > > > > Can you please help me to choose the right category for it? > > > > > > > > The paper is about a novel technique of implementation of FRP. > > > > I've studied the Haskell FRP zoo and I can confirm that it's novel. > > > > In my opinion it's very elegant and simple, but of course I'm biased > :) > > > > > > > > So far so good. Can you please help me to choose the right category > for > > > it? > > > > Is it a normal research paper or is it a functional pearl? > > > > > > > > So the FRP is an old technique, but I propose a novel variant of > > > implementation > > > > which I hope is easy to study even in normal class rooms and does not > > > contain > > > > unsafePerform tricks. > > > > > > > > Cheers, > > > > Anton > > > > _______________________________________________ > > > > Haskell-Cafe mailing list > > > > To (un)subscribe, modify options or view archives go to: > > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > Only members subscribed via the mailman list are allowed to post. > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.kholomiov at gmail.com Wed Feb 2 07:28:30 2022 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Wed, 2 Feb 2022 10:28:30 +0300 Subject: [Haskell-cafe] Asking for advice on category for a paper for ICFP In-Reply-To: References: <010f017eb600d3f2-0769f061-1907-41dd-b453-d6f3a2477638-000000@us-east-2.amazonses.com> Message-ID: Thanks alot for comments and encouragement! @Ivan I will study your papers, thanks for the links, it can be a good example as you also have mentioned the categories in which papers were published @Ollie yeah, I plan to release after I submit the paper and get feedback from the reviewers, I guess it's going to be in the March @Tom Good to know I can consider that, I've also did a talk on the farm in 2019 on my musical library вт, 1 февр. 2022 г. в 22:21, Ivan Perez : > Depending on what it is, it may be a good fit. Feel free to send details > (publicly, privately). > > I have presented several papers on novel implementations and > extensions/uses of FRP, at the Haskell Symposium and ICFP, some built > around very simple concepts. > > From https://github.com/ivanperez-keera/dunai/#reading > > - Hλ Sym: Functional Reactive Programming, Refactored > (official ACM page > ) (mirror > ) > > > - > > ICFP Pearl: Fault Tolerant Functional Reactive Programming > > - > > Hλ Sym: Rhine: FRP with type-level clocks > > - > > Hλ Sym: Back to the Future: time travel inIn case it helps: FRP > (mirror > ) > - > > ICFP: Testing and Debugging Functional Reactive Programming > > > Sometimes, what you lack in theoretical contribution you can make up with > use cases or real-world use. > > There's also REBLS, co-located with OOPSLA. > > I'd love to see it your solution. Many I find in the FRP zoo can be > reduced to an MSF with a specific monad or extended in some way. There was > a paper at REBLS 2019 (?) on async FRP that could be expressed as an MSF on > the continuation monad. > > That possibility, if it applies, should be encouraging not discouraging. > The FRP land is overpopulated. If you can build your solution as an > extension to or specialization of an existing one, it makes using and > comparing them much easier. As a frequent reviewer in FP/FM conferences, > I'd be more likely to accept a solution expressed that way. > > Ivan > > On Tue, 1 Feb 2022 at 19:38, amindfv--- via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> Hi Anton, >> >> Based on your description, this sounds like it could possibly be a good >> fit for FARM (https://icfp20.sigplan.org/series/farm, >> https://functional-art.org), which is co-located with ICFP. I've seen a >> few novel FRP systems presented there (and a few years back presented one >> myself). >> >> Tom >> >> >> On Tue, Feb 01, 2022 at 09:01:39PM +0300, Anton Kholomiov wrote: >> > Thanks for the answer Richard! >> > For now I have some guide points and questions to think about. >> > >> > I did bindings to gloss and brick to elaborate the ideas, and it seems >> to >> > be fun to use. >> > Even if it will get rejected I'll just release it for others. >> > >> > вт, 1 февр. 2022 г. в 18:56, Richard Eisenberg : >> > >> > > This is a good question, and there's no easy answer. My first >> impression >> > > is that a new implementation of an existing idea probably would not >> qualify >> > > as a big enough contribution to be accepted at ICFP -- but I don't >> know FRP >> > > well enough to really know (and I certainly don't know how impactful >> your >> > > new approach is). It's plausible that a new implementation of an >> existing >> > > idea would be accepted, but it would have to be pretty >> thought-provoking. A >> > > good rule-of-thumb is: if a reader had no particular interest in >> using your >> > > implementation or writing their own FRP implementation, is there >> something >> > > for them to learn? That is, does your approach generalize to non-FRP >> tasks? >> > > Does it use a feature of Haskell or of a lazy programming language or >> of a >> > > functional programming language in a new, surprising way? Does your >> > > approach to analyzing why your implementation is better than others >> offer >> > > insight? If the answers to these (or similar) questions is "yes", then >> > > perhaps a research paper would work. >> > > >> > > On the other hand, a key attribute of a functional pearl is its >> elegance >> > > and beauty. Does your approach take a knot of complication in other >> FRP >> > > implementations and make it go away by construction? Is your approach >> > > guaranteed faster by some aspect of its design? Would a reader (who >> doesn't >> > > know about FRP implementations) read what you've written and smile at >> the >> > > ingenuity of it all? Positive answers to these types of question >> suggest >> > > that a functional pearl is best. >> > > >> > > Sadly, there are many neat ideas that fit neither of these molds -- >> > > implementation-oriented work often doesn't. And, if you don't fit the >> mold >> > > of the category you're writing for, your paper may well get rejected, >> even >> > > if it's a good contribution. I don't have a solution here; I think >> this is >> > > a weakness of the current publication model. >> > > >> > > I hope this advice is helpful! >> > > Richard >> > > >> > > > On Feb 1, 2022, at 10:07 AM, Anton Kholomiov < >> anton.kholomiov at gmail.com> >> > > wrote: >> > > > >> > > > Hi! >> > > > >> > > > I'm trying to write a paper for ICFP, This is my first paper of this >> > > kind. >> > > > Can you please help me to choose the right category for it? >> > > > >> > > > The paper is about a novel technique of implementation of FRP. >> > > > I've studied the Haskell FRP zoo and I can confirm that it's novel. >> > > > In my opinion it's very elegant and simple, but of course I'm >> biased :) >> > > > >> > > > So far so good. Can you please help me to choose the right category >> for >> > > it? >> > > > Is it a normal research paper or is it a functional pearl? >> > > > >> > > > So the FRP is an old technique, but I propose a novel variant of >> > > implementation >> > > > which I hope is easy to study even in normal class rooms and does >> not >> > > contain >> > > > unsafePerform tricks. >> > > > >> > > > Cheers, >> > > > Anton >> > > > _______________________________________________ >> > > > Haskell-Cafe mailing list >> > > > To (un)subscribe, modify options or view archives go to: >> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > Only members subscribed via the mailman list are allowed to post. >> > > >> > > >> >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuebinm at disroot.org Thu Feb 3 17:32:01 2022 From: stuebinm at disroot.org (stuebinm) Date: Thu, 3 Feb 2022 18:32:01 +0100 Subject: [Haskell-cafe] current status of cloud haskell? Message-ID: <49548d08-7a2a-ba59-36d9-00fc191fbd70@disroot.org> Hi all! I've been meaning to do more with concurrent (and parallel) haskell, and having looked around a bit on hackage (and being a fan of Erlang's OTP) the cloud haskell packages seem like a dream come true. But only at first glance — the last release of distributed-process [1], which looks to be the main library, was in 2018, and many of the other packages are older. The "recent news" section of the website [2] even has its last entry from 2016! So I'd be assuming that the project has been abandoned, yet on github [3] it looks to still be (comparatively) alive and well, with activity just a few months ago. So what's the current status there? Is anyone here using it productively, or involved in its development / knows if or when to expect a new release? thanks! ~stuebinm [1] https://hackage.haskell.org/package/distributed-process [2] http://haskell-distributed.github.io/ [3] https://github.com/haskell-distributed/distributed-process From sergueyz at gmail.com Thu Feb 3 20:03:09 2022 From: sergueyz at gmail.com (Serguey Zefirov) Date: Thu, 3 Feb 2022 23:03:09 +0300 Subject: [Haskell-cafe] current status of cloud haskell? In-Reply-To: <49548d08-7a2a-ba59-36d9-00fc191fbd70@disroot.org> References: <49548d08-7a2a-ba59-36d9-00fc191fbd70@disroot.org> Message-ID: I can't help myself, I have to try to talk you out of the use of distributed-process. ;) It is hard to use, requiring at least some understanding of Erlang's process model and some implementation details of distributed-process itself. It also uses EDSL for pattern-matching of messages, and that makes you lose compiler guarantees like pattern match completeness. If I may offer an alternative, please, consider DSTM: https://hackage.haskell.org/package/DSTM My experience with distributed systems (some HPC, a couple of blockchains and a couple of databases) shows that what is usually needed is a distributed transactional memory. One usually needs atomic and consistent orchestration of computations in a distributed setting, which is most easier to obtain through, well, distributed software transactional memory. It also contains an implementation of a simple game as an example. ;) чт, 3 февр. 2022 г. в 20:38, stuebinm via Haskell-Cafe < haskell-cafe at haskell.org>: > Hi all! > > I've been meaning to do more with concurrent (and parallel) haskell, and > having looked around a bit on hackage (and being a fan of Erlang's OTP) > the cloud haskell packages seem like a dream come true. But only at > first glance — the last release of distributed-process [1], which looks > to be the main library, was in 2018, and many of the other packages are > older. The "recent news" section of the website [2] even has its last > entry from 2016! > > So I'd be assuming that the project has been abandoned, yet on github > [3] it looks to still be (comparatively) alive and well, with activity > just a few months ago. > > So what's the current status there? Is anyone here using it > productively, or involved in its development / knows if or when to > expect a new release? > > thanks! > > ~stuebinm > > > [1] https://hackage.haskell.org/package/distributed-process > [2] http://haskell-distributed.github.io/ > [3] https://github.com/haskell-distributed/distributed-process > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 agentm at themactionfaction.com Thu Feb 3 20:49:00 2022 From: agentm at themactionfaction.com (A.M.) Date: Thu, 3 Feb 2022 15:49:00 -0500 Subject: [Haskell-cafe] current status of cloud haskell? In-Reply-To: <49548d08-7a2a-ba59-36d9-00fc191fbd70@disroot.org> References: <49548d08-7a2a-ba59-36d9-00fc191fbd70@disroot.org> Message-ID: <13dbbe6d-c10c-cbc2-4cdb-b33447fbc232@themactionfaction.com> On 2/3/22 12:32, stuebinm via Haskell-Cafe wrote: > Hi all! > > I've been meaning to do more with concurrent (and parallel) haskell, and > having looked around a bit on hackage (and being a fan of Erlang's OTP) > the cloud haskell packages seem like a dream come true. But only at > first glance — the last release of distributed-process [1], which looks > to be the main library, was in 2018, and many of the other packages are > older. The "recent news" section of the website [2] even has its last > entry from 2016! > > So I'd be assuming that the project has been abandoned, yet on github > [3] it looks to still be (comparatively) alive and well, with activity > just a few months ago. > > So what's the current status there? Is anyone here using it > productively, or involved in its development / knows if or when to > expect a new release? Hi stuebinm, We were using distributed-process within our own project until it was too much effort to keep up with newer GHC releases and packages. We were able to replace distributed-process and friends with our own much more lightweight curryer-rpc library[1] for the simple use-case of TCP client-server interaction. Cheers, M 1. https://hackage.haskell.org/package/curryer-rpc -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From will.yager at gmail.com Thu Feb 3 22:10:03 2022 From: will.yager at gmail.com (Will Yager) Date: Thu, 3 Feb 2022 17:10:03 -0500 Subject: [Haskell-cafe] current status of cloud haskell? In-Reply-To: <13dbbe6d-c10c-cbc2-4cdb-b33447fbc232@themactionfaction.com> References: <13dbbe6d-c10c-cbc2-4cdb-b33447fbc232@themactionfaction.com> Message-ID: I used distributed-process 5 or 6 years ago when I was in uni for a distributed systems class. It was pretty nice, but I have no idea about its current maintenance. I wrote a blog post at the time with some thoughts on design patterns etc. http://yager.io/Distributed/Distributed.html > On Feb 3, 2022, at 15:54, A.M. wrote: > > On 2/3/22 12:32, stuebinm via Haskell-Cafe wrote: >> Hi all! >> I've been meaning to do more with concurrent (and parallel) haskell, and having looked around a bit on hackage (and being a fan of Erlang's OTP) the cloud haskell packages seem like a dream come true. But only at first glance — the last release of distributed-process [1], which looks to be the main library, was in 2018, and many of the other packages are older. The "recent news" section of the website [2] even has its last entry from 2016! >> So I'd be assuming that the project has been abandoned, yet on github [3] it looks to still be (comparatively) alive and well, with activity just a few months ago. >> So what's the current status there? Is anyone here using it productively, or involved in its development / knows if or when to expect a new release? > > Hi stuebinm, > > We were using distributed-process within our own project until it was too much effort to keep up with newer GHC releases and packages. > > We were able to replace distributed-process and friends with our own much more lightweight curryer-rpc library[1] for the simple use-case of TCP client-server interaction. > > Cheers, > M > > > 1. https://hackage.haskell.org/package/curryer-rpc > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/octet-stream Size: 840 bytes Desc: not available URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Fri Feb 4 14:09:41 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Fri, 4 Feb 2022 15:09:41 +0100 (CET) Subject: [Haskell-cafe] optparse-applicative with attoparsec parser Message-ID: <30404406.15581346.1643983781075.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I Try to write a parser for this command line binoculars-ng --debug process data/test/config_sixs_ruche_flymedv_3.ini 698-734 735-736 But I have this problem Invalid argument `735-736' The parser used for this is this one processOptions :: Parser Options processOptions = Process <$> optional config <*> optional (argument (eitherReader (parseOnly configRangeP . pack)) (metavar "RANGE")) it use the configRangeP attoparser parser whcih knows how to deal with the string "698-734 735-736" configRangeP :: Parser ConfigRange configRangeP = ConfigRange <$> (inputRangeP `sepBy` many (satisfy isSep)) where isSep :: Char -> Bool isSep c = c == ' ' || c == ',' the result should be this one Just (ConfigRange [InputRangeFromTo 698 734,InputRangeFromTo 735 736]) so my question how should I fix my processOptions fucntion in order to deal with this problem. thanks for considering Frederic From lemming at henning-thielemann.de Fri Feb 4 16:34:30 2022 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 4 Feb 2022 17:34:30 +0100 (CET) Subject: [Haskell-cafe] optparse-applicative with attoparsec parser In-Reply-To: <30404406.15581346.1643983781075.JavaMail.zimbra@synchrotron-soleil.fr> References: <30404406.15581346.1643983781075.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <3ab6ead-d014-a191-583-d9b0405bed87@henning-thielemann.de> On Fri, 4 Feb 2022, PICCA Frederic-Emmanuel wrote: > I Try to write a parser for this command line > > binoculars-ng --debug process data/test/config_sixs_ruche_flymedv_3.ini 698-734 735-736 > > But I have this problem > > Invalid argument `735-736' > > The parser used for this is this one > > processOptions :: Parser Options > processOptions = Process > <$> optional config > <*> optional (argument (eitherReader (parseOnly configRangeP . pack)) (metavar "RANGE")) > > it use the configRangeP attoparser parser whcih knows how to deal with the string "698-734 735-736" I guess you must use something like (many (argument ...)). From aidancrawfordd at gmail.com Sun Feb 6 16:24:34 2022 From: aidancrawfordd at gmail.com (Amber Crawford) Date: Sun, 6 Feb 2022 09:24:34 -0700 Subject: [Haskell-cafe] How can I get a list of all English words? Message-ID: I'm creating a project in which I need a list of every English word, so I'm wondering how I would get this. The only thing I need is that I can filter the words based on some boolean function, thanks. btw I'm pretty beginner so sry If i'm not really good at writing these. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mukeshtiwari.iiitm at gmail.com Sun Feb 6 16:36:08 2022 From: mukeshtiwari.iiitm at gmail.com (mukesh tiwari) Date: Sun, 6 Feb 2022 16:36:08 +0000 Subject: [Haskell-cafe] How can I get a list of all English words? In-Reply-To: References: Message-ID: Hi Amber, Can you give one example, or a test case? If you need every English word, you need to read a English dictionary, which has all the words, and store it in map, or hash-map, because list would be very slow for accessing the words. (is it the case that you want to break a line, e.g., “brown fox jumped over the lazy dog” into list of words, [brown, fox, jumped, over, the, lazy, dog]?) Best, Mukesh On Sun, 6 Feb 2022 at 16:25, Amber Crawford wrote: > I'm creating a project in which I need a list of every English word, so > I'm wondering how I would get this. The only thing I need is that I can > filter the words based on some boolean function, thanks. btw I'm pretty > beginner so sry If i'm not really good at writing these. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From migmit at gmail.com Sun Feb 6 16:47:37 2022 From: migmit at gmail.com (MigMit) Date: Sun, 6 Feb 2022 17:47:37 +0100 Subject: [Haskell-cafe] How can I get a list of all English words? In-Reply-To: References: Message-ID: <3F1DDDDB-0E6B-47A5-B5A2-C70DB2FCEC84@gmail.com> Oxford English Dictionary contains more than 600000 words, by the way. And sometimes even humans have trouble discerning typos from made-up words, which may or may not be a concern for you, depending on your goal. > On 6 Feb 2022, at 17:36, mukesh tiwari wrote: > > Hi Amber, > > Can you give one example, or a test case? If you need every English word, you need to read a English dictionary, which has all the words, and store it in map, or hash-map, because list would be very slow for accessing the words. (is it the case that you want to break a line, e.g., “brown fox jumped over the lazy dog” into list of words, [brown, fox, jumped, over, the, lazy, dog]?) > > Best, > Mukesh > > On Sun, 6 Feb 2022 at 16:25, Amber Crawford wrote: > I'm creating a project in which I need a list of every English word, so I'm wondering how I would get this. The only thing I need is that I can filter the words based on some boolean function, thanks. btw I'm pretty beginner so sry If i'm not really good at writing these. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ietf-dane at dukhovni.org Sun Feb 6 16:49:43 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 6 Feb 2022 11:49:43 -0500 Subject: [Haskell-cafe] How can I get a list of all English words? In-Reply-To: References: Message-ID: <3023A6C9-59FF-4949-8039-D79072AE5B07@dukhovni.org> > On 6 Feb 2022, at 11:24 am, Amber Crawford wrote: > > I'm creating a project in which I need a list of every English word, so I'm wondering how I would get this. The only thing I need is that I can filter the words based on some boolean function, thanks. btw I'm pretty beginner so sry If i'm not really good at writing these. There is no single definitive list, but many Unix-like systems (including MacOS) have various word lists in /usr/share/dict/: Linux: $ ls /usr/share/dict/ linux.words words MacOS: $ ls /usr/share/dict/ README connectives propernames web2 web2a words FreeBSD: $ ls /usr/share/dict/ README freebsd propernames web2 web2a words -- Viktor. From greg7mdp at gmail.com Sun Feb 6 16:50:43 2022 From: greg7mdp at gmail.com (Gregory Popovitch) Date: Sun, 6 Feb 2022 11:50:43 -0500 Subject: [Haskell-cafe] How can I get a list of all English words? In-Reply-To: References: Message-ID: <055a01d81b79$ae7d2720$0b777560$@gmail.com> On linux you can use /etc/dictionaries-common/words, for example ❯ grep "stream" /etc/dictionaries-common/words bloodstream bloodstream's bloodstreams downstream mainstream mainstream's mainstreamed mainstreaming mainstreams midstream midstream's stream stream's streamed streamer streamer's streamers streaming streamline streamlined streamlines streamlining streams upstream From: Haskell-Cafe On Behalf Of Amber Crawford Sent: Sunday, February 06, 2022 11:25 AM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] How can I get a list of all English words? I'm creating a project in which I need a list of every English word, so I'm wondering how I would get this. The only thing I need is that I can filter the words based on some boolean function, thanks. btw I'm pretty beginner so sry If i'm not really good at writing these. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nnunley at gmail.com Sun Feb 6 16:51:49 2022 From: nnunley at gmail.com (Norman Nunley) Date: Sun, 6 Feb 2022 11:51:49 -0500 Subject: [Haskell-cafe] How can I get a list of all English words? In-Reply-To: References: Message-ID: It reads like you want to verify that a given word in a string exists in a list of (english) words. https://github.com/dwyl/english-words seems to contain a large user contributed list of english words (~450k). It seems to contain a number of loan words as well as potentially made up words, so caveat emptor. As far as testing for membership - I'd suggest building up a Data.Trie.Set ( https://hackage.haskell.org/package/trie-simple-0.4.1.1/docs/Data-Trie-Set.html). The trie data structure provides a reasonably compact representation of strings, and Sets provide a function to test if a given word is a member. On Sun, Feb 6, 2022 at 11:37 AM mukesh tiwari wrote: > Hi Amber, > > Can you give one example, or a test case? If you need every English word, > you need to read a English dictionary, which has all the words, and store > it in map, or hash-map, because list would be very slow for accessing the > words. (is it the case that you want to break a line, e.g., “brown fox > jumped over the lazy dog” into list of words, [brown, fox, jumped, over, > the, lazy, dog]?) > > Best, > Mukesh > > On Sun, 6 Feb 2022 at 16:25, Amber Crawford > wrote: > >> I'm creating a project in which I need a list of every English word, so >> I'm wondering how I would get this. The only thing I need is that I can >> filter the words based on some boolean function, thanks. btw I'm pretty >> beginner so sry If i'm not really good at writing these. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 j.stutterheim at me.com Mon Feb 7 02:23:16 2022 From: j.stutterheim at me.com (J. Stutterheim) Date: Mon, 7 Feb 2022 10:23:16 +0800 Subject: [Haskell-cafe] Haskell Developer Roles at Standard Chartered Bank (UK and SG) Message-ID: <1B7E0265-01FB-4FAA-B549-59C14C4FA0D0@me.com> Hi all, I'm happy to report that my team at Standard Chartered Bank is hiring Haskell programmers! We're currently hiring in London, and we expect to open positions in Singapore soon. If you're interested in writing Haskell code for mission-critical cloud-based applications, this is the job for you. Financial knowledge is not required, as there will be plenty of opportunity to pick it up on the job. If you're interested in having a chat, please apply through the following link: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200001642&lang=en After applying through the link above, please shoot me an email at `jurrien dot stutterheim at sc dot com` so that I know that you have applied. Best regards, Jurriën From seb at sebleblanc.net Mon Feb 7 02:52:00 2022 From: seb at sebleblanc.net (=?UTF-8?Q?S=C3=A9bastien_Leblanc?=) Date: Sun, 6 Feb 2022 21:52:00 -0500 Subject: [Haskell-cafe] optparse-applicative with attoparsec parser In-Reply-To: References: Message-ID: > > Date: Fri, 4 Feb 2022 15:09:41 +0100 (CET) > From: PICCA Frederic-Emmanuel > > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] optparse-applicative with attoparsec parser > Message-ID: > < > 30404406.15581346.1643983781075.JavaMail.zimbra at synchrotron-soleil.fr> > > Content-Type: text/plain; charset=utf-8 > > Hello, > > I Try to write a parser for this command line > > binoculars-ng --debug process data/test/config_sixs_ruche_flymedv_3.ini > 698-734 735-736 > > But I have this problem > > Invalid argument `735-736' > > The parser used for this is this one > > processOptions :: Parser Options > processOptions = Process > <$> optional config > <*> optional (argument (eitherReader (parseOnly > configRangeP . pack)) (metavar "RANGE")) > > it use the configRangeP attoparser parser whcih knows how to deal with the > string "698-734 735-736" > > configRangeP :: Parser ConfigRange > configRangeP = ConfigRange <$> (inputRangeP `sepBy` many (satisfy isSep)) > where > isSep :: Char -> Bool > isSep c = c == ' ' || c == ',' > > the result should be this one > > Just (ConfigRange [InputRangeFromTo 698 734,InputRangeFromTo 735 736]) > > so my question how should I fix my processOptions fucntion in order to > deal with this problem. > > thanks for considering > It seems that the issue stems from having your arguments separated by spaces. If your parser is parsing [[ [debug-flag] ]], then it does not know what to do with the last particle (735-736). You would need to wrap your ranges in quotes in your shell, to include the space, or replace the space with a comma instead (698-734,735-736) Sébastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.redelings at gmail.com Tue Feb 8 01:21:59 2022 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Mon, 7 Feb 2022 17:21:59 -0800 Subject: [Haskell-cafe] Explicit type signatures and wrappers / impedance-matching In-Reply-To: <69bf561f-2fea-d1dd-4485-75e7dcbe28de@gmail.com> References: <69bf561f-2fea-d1dd-4485-75e7dcbe28de@gmail.com> Message-ID: So... I suspect that the best way forwards is just to read GHC/TC/Gen/Bind.hs and make notes on all the functions.  That is what I am doing. -BenRI On 1/31/22 2:50 PM, Benjamin Redelings wrote: > > Hi, > > I am trying to understand (and implement) how Haskell handles explicit > type signatures.  Specifically, I'm trying to understand how explicit > type signatures interact with wrappers. > > 1. Is there any paper or documentation that explains wrappers and/or > explicit type signatures in detail?  There are some non-obvious > details regarding wrappers, such as using eliminating type arguments > by supplying the Any type as an argument... > > 2. Do explicit type signatures impose any unification constraints, or > can they be thought of entirely in terms of wrappers? > > For example, if we have > > g :: Int -> Int > (f,g) = (\x ->x, f) > > then the signature for g is added to the environment when typing the > right-hand-side. > > One way that this could be handled is: > > (i) typecheck rhs -> rhs_type > > (ii) generate type of lhs with fresh variables for every binder -> > lhs_type = (a,b) > > (iii) unify(lhs_type, rhs_type) > > (iv) do one-way unification: match(inferred-type-of-g, > explicit-type-for-g) > > Is this correct?  Step (iv), the way that I have written it, would > impose unification constraints. > > Without considering the type signature, we would have > > { f_mono :: a -> a, g_mono :: a -> a} > > If we just use wrappers to impose the explict type, it seems like we > would get something like > > let tup = /\a.let {(f:a,g:a) = (\x:a -> x:a, f::a->a) > f = /\a.case tup a of (f,g) -> f > g = case tup @Int of (f,g) -> g > > where f :: forall a.a ->a and g :: Int -> Int. > > THIH seems to imply that type signatures are merely checked: no > unification constraints are imposed (I think).  However, ghc reports f > :: Int -> Int. > > I apologize if this is a dumb question.  I have found the definition > of HsWrapper in ghc/compiler/GHC/Tc/Types/Evidence.hs, but I am still > struggling a bit. > > thanks! > > -BenRI > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Wed Feb 9 15:57:53 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 9 Feb 2022 15:57:53 +0000 Subject: [Haskell-cafe] Haskell Foundation seeks new Executive Director Message-ID: <010f017edf3498e3-86a380f4-b78d-4d69-927a-dae5cfa54005-000000@us-east-2.amazonses.com> Hi all, Following Andrew Boardman's resignation announcement [1] yesterday, the Haskell Foundation is seeking a new Executive Director. The job ad appears below. Note that we are eager to identify our next leader, and so the turnaround is tight -- we will fully consider only applications received by the end of Feb 22 (anywhere on Earth). Please spread the word, recommend folks to consider, use your networks, etc! Feel free to post here or reach out to me with any questions. Job ad home: https://haskell.foundation/careers/ed.html [1]: https://discourse.haskell.org/t/haskell-foundation-executive-director-change/4047 ------------------------------ # Executive Director ## About the Haskell Foundation The Haskell Foundation (HF) is an independent, non-profit organization dedicated to broadening the adoption of Haskell, by supporting its ecosystem of tools, libraries, education, and research. ## The Role HF seeks a full-time Executive Director (ED) to continue to inspire and develop the organization. The ED is responsible for furthering HF’s mission and vision, ensuring that resources are in place to accomplish its goals. The ED will drive sourcing for sponsorships, structure the organization, recruit and channel the efforts of both volunteers and paid staff. Working with HF's Board of Directors, the ED will articulate HF’s strategic priorities and direction. They will assess and evaluate strategies, hire teams, set budgets, forge alliances, and build partnerships to further the mission. The ED will play a crucial role in building the culture of HF around community service. HF will succeed if and only if it succeeds in unlocking the expertise and enthusiasm of volunteer members of the community. This will be a major goal for the ED, so that volunteers find HF to be a solid professional home with ample opportunities for recognition and professional growth. Finally, the ED will actively promote HF to build its financial reserves and goodwill. They will secure, budget, and allocate resources appropriately and hold themselves accountable for the financial health of the organization. ## Reporting Relationships The ED reports to the Board of Directors. All other members of staff and volunteers report directly or indirectly to the ED. ## Responsibilities **Organization Mission and Strategy**: Works with the Board and staff to ensure that the mission is fulfilled. * Responsible for the implementation of volunteer programs that carry out the organization’s mission. * Responsible for recruiting existing community projects to affiliate with HF, and for assessing their ongoing adherence to HF standards. * Responsible for the enhancement of HF’s image by being engaged with the community and by working closely with other professional and private organizations. * Be the public face of HF through public presentations at Haskell-related events. * Cultivate excellent relationships with the community and operate HF’s social media presence. **Organization Operations**: Oversees and implements appropriate resources to ensure that the operations of the organization are appropriate. * Responsible for the hiring and retention of competent, qualified staff as financial resources permit. * Responsible for the effective administration of HF’s operations. * Responsible for signing all notes, agreements, and other instruments made and entered into and on behalf of the organization. * Responsible for fiscal management that generally anticipates operating within the approved budget, ensures maximum resource utilization, and maintenance of the organization in a positive financial position. **Viability**: Develops financial resources sufficient to ensure the sustainability of the organization. * Responsible for fundraising and developing other revenues necessary to support HF’s mission. * Participate in identifying and cultivating corporate, institutional and individual sponsors. **Board Governance**: Works with the Board to help it enact HF’s mission. * Responsible for leading HF in a manner that supports the organization’s mission. * Responsible for communicating effectively with the Board and providing, in a timely and accurate manner, all information necessary for the Board to function properly and to make informed judgements. * Ensure that HF is in compliance with relevant state and federal laws, regulations and with standard accounting procedures. * Work with individual Board members and subcommittees as directed by the Board. * Inform the Board regularly of internal organization matters, including relevant staffing, funding and program success and priorities. * Responsible for the fiscal integrity of HF, ensure that the Board is able to monitor the financial condition of HF. This means preparing budgets and financial statements which accurately reflect the financial condition of the organization and are kept up to date. ## Salary and Employment The ED can live anywhere in the world – remote working is the standard within HF. The ED must be eligible under USA law and the law in their jurisdiction to perform work (as an employee or as a contractor) for a non-profit organization incorporated in the USA. Salary will be commensurate with the experience and qualities of the candidate, and will also reflect the Foundation’s status as a non-profit organization funded by donations. ## Key Credentials and Personal Qualities Candidates are encouraged to apply with the expectation that the Board will assist and coach in areas of personal development tailored to the successful candidate’s needs. **Essential attributes:** * Successful experience in development and organizational leadership in a non-profit or business setting. * Self-starter, with strong motivational and staff leadership abilities. * Demonstrated knowledge, via experience or an advanced degree in CS, math or a related technical field. * Willingness to execute fundraising plans and strategies that generate significant results. * Commitment to results; “can-do" mindset with emphasis on accountability. * Exceptional in communicating verbally and in written language. * Integrity and impeccable work ethic. **Desirable attributes:** * Experience at change management. * Experience in writing persuasive materials including successful appeals, proposals, presentations, stewardship materials, and other collateral. * Knowledge of the Haskell community and its dynamics. HF celebrates diversity and inclusion, and does not discriminate on an individual’s identity characteristics. Under-represented minorities are especially encouraged to apply. ## Application Process Interested candidates should submit a resume and thoughtful cover letter outlining how their skills and experience meet the qualifications of the position, and their vision for the Foundation. Send to nominations at haskell.foundation. If you have any questions about the position, feel free to email chair at haskell.foundation. Closing date: Tuesday, February 22, 2022. From frederic-emmanuel.picca at synchrotron-soleil.fr Wed Feb 9 17:43:39 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Wed, 9 Feb 2022 18:43:39 +0100 (CET) Subject: [Haskell-cafe] C binding <-> safer haskell API Message-ID: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I try to create a binding for a C library I can find something like this in the c library merge(HklCube *cube, const HklFrame *frame) So I create a binding with binding-DSL #ccall merge, Ptr -> Ptr -> IO () Now I want to create a higher level API whcich encode the fact that the cube is modified after the merge. So what is the best way to encode this in the type ? merge :: _ merge c f = do .... c'merge pc pf I thought about IORef, but I am not sure thaht this is the right way to have a safer haskell interface for this method. thanks for your help Fred From jm at memorici.de Wed Feb 9 18:14:47 2022 From: jm at memorici.de (Jonn Mostovoy) Date: Wed, 9 Feb 2022 18:14:47 +0000 Subject: [Haskell-cafe] current status of cloud haskell? In-Reply-To: References: <13dbbe6d-c10c-cbc2-4cdb-b33447fbc232@themactionfaction.com> Message-ID: Semi-solicited advertisement of purerl. It works and is actively used in production. It even has an actor framework a la Erlang OTP: https://github.com/id3as/purescript-erl-pinto I've chatted with purerl devs, who are really nice too, and if I had a budget, I would absolutely make a concurrent system with it. On Thu, 3 Feb 2022, 22:12 Will Yager, wrote: > I used distributed-process 5 or 6 years ago when I was in uni for a > distributed systems class. It was pretty nice, but I have no idea about its > current maintenance. > > I wrote a blog post at the time with some thoughts on design patterns etc. > http://yager.io/Distributed/Distributed.html > > On Feb 3, 2022, at 15:54, A.M. wrote: > > On 2/3/22 12:32, stuebinm via Haskell-Cafe wrote: > > Hi all! > > I've been meaning to do more with concurrent (and parallel) haskell, and > having looked around a bit on hackage (and being a fan of Erlang's OTP) the > cloud haskell packages seem like a dream come true. But only at first > glance — the last release of distributed-process [1], which looks to be the > main library, was in 2018, and many of the other packages are older. The > "recent news" section of the website [2] even has its last entry from 2016! > > So I'd be assuming that the project has been abandoned, yet on github [3] > it looks to still be (comparatively) alive and well, with activity just a > few months ago. > > So what's the current status there? Is anyone here using it productively, > or involved in its development / knows if or when to expect a new release? > > > Hi stuebinm, > > We were using distributed-process within our own project until it was too > much effort to keep up with newer GHC releases and packages. > > We were able to replace distributed-process and friends with our own much > more lightweight curryer-rpc library[1] for the simple use-case of TCP > client-server interaction. > > Cheers, > M > > > 1. https://hackage.haskell.org/package/curryer-rpc > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ietf-dane at dukhovni.org Wed Feb 9 19:33:00 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Feb 2022 14:33:00 -0500 Subject: [Haskell-cafe] C binding <-> safer haskell API In-Reply-To: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> References: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Wed, Feb 09, 2022 at 06:43:39PM +0100, PICCA Frederic-Emmanuel wrote: > So I create a binding with binding-DSL > > #ccall merge, Ptr -> Ptr -> IO () > > Now I want to create a higher level API which encode the fact that > the cube is modified after the merge. So what is the best way to > encode this in the type? Perhaps your use-case is somewhat analogous to ByteString, which wraps an underlying (potentially) mutable memory block as an abstract "pure" octet string. With ByteString, operations that produce new bytestrings do so by copying the original buffer (except for "slices" which simply alias part of the buffer content). > merge :: _ > merge c f = do > .... > c'merge pc pf > > I thought about IORef, but I am not sure thaht this is the right way > to have a safer haskell interface for this method. Thus the wrapper function would instead have a signature of: merge :: Cube -> Frame -> Cube producing a new Cube, leaving the original unmodified. If however always copying the cube is too expensive, then you can take an approach similar to that used in Array or Vector, where Cubes are available in both immutable and mutable forms, with freeze, thaw, unsafeFreeze and unsafeThaw operations connecting the two. data Cube = Cube ... data STCube s = STCube s ... data IOCube = IOCube ... Mutable cubes can be modified in place in either the IO or ST Monads. -- VIktor. From heraldhoi at gmail.com Wed Feb 9 23:43:54 2022 From: heraldhoi at gmail.com (Geraldus) Date: Thu, 10 Feb 2022 04:43:54 +0500 Subject: [Haskell-cafe] Any chances to fetch data from Vertica DB? Message-ID: Hi, dear Café! I'm trying to figure out if there is any way to connect and fetch data from the Vertica database? I got used to the amazing `esqueleto` package, and ideally, I'm looking for a way to use type-safe queries. Albeit at the moment raw SQL queries would be sufficient. Any feedback would be appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic-emmanuel.picca at synchrotron-soleil.fr Thu Feb 10 09:30:18 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Thu, 10 Feb 2022 10:30:18 +0100 (CET) Subject: [Haskell-cafe] C binding <-> safer haskell API In-Reply-To: References: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <209646940.2368337.1644485418235.JavaMail.zimbra@synchrotron-soleil.fr> Hello, I am in this case, the Cube C struct contains at least two realy big arrays. I wan to modify them in place. > If however always copying the cube is too expensive, then you can take > an approach similar to that used in Array or Vector, where Cubes are > available in both immutable and mutable forms, with freeze, thaw, > unsafeFreeze and unsafeThaw operations connecting the two. > > data Cube = Cube ... > data STCube s = STCube s ... > data IOCube = IOCube ... > > Mutable cubes can be modified in place in either the IO or ST Monads. I like this idea, I looked a t the MVector implementation data MVector s a = MVector {-# UNPACK #-} !Int -- ^ Offset in underlying array {-# UNPACK #-} !Int -- ^ Size of slice {-# UNPACK #-} !(MutableArray s a) -- ^ Underlying array deriving ( Typeable ) type IOVector = MVector RealWorld type STVector s = MVector s I imagine that in my case I can can just define a. data MCube s = MCube (ForeignPtr C'HklBinocularsCube) and then type IOCube = NCube RealWorld I a > > -- > VIktor. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From frederic-emmanuel.picca at synchrotron-soleil.fr Thu Feb 10 09:39:26 2022 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Thu, 10 Feb 2022 10:39:26 +0100 (CET) Subject: [Haskell-cafe] C binding <-> safer haskell API In-Reply-To: <209646940.2368337.1644485418235.JavaMail.zimbra@synchrotron-soleil.fr> References: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> <209646940.2368337.1644485418235.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: <381923208.2380669.1644485966896.JavaMail.zimbra@synchrotron-soleil.fr> Sorry I sent the email before finishin it :)) ----- PICCA Frederic-Emmanuel a écrit : > Hello, > > I am in this case, the Cube C struct contains at least two realy big arrays. > I wan to modify them in place. > > > If however always copying the cube is too expensive, then you can take > > an approach similar to that used in Array or Vector, where Cubes are > > available in both immutable and mutable forms, with freeze, thaw, > > unsafeFreeze and unsafeThaw operations connecting the two. > > > > data Cube = Cube ... > > data STCube s = STCube s ... > > data IOCube = IOCube ... > > > > Mutable cubes can be modified in place in either the IO or ST Monads. > > I like this idea, I looked a t the MVector implementation > > data MVector s a = MVector {-# UNPACK #-} !Int -- ^ Offset in underlying array > {-# UNPACK #-} !Int -- ^ Size of slice > {-# UNPACK #-} !(MutableArray s a) -- ^ Underlying array > deriving ( Typeable ) > > type IOVector = MVector RealWorld > type STVector s = MVector s > > > I imagine that in my case I can can just define a. > > data MCube s = MCube (ForeignPtr C'HklBinocularsCube) > > and then > > type IOCube = NCube RealWorld > Then it seems to me that I just need to define a merge function like this merge :: PrimMonad m => MCube (PrimState m) -> Frame -> m () and then an unsafeFreeze to avoid copy. It that correct ? Cheers Fred From chris at chrisdornan.com Thu Feb 10 12:49:46 2022 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 10 Feb 2022 12:49:46 +0000 Subject: [Haskell-cafe] Haskell Foundation Stability Working Group Message-ID: <868FE5D1-923B-468E-BBA0-7AD4F716FC66@chrisdornan.com> Hi Everyone, This is to announce the formation of the Haskell Foundation Stability Working Group , a new working group for for studying and promoting stability in the Haskell ecosystem. Check out our our home page (https://github.com/haskellfoundation/stability) where you can read about who we are, and what we do and are doing (and have been doing). We meet on a call about once a fortnight – let us know if you would like to join any of our calls or raise any topic with the group (the e-list for contacting the group is on the home page). Chris Dornan for the Haskell Foundation Stability Working Group -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Thu Feb 10 14:28:27 2022 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Feb 2022 09:28:27 -0500 Subject: [Haskell-cafe] C binding <-> safer haskell API In-Reply-To: <381923208.2380669.1644485966896.JavaMail.zimbra@synchrotron-soleil.fr> References: <1575700032.2022915.1644428619413.JavaMail.zimbra@synchrotron-soleil.fr> <209646940.2368337.1644485418235.JavaMail.zimbra@synchrotron-soleil.fr> <381923208.2380669.1644485966896.JavaMail.zimbra@synchrotron-soleil.fr> Message-ID: On Thu, Feb 10, 2022 at 10:39:26AM +0100, PICCA Frederic-Emmanuel wrote: > Then it seems to me that I just need to define a merge function like this > > merge :: PrimMonad m => MCube (PrimState m) -> Frame -> m () > > and then an unsafeFreeze to avoid copy. It that correct? Well, the `unsafeFreeze` would typicall only be appropriate in pure functions that *construct* a pure `Cube` from scratch by allocating and mutating an `MCube`. As for merge itself, it runs in IO and mutates an `MCube`. It is the caller's responsibility to ensure that that object is not "shared". If the entire computation runs in `IO` then you just use MCube(s) throughout. Once you have a pure `Cube`, you would typically not mutate it in place, except in "linear" use-cases that *consume* its *sole* reference while mutating it in place (possibly returning a fresh Cube based on the modified copy). Ensuring "linearity" is not trivial (a key reason for the existence of "Rust"). Use of `unsafeThaw` is atypical. -- Viktor. From anatoly.zaretsky at gmail.com Fri Feb 11 13:31:16 2022 From: anatoly.zaretsky at gmail.com (Anatoly Zaretsky) Date: Fri, 11 Feb 2022 15:31:16 +0200 Subject: [Haskell-cafe] Any chances to fetch data from Vertica DB? In-Reply-To: References: Message-ID: Hi, Geraldus! On Thu, Feb 10, 2022 at 1:44 AM Geraldus wrote: > I'm trying to figure out if there is any way to connect and fetch data > from the Vertica database? I got used to the amazing `esqueleto` package, > and ideally, I'm looking for a way to use type-safe queries. Albeit at the > moment raw SQL queries would be sufficient. > They claim to have ODBC drivers [1], so perhaps for raw SQL `HDBC-odbc` [2] could work out of the box. Since `esqueleto` relies on `persistent`, some non-trivial integration might be required to make them talk to each other [3]. [1] https://www.vertica.com/download/vertica/client-drivers/ [2] https://hackage.haskell.org/package/HDBC-odbc [3] https://hackage.haskell.org/package/persistent-odbc -- Best regards, Anatoly Zaretsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From dreixel at gmail.com Sun Feb 13 14:00:55 2022 From: dreixel at gmail.com (=?UTF-8?Q?Jos=C3=A9_Pedro_Magalh=C3=A3es?=) Date: Sun, 13 Feb 2022 14:00:55 +0000 Subject: [Haskell-cafe] Several Haskell roles with Core Strats at Standard Chartered Message-ID: Full details here (so I can update the Shanghai link once it's up): https://discourse.haskell.org/t/several-haskell-roles-with-core-strats-at-standard-chartered/4087 Cheers, Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Tue Feb 15 21:49:58 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 15 Feb 2022 21:49:58 +0000 Subject: [Haskell-cafe] Explicit type signatures and wrappers / impedance-matching In-Reply-To: References: <69bf561f-2fea-d1dd-4485-75e7dcbe28de@gmail.com> Message-ID: <010f017eff5d1ae7-74e6accb-7e6c-45a8-8096-33fe9d9e64c3-000000@us-east-2.amazonses.com> Some time has passed. Have you made forward progress? The truth is that the particular case you describe would make me, too, stare hard at the code. (This is why I have been slow to respond!) One thing I can say is that I do not think HsWrappers are much implicated. They are involved with instantiation of type variables and of dictionaries (among other fun things). Instead, look for a construct called AbsBinds, which is heavily implicated here. You seem to be doing interesting work -- please don't let yourself get stuck. Keeping asking for answers if you need them! :) Richard > On Feb 7, 2022, at 8:21 PM, Benjamin Redelings wrote: > > So... I suspect that the best way forwards is just to read GHC/TC/Gen/Bind.hs and make notes on all the functions. That is what I am doing. > > -BenRI > > On 1/31/22 2:50 PM, Benjamin Redelings wrote: >> Hi, >> >> I am trying to understand (and implement) how Haskell handles explicit type signatures. Specifically, I'm trying to understand how explicit type signatures interact with wrappers. >> >> 1. Is there any paper or documentation that explains wrappers and/or explicit type signatures in detail? There are some non-obvious details regarding wrappers, such as using eliminating type arguments by supplying the Any type as an argument... >> >> 2. Do explicit type signatures impose any unification constraints, or can they be thought of entirely in terms of wrappers? >> >> For example, if we have >> >> g :: Int -> Int >> (f,g) = (\x ->x, f) >> then the signature for g is added to the environment when typing the right-hand-side. >> >> One way that this could be handled is: >> >> (i) typecheck rhs -> rhs_type >> >> (ii) generate type of lhs with fresh variables for every binder -> lhs_type = (a,b) >> >> (iii) unify(lhs_type, rhs_type) >> >> (iv) do one-way unification: match(inferred-type-of-g, explicit-type-for-g) >> >> Is this correct? Step (iv), the way that I have written it, would impose unification constraints. >> >> Without considering the type signature, we would have >> >> { f_mono :: a -> a, g_mono :: a -> a} >> >> If we just use wrappers to impose the explict type, it seems like we would get something like >> >> let tup = /\a.let {(f:a,g:a) = (\x:a -> x:a, f::a->a) >> f = /\a.case tup a of (f,g) -> f >> g = case tup @Int of (f,g) -> g >> >> where f :: forall a.a ->a and g :: Int -> Int. >> >> THIH seems to imply that type signatures are merely checked: no unification constraints are imposed (I think). However, ghc reports f :: Int -> Int. >> >> I apologize if this is a dumb question. I have found the definition of HsWrapper in ghc/compiler/GHC/Tc/Types/Evidence.hs, but I am still struggling a bit. >> >> thanks! >> >> -BenRI >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Feb 17 19:16:52 2022 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 17 Feb 2022 16:16:52 -0300 Subject: [Haskell-cafe] Which gogol-* library provides access to the "secrets manager" API on cloud run? Message-ID: <1aac5923-1c5a-e317-16b8-9fc346425190@gmail.com> Hello -Cafe On the company I work for we are migrating to google cloud run. As part of the migration I have to interface with the secret management API[1]. I got the `gogol`[2] library compiling and working, yet I don't seem to find a package nor module what provides this functionality. Is this supported by the `gogol` library? Am I not looking at the correct sub-package? Any direction, alternatives or feedback are appreciated. [1]: [2]: -- Rubén. (pgp: 1E88 3AC4 89EB FA22) From amy at nualeargais.ie Thu Feb 17 15:15:59 2022 From: amy at nualeargais.ie (=?UTF-8?Q?Amy_de_Buitl=C3=A9ir?=) Date: Thu, 17 Feb 2022 15:15:59 +0000 Subject: [Haskell-cafe] recommend book for self-study group Message-ID: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> I want to encourage more people at my company to learn Haskell, but I just don't have time to prepare and deliver a class. But then it occurred to me I could lead a self-study group, where people learn on their own but would have a forum to discuss what they're learning and ask questions. I would encourage people to answer each other's questions, but I would answer the more difficult questions. What book(s) do you think would be best suited for self-study? The participants would all be experienced programmers, but would likely have no knowledge of functional programming? -------------- next part -------------- An HTML attachment was scrubbed... URL: From varikvalefor at aol.com Fri Feb 18 00:08:44 2022 From: varikvalefor at aol.com (Varik Valefor) Date: Thu, 17 Feb 2022 19:08:44 -0500 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> References: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> Message-ID: <99f7811a-1d42-138b-d5f7-8ea5a0e52313@aol.com> AMY: D'oh!  Remember to use the "reply to all" thing. The Haskell Language Report, hereinafter referred to as the "HNR", is an excellent reference material.  Additionally, thoroughly reading the HNR facilitates grokking Haskell.  But the HNR is a bit weird and can be discouraging. Relatively "friendly" reading material includes "Learn You a Haskell for Great Good" and "Real World Haskell", which are available at https://learnyouahaskell.com/ and http://book.realworldhaskell.org, respectively. Just remember that using the HNR _is_ probably the best method of truly grokking Haskell... and that independently learning from the HNR is absolutely possible.  ;^) Good luck, Varik Valefor "Fuch's Warning: If you actually look like your passport photo, you aren't well enough to travel." On 2/17/22 10:15, Amy de Buitléir wrote: > > I want to encourage more people at my company to learn Haskell, but I > just don't have time to prepare and deliver a class. But then it > occurred to me I could lead a self-study group, where people learn on > their own but would have a forum to discuss what they're learning and > ask questions. I would encourage people to answer each other's > questions, but I would answer the more difficult questions. > > What book(s) do you think would be best suited for self-study? The > participants would all be experienced programmers, but would likely > have no knowledge of functional programming? > From fa-ml at ariis.it Fri Feb 18 07:10:44 2022 From: fa-ml at ariis.it (Francesco Ariis) Date: Fri, 18 Feb 2022 08:10:44 +0100 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> References: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> Message-ID: Il 17 febbraio 2022 alle 15:15 Amy de Buitléir ha scritto: > What book(s) do you think would be best suited for self-study? The > participants would all be experienced programmers, but would likely have no > knowledge of functional programming? Not a book, but CIS194 [1] is thorough, practical, with exercises, gratis. —F [1] https://www.seas.upenn.edu/~cis194/spring13/lectures.html From leah at vuxu.org Fri Feb 18 17:47:55 2022 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 18 Feb 2022 18:47:55 +0100 Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2022-02-22 @ 19:30 Message-ID: <87pmnkdq2c.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, February 22 on Jitsi at 19:30 CEST. **Due to the pandemic, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Jitsi link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen https://leahneukirchen.org/ From godzbanebane at gmail.com Fri Feb 18 21:00:43 2022 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Fri, 18 Feb 2022 23:00:43 +0200 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: References: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> Message-ID: Additionally, Hutton's Programming in Haskell seems to be pretty good. I would definitely recommend it over LYAH, as LYAH at the very least doesn't have exercises. On Fri, Feb 18, 2022 at 9:13 AM Francesco Ariis wrote: > Il 17 febbraio 2022 alle 15:15 Amy de Buitléir ha scritto: > > What book(s) do you think would be best suited for self-study? The > > participants would all be experienced programmers, but would likely have > no > > knowledge of functional programming? > > Not a book, but CIS194 [1] is thorough, practical, with exercises, gratis. > —F > > [1] https://www.seas.upenn.edu/~cis194/spring13/lectures.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 johannes.waldmann at htwk-leipzig.de Sun Feb 20 16:57:47 2022 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Sun, 20 Feb 2022 17:57:47 +0100 Subject: [Haskell-cafe] recommend book for self-study group Message-ID: > https://www.seas.upenn.edu/~cis194/spring13/lectures.html I agree strongly. See also https://haskell.markmail.org/search/?q=CIS194 Then, you want to quickly move to https://thinkingwithtypes.com/ (the second half of CIS194 already shows the way) ... because that's what makes present-day Haskell useful and unique (and not "thinking with lists (and Ints)", as some (LISP-era) introductory texts want you to believe) > ... I just don't have time to prepare and deliver a class. then hire a (remote) consultant? Buy a few copies of Maguire's book. - J.W. From amin.saffari at gmail.com Sun Feb 20 18:13:46 2022 From: amin.saffari at gmail.com (amin saffari) Date: Sun, 20 Feb 2022 19:13:46 +0100 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> References: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> Message-ID: I did run a self study group in Berlin and I highly recommend the 1st 19 chapters of the "Haskell programming from first principles" to start from the ground. After that it's more beneficial to continue with a more project-based approach to connect the dots with hands-on code. For the second part, although I just read the sample part of "The Simple Haskell Handbook", it seems fairly practical. Cheers, On Thu, Feb 17, 2022 at 9:11 PM Amy de Buitléir wrote: > I want to encourage more people at my company to learn Haskell, but I just > don't have time to prepare and deliver a class. But then it occurred to me > I could lead a self-study group, where people learn on their own but would > have a forum to discuss what they're learning and ask questions. I would > encourage people to answer each other's questions, but I would answer the > more difficult questions. > > What book(s) do you think would be best suited for self-study? The > participants would all be experienced programmers, but would likely have no > knowledge of functional 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. -- Amin -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Sun Feb 20 21:03:17 2022 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Sun, 20 Feb 2022 16:03:17 -0500 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> References: <81732de2c4db6b134877156cd2b1a6bc@nualeargais.ie> Message-ID: Hey Amy, For practical programmers, I think the best way to go is, first, "Get programming with Haskell" by Will Kurt, and after that "Haskell in Depth" by Vitaly Bragilevsky. Both of these were written very much with the mentioned audience in mind and try to go via practical examples/projects. -- Best, Artem On Thu, Feb 17, 2022, 3:10 PM Amy de Buitléir wrote: > I want to encourage more people at my company to learn Haskell, but I just > don't have time to prepare and deliver a class. But then it occurred to me > I could lead a self-study group, where people learn on their own but would > have a forum to discuss what they're learning and ask questions. I would > encourage people to answer each other's questions, but I would answer the > more difficult questions. > > What book(s) do you think would be best suited for self-study? The > participants would all be experienced programmers, but would likely have no > knowledge of functional programming? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at nualeargais.ie Sun Feb 20 22:47:38 2022 From: amy at nualeargais.ie (=?UTF-8?Q?Amy_de_Buitl=C3=A9ir?=) Date: Sun, 20 Feb 2022 22:47:38 +0000 Subject: [Haskell-cafe] recommend book for self-study group In-Reply-To: References: Message-ID: <07cb74cd2acfa180ac6680f056d371c0@nualeargais.ie> Thank you everyone who responded to my request for book suggestions for a self-study group. I had completely forgotten about CIS194, and I'm particularly glad to learn that the second half paves the way for Thinking With Types. These books were new to me: "Haskell programming from first principles", "The Simple Haskell Handbook", "Get programming with Haskell", "Haskell in Depth" Amin, it's especially good to hear from someone who has run a Haskell self study group! -------------- next part -------------- An HTML attachment was scrubbed... URL: From P.Achten at cs.ru.nl Mon Feb 21 14:03:00 2022 From: P.Achten at cs.ru.nl (Peter Achten) Date: Mon, 21 Feb 2022 15:03:00 +0100 Subject: [Haskell-cafe] [TFP'22] final call for papers: Trends in Functional Programming 2022 (deadline March 7 2022) Message-ID: <2209ee04-6fbf-3ff6-a1a5-48b59a561b49@cs.ru.nl> ================ TFP 2022 ================= ==         Final Call For Papers         == ==          registration opened          == =========================================== 23rd Symposium on Trends in Functional Programming 17-18 March, 2022 Online event https://trendsfp.github.io/index.html Due the pandemic, we have had to make TFP virtual this year. As a result, we've decided to push back the deadlines and conference date by a few weeks. In particular, the pre-symposium deadline for submitting the first version of your paper is now just after the ICFP deadline. == Important Dates == Submission deadline for draft papers                Monday 7th March, 2022 Notification for draft submissions                  Friday 11th March, 2022 Symposium dates                                     Thursday 17th - Friday 18th March, 2022 Submission deadline for post-symposium reviewing    Wednesday 6th April, 2022 Notification for post-symposium submissions         Friday 27th May, 2022 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. == 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 2022 program chairs, Wouter Swierstra and Nicolas Wu. == 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. == Instructions to Author == Papers must be submitted at:    https://easychair.org/conferences/?conf=tfp22 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Post-symposium formal review process == Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. == Program Committee == Guillaume Allais                University of St Andrews José Manuel Calderón Trilla     Galois, Inc. Stephen Chang                   University of Massachusetts Boston Matthew Flatt                   University of Utah Jeremy Gibbons                  University of Oxford Zhenjiang Hu                    Peking University Mauro Jaskelioff                CIFASIS / Universidad Nacional de Rosario Moa Johansson                   Chalmers University of Technology Shin-ya Katsumata               National Institute of Informatics Oleg Kiselyov                   Tohoku University Bas Lijnse                      Netherlands Defence Academy / Radboud University Nijmegen Kazutaka Matsuda                Tohoku University Nico Naus                       Virginia Tech Christine Rizkallah             University of New South Wales Alejandro Serrano               47 Degrees Amir Shaikhha                   Ecole Polytechnique Fédérale de Lausanne Aaron Stump                     University of Iowa Wouter Swierstra (Co-chair)     Utrecht University Baltasar Trancón Y Widemann     Semantics GmbH Nicolas Wu (Co-chair)           Imperial College London Ningning Xie                    University of Hong Kong From benjamin.redelings at gmail.com Tue Feb 22 19:42:14 2022 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Tue, 22 Feb 2022 14:42:14 -0500 Subject: [Haskell-cafe] Explicit type signatures and wrappers / impedance-matching In-Reply-To: <010f017eff5d1ae7-74e6accb-7e6c-45a8-8096-33fe9d9e64c3-000000@us-east-2.amazonses.com> References: <69bf561f-2fea-d1dd-4485-75e7dcbe28de@gmail.com> <010f017eff5d1ae7-74e6accb-7e6c-45a8-8096-33fe9d9e64c3-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, Thanks for asking!  Yes, I'm making forward progress.  The feedback is appreciated, as I am not always sure which things I am struggling with are silly questions and which ones are hard questions. Here is my understanding so far -- please chime in if anything is obviously wrong here: I. So, an AbsBinds contains a collection of bindings that could be mutually recursive.  It has constraints "theta" and quantifies over type variables "qtvs" [1].  It also contains "evidence bindings" that explain how to construct dictionaries that are needed from dictionary arguments. An AbsBinds can contain multiple bindings, for example if we have two mutually recursive functions with no type signatures. However, a recursive group can be split into multiple separate AbsBinds if type signatures allow breaking some of the dependencies.  Each binding inside the AbsBinds has a type "monotype" (from tcMonoBinds) before we generalize. Then, for each binding, we end up with two different types: 1. The more quantified type for each binder     forall qtvs. theta => monotype This is what we get if we include ALL the type variables and ALL the predicates that will end up in the AbsBinds. 2. The actual type for each binder, that includes only SOME of the type variables and SOME of the predicates. This is given either by 2a: an explicit type signature 2b: selecting some of the type variables some_qtvs and predicates some_predicates in chooseInferredQuantifiers.  We'd end up with     forall some_qtvs. some_predicates => monotype For example, if we have (f,g) = (\x->x, \y->y+2), then we don't want     f :: forall a b.Num b => a -> a we just want     f :: a -> a The first type is the more quantified type, and the second type is the actual type. Then, in order to handle the difference between these two types, we call `tcSubTypeSigma actual_type more_quantified_type`, which (i) checks to see that we can get `actual_type` out of `more_quantified_type` by constraining it somehow. (i) returns an HsWrapper that, does the actually constraining. It may (I think) eliminate predicates by defaulting, and it can eliminate types by substituting an ANY type, at least sometimes. This wrapper is stored inside abe_wrap field of ABE objects, inside the abs_exports field of the AbsBinds. II. I am still not completely sure how the wrapper is actually applied in code generation, or how the wrapper is computed from the two types.  But, I'm not quite done reading yet. For example, in the case above, suppose that `tuple` represents all combined binders inside the AbsBinds, and is quantified by ALL the type variables and ALL the (given) dictionaries.  One approach would be something like: tuple = /\a./\b.\(dNum :: Num b). let ...CODE... in (f,g) f' = /\a./\b.\(dNum :: b). case (tuple @a @b dNum) of f f = /\a. f' @a @ANY dNum = apply wrapper to f' ? In that approach, then we would FIRST extract an "f'" from the tuple without applying any wrapper.  Then, SECOND, we would SECOND apply the wrapper to f' to get f. III. I am also still working through tcMonoBinds.  I'm curious what happens in a pattern binding, when the pattern has a type signature with predicates: f:: forall a.Num a -> a->a->a (f,g) = ...rhs... It looks like the type signature for gets instantiated on the LHS, and.... I presume the predicate Num a is added to the local instance environment, just like if f was instantiated on the RHS?   I will think about this more... Anyway, thanks for the encouragement.  I am not stuck, yet... All this does make me think that, perhaps, some kind of updated version of Typing Haskell in Haskell would be appropriate.  I'm not sure how much of this is in the Report, either. -BenRI [1] Determined in tcPolyInfer by calling simpliferInfer On 2/15/22 4:49 PM, Richard Eisenberg wrote: > Some time has passed. Have you made forward progress? > > The truth is that the particular case you describe would make me, too, > stare hard at the code. (This is why I have been slow to respond!) > > One thing I can say is that I do not think HsWrappers are much > implicated. They are involved with instantiation of type variables and > of dictionaries (among other fun things). Instead, look for a > construct called AbsBinds, which is heavily implicated here. > > You seem to be doing interesting work -- please don't let yourself get > stuck. Keeping asking for answers if you need them! :) > > Richard > >> On Feb 7, 2022, at 8:21 PM, Benjamin Redelings >> wrote: >> >> So... I suspect that the best way forwards is just to read >> GHC/TC/Gen/Bind.hs and make notes on all the functions.  That is what >> I am doing. >> >> -BenRI >> >> On 1/31/22 2:50 PM, Benjamin Redelings wrote: >>> >>> Hi, >>> >>> I am trying to understand (and implement) how Haskell handles >>> explicit type signatures. Specifically, I'm trying to understand how >>> explicit type signatures interact with wrappers. >>> >>> 1. Is there any paper or documentation that explains wrappers and/or >>> explicit type signatures in detail?  There are some non-obvious >>> details regarding wrappers, such as using eliminating type arguments >>> by supplying the Any type as an argument... >>> >>> 2. Do explicit type signatures impose any unification constraints, >>> or can they be thought of entirely in terms of wrappers? >>> >>> For example, if we have >>> >>> g :: Int -> Int >>> (f,g) = (\x ->x, f) >>> >>> then the signature for g is added to the environment when typing the >>> right-hand-side. >>> >>> One way that this could be handled is: >>> >>> (i) typecheck rhs -> rhs_type >>> >>> (ii) generate type of lhs with fresh variables for every binder -> >>> lhs_type = (a,b) >>> >>> (iii) unify(lhs_type, rhs_type) >>> >>> (iv) do one-way unification: match(inferred-type-of-g, >>> explicit-type-for-g) >>> >>> Is this correct?  Step (iv), the way that I have written it, would >>> impose unification constraints. >>> >>> Without considering the type signature, we would have >>> >>> { f_mono :: a -> a, g_mono :: a -> a} >>> >>> If we just use wrappers to impose the explict type, it seems like we >>> would get something like >>> >>> let tup = /\a.let {(f:a,g:a) = (\x:a -> x:a, f::a->a) >>> f = /\a.case tup a of (f,g) -> f >>> g = case tup @Int of (f,g) -> g >>> >>> where f :: forall a.a ->a and g :: Int -> Int. >>> >>> THIH seems to imply that type signatures are merely checked: no >>> unification constraints are imposed (I think).  However, ghc reports >>> f :: Int -> Int. >>> >>> I apologize if this is a dumb question.  I have found the definition >>> of HsWrapper in ghc/compiler/GHC/Tc/Types/Evidence.hs, but I am >>> still struggling a bit. >>> >>> thanks! >>> >>> -BenRI >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 lists at richarde.dev Tue Feb 22 20:54:54 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 22 Feb 2022 20:54:54 +0000 Subject: [Haskell-cafe] Explicit type signatures and wrappers / impedance-matching In-Reply-To: References: <69bf561f-2fea-d1dd-4485-75e7dcbe28de@gmail.com> <010f017eff5d1ae7-74e6accb-7e6c-45a8-8096-33fe9d9e64c3-000000@us-east-2.amazonses.com> Message-ID: <010f017f233734c8-8d826fa9-0dd0-428b-b40f-60baa9821aeb-000000@us-east-2.amazonses.com> > On Feb 22, 2022, at 2:42 PM, Benjamin Redelings wrote: > Then, in order to handle the difference between these two types, we call `tcSubTypeSigma actual_type more_quantified_type`, which > > ... It may (I think) eliminate predicates by defaulting, and it can eliminate types by substituting an ANY type, at least sometimes. This wrapper is stored inside abe_wrap field of ABE objects, inside the abs_exports field of the AbsBinds. > > I don't think this step ever does defaulting or uses Any. > > II. I am still not completely sure how the wrapper is actually applied in code generation, or how the wrapper is computed from the two types. But, I'm not quite done reading yet. > > For example, in the case above, suppose that `tuple` represents all combined binders inside the AbsBinds, and is quantified by ALL the type variables and ALL the (given) dictionaries. One approach would be something like: > > tuple = /\a./\b.\(dNum :: Num b). let ...CODE... in (f,g) > > f' = /\a./\b.\(dNum :: b). case (tuple @a @b dNum) of f > > f = /\a. f' @a @ANY dNum = apply wrapper to f' ? > > In that approach, then we would FIRST extract an "f'" from the tuple without applying any wrapper. Then, SECOND, we would SECOND apply the wrapper to f' to get f. > > I don't follow here -- sorry. I think you have some typos in your example (for example, there is no -> after 'of' in your 'case', and I see two =s on the last line), and I can't quite figure out what you mean. > > III. I am also still working through tcMonoBinds. I'm curious what happens in a pattern binding, when the pattern has a type signature with predicates: > > f:: forall a.Num a -> a->a->a > > (f,g) = ...rhs... > > It looks like the type signature for gets instantiated on the LHS, and.... I presume the predicate Num a is added to the local instance environment, just like if f was instantiated on the RHS? I will think about this more... > Not sure what you mean here. :( For a pattern binding, I'm pretty sure all the signature does is set what will happen if GHC looks up a symbol's type when processing the RHS. > > Anyway, thanks for the encouragement. I am not stuck, yet... > > All this does make me think that, perhaps, some kind of updated version of Typing Haskell in Haskell would be appropriate. I'm not sure how much of this is in the Report, either. > Little, if any, of this is in the Report, and it's unclear to me whether that's a good or a bad thing. An up-to-date description of all of this would be lovely! But is it worth it? Especially when this all will continue to change? Keep plugging away! You're definitely working in the right direction. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.wehr at gmail.com Wed Feb 23 11:19:15 2022 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Wed, 23 Feb 2022 12:19:15 +0100 Subject: [Haskell-cafe] 2nd Call for Participation: Virtual BOB 2022 (March 11) Message-ID: ========================================================================= BOB 2022 Conference “What happens if we simply use what’s best?” March 11, 2022, online 0100+UTC https://bobkonf.de/2022/ Program: https://bobkonf.de/2022/program.html Registration: https://bobkonf.de/2022/program.html ========================================================================= BOB conference is a place for developers, architects, and decision-makers to explore technologies beyond the mainstream in software development and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experience. The program features 14 talks and 8 tutorials on current topics: https://bobkonf.de/2022/program.html The subject range includes functional programming, effects, distributed programming, formal methods, generative art, event-driven systems, the human brain, Haskell, Python, Scala, Lua, Clojure, Erlang, Nix, and others. Derek Dreyer will give the keynote talk. Due to COVID-related risks, BOB will take place online, entirely within a Gather Town virtual world. We've placed special emphasis on enabling social, casual interaction, in addition to our stellar program. Registration is open - student tickets are €10, regular tickets are €30. As always, grants are available for members of groups underrepresented in tech: https://bobkonf.de/2022/program.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From yorgey at hendrix.edu Mon Feb 28 15:41:12 2022 From: yorgey at hendrix.edu (Brent Yorgey) Date: Mon, 28 Feb 2022 09:41:12 -0600 Subject: [Haskell-cafe] Initiating package takeover: size-based and testing-feat Message-ID: <87wnhfngmf.fsf@hendrix.edu> Hi everyone, Wen Kokke (cc'd) and I intend to take over maintainership of the size-based and testing-feat packages. I have tried to contact the current maintainer, Jonas Duregård (also cc'd), multiple times over the past year via both GitHub and email. I have both requested new releases incorporating existing PRs, and also offered to help with maintenance, but I have not received any response. I don't intend to do do anything fancy with the packages or make major changes, but they are nice packages and I would like to see them able to build on newer GHCs. Happy to hear any comments or feedback (especially from Jonas), but in any case, this email serves as official notice of our intention. If I still haven't heard from Jonas after a while I will proceed with contacting the Hackage admins to request a transfer of maintainership. -Brent