From cdsmith at gmail.com Mon Jun 1 15:37:12 2020 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 1 Jun 2020 11:37:12 -0400 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment Message-ID: Hello, I'm the maintainer of CodeWorld. In addition to the K-12 education uses, CodeWorld provides a web-based programming environment at http://code.world/haskell to write short snippets of Haskell and share it easily with others. I am trying to ensure that as many interesting Haskell libraries as possible are available on the platform. If you are interested in ensuring that a library is included, whether you're the maintainer or just am interested user, please take a look at the package list at https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal Packages that fit here are: 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web browser, there is no filesystem, for example. 2. Do not rely on native libraries, or have dependencies that do. This all depends on the library building with GHCJS. 3. Do not require use of Template Haskell by clients. It's okay if your package needs template Haskell to build, but people using your library via CodeWorld cannot yet use TH themselves. If you have a library you'd like to see included that's not in that list, please let me know, either with just an email or with a pull request at the GitHub link above. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From meng.wang at bristol.ac.uk Mon Jun 1 17:22:24 2020 From: meng.wang at bristol.ac.uk (Meng Wang) Date: Mon, 1 Jun 2020 17:22:24 +0000 Subject: [Haskell-cafe] Postdoc position at University of Bristol in functional programming Message-ID: <3C08AF22-5E5D-4429-B45F-600C89A4991D@bristol.ac.uk> Dear Haskellers, The programming languages group at Bristol has an open postdoc position in the area of functional programming. Haskell programmers are particularly welcome! Best regards, Meng Meng Wang, PhD (Oxon) Senior Lecturer in Programming Languages International Director, SCEEM School We are looking for an enthusiastic, self-motivated individual to contribute to an EPSRC-funded project, which aims to design programming languages that guarantee strong properties, and the application of them. The post holder will be based in the programming languages group at the University of Bristol Computer Science Department, which consists of three academics, two PDRAs, and a number of PhD students. You will also be working with a network of partners from Oxford, Edinburgh, Kent, Tohoku Japan, Chalmers Sweden, and industrial partner DFINITY Foundations providing expertise on WebAssembly. The University of Bristol is a world-leading university (consistently ranked top 50 in the world by QS) with an exceptionally strong Faculty of Engineering (which the Department of Computer Science is part of). Bristol is a mid-sized city and is widely considered as one of the best places to live in the country. You should have a PhD in programming languages, or a closely related field. This post is available immediately and is offered on a full-time based for an initial term of three years. Appointment at a higher salary point than grade I is possible based on relevant experience. Informal enquiries should be addressed to Dr. Meng Wang (meng.wang at bristol.ac.uk) For more details about this position, please see: http://www.bristol.ac.uk/jobs/find/details.html?nPostingID=68914&nPostingTargetID=186274&option=28&sort=DESC&respnr=2&ID=Q50FK026203F3VBQBV7V77V83&Resultsperpage=10&lg=UK&mask=uobext Deadline: 28 Jun 2020 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Mon Jun 1 18:29:32 2020 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 1 Jun 2020 14:29:32 -0400 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: References: Message-ID: <20200601182932.GM48101@straasha.imrryr.org> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: > https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal > > Packages that fit here are: > > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web > browser, there is no filesystem, for example. I assume this also precludes network I/O? > 2. Do not rely on native libraries, or have dependencies that do. This all > depends on the library building with GHCJS. I guess this also excludes `bytestring`, which uses memcpy(), memchr(), and writes directly allocated memory? -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation for GHC -- mallocByteString :: Int -> IO (ForeignPtr a) mallocByteString = mallocPlainForeignPtrBytes and all of its dependencies? > 3. Do not require use of Template Haskell by clients. It's okay if your > package needs template Haskell to build, but people using your library via > CodeWorld cannot yet use TH themselves. Is it that Template Haskell features in modules are not available to users, or that modules that export even "inessential" TH features are precluded. For example, can the platform support a module that exports a convenience TH "splice", if the same can be done slightly less conveniently (e.g. run-time, rather than compile-time error checks) at runtime via alternative functions? [ My current project does network I/O, uses `bytestring`, and provides TH-splices for two types of compile-time validated literals, so I would assume is a non-starter on all three counts. ] -- Viktor. From cdsmith at gmail.com Mon Jun 1 23:07:38 2020 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 1 Jun 2020 19:07:38 -0400 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: <20200601182932.GM48101@straasha.imrryr.org> References: <20200601182932.GM48101@straasha.imrryr.org> Message-ID: Thanks for the questions. 1. Yes, network I/O is excluded. The only real exceptions here are stdin/err/out, and code that's specifically written to work in GHCJS, such as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in ghcjs-base. 2. Depending on bytestring is fine, because it has a shim that makes it work with GHCJS. I believe https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list of shimmed libraries that you don't need to worry about depending on. 3. Exporting inessential TH features is fine. It's just that people attempting to use your library via CodeWorld won't be able to use them, since CodeWorld's web interface will refuse to build anything that enables Template Haskell. It looks like your project is completely excluded only because of the network I/O. If the network I/O is not necessary and you could exclude the dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if impl(ghcjs)" in the cabal file, then it could still work. But, of course, of the network I/O is the whole point, then it's not going to work out. JavaScript On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni wrote: > On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: > > > > https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal > > > > Packages that fit here are: > > > > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web > > browser, there is no filesystem, for example. > > I assume this also precludes network I/O? > > > 2. Do not rely on native libraries, or have dependencies that do. This > all > > depends on the library building with GHCJS. > > I guess this also excludes `bytestring`, which uses memcpy(), memchr(), > and writes directly allocated memory? > > -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation for > GHC > -- > mallocByteString :: Int -> IO (ForeignPtr a) > mallocByteString = mallocPlainForeignPtrBytes > > and all of its dependencies? > > > 3. Do not require use of Template Haskell by clients. It's okay if your > > package needs template Haskell to build, but people using your library > via > > CodeWorld cannot yet use TH themselves. > > Is it that Template Haskell features in modules are not available to > users, or that modules that export even "inessential" TH features are > precluded. > > For example, can the platform support a module that exports a > convenience TH "splice", if the same can be done slightly less > conveniently (e.g. run-time, rather than compile-time error checks) at > runtime via alternative functions? > > [ My current project does network I/O, uses `bytestring`, and provides > TH-splices for two types of compile-time validated literals, so I > would assume is a non-starter on all three counts. ] > > -- > Viktor. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Tue Jun 2 11:41:03 2020 From: agocorona at gmail.com (Alberto G. Corona) Date: Tue, 2 Jun 2020 13:41:03 +0200 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: References: <20200601182932.GM48101@straasha.imrryr.org> Message-ID: It is OK to include client-side Javascript frameworks? El mar., 2 jun. 2020 a las 1:09, Chris Smith () escribió: > Thanks for the questions. > > 1. Yes, network I/O is excluded. The only real exceptions here are > stdin/err/out, and code that's specifically written to work in GHCJS, such > as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in > ghcjs-base. > > 2. Depending on bytestring is fine, because it has a shim that makes it > work with GHCJS. I believe > https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list of > shimmed libraries that you don't need to worry about depending on. > > 3. Exporting inessential TH features is fine. It's just that people > attempting to use your library via CodeWorld won't be able to use > them, since CodeWorld's web interface will refuse to build anything that > enables Template Haskell. > > It looks like your project is completely excluded only because of the > network I/O. If the network I/O is not necessary and you could exclude the > dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if > impl(ghcjs)" in the cabal file, then it could still work. But, of course, > of the network I/O is the whole point, then it's not going to work out. > JavaScript > > On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni > wrote: > >> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: >> >> > >> https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal >> > >> > Packages that fit here are: >> > >> > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a web >> > browser, there is no filesystem, for example. >> >> I assume this also precludes network I/O? >> >> > 2. Do not rely on native libraries, or have dependencies that do. This >> all >> > depends on the library building with GHCJS. >> >> I guess this also excludes `bytestring`, which uses memcpy(), memchr(), >> and writes directly allocated memory? >> >> -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation >> for GHC >> -- >> mallocByteString :: Int -> IO (ForeignPtr a) >> mallocByteString = mallocPlainForeignPtrBytes >> >> and all of its dependencies? >> >> > 3. Do not require use of Template Haskell by clients. It's okay if your >> > package needs template Haskell to build, but people using your library >> via >> > CodeWorld cannot yet use TH themselves. >> >> Is it that Template Haskell features in modules are not available to >> users, or that modules that export even "inessential" TH features are >> precluded. >> >> For example, can the platform support a module that exports a >> convenience TH "splice", if the same can be done slightly less >> conveniently (e.g. run-time, rather than compile-time error checks) at >> runtime via alternative functions? >> >> [ My current project does network I/O, uses `bytestring`, and provides >> TH-splices for two types of compile-time validated literals, so I >> would assume is a non-starter on all three counts. ] >> >> -- >> 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. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Tue Jun 2 14:01:55 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Tue, 02 Jun 2020 10:01:55 -0400 Subject: [Haskell-cafe] Call for Submissions: ICFP Student Research Competition Message-ID: <5ed65bd369538_bbe12b160d7105a4274e1@homer.mail> ICFP 2020 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition, which will be held virtually alongside the main conference, in order to present their research and receive feedback from prominent members of the programming language research community. As usual, the SRC consists of three rounds: * Extended abstract * Poster session at ICFP 2020 * ICFP presentation To make the virtual competition fruitful, we will make sure that every student will have an "invited audience" during the poster session.  We are also planning to organize a social event for the students. Please visit the SRC website for updates. ### Important Dates Submissions due: 26 Jun 2020 (Friday) https://icfp20src.hotcrp.com Notification: 10 July 2020 (Friday) Conference: 23 August (Sunday) - 28 August (Friday) ### Submission Details Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition Program Committee: Chair: Youyou Cong (Tokyo Institute of Technology) Stephen Chang (University of Massachusetts Boston) Jesper Cockx (Delft University of Technology) Hsiang-Shang Ko (Institute of Information Science, Academia Sinica) Cyrus Omar (University of Michigan) From joshchia at gmail.com Wed Jun 3 07:04:59 2020 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Wed, 3 Jun 2020 15:04:59 +0800 Subject: [Haskell-cafe] How to compose operations in streaming Message-ID: I have a question about the streaming package. Let's say I have str :: Stream (Of String) IO () I want to putStrLn each element and then print the length of str, so I could do this: import Streaming import qualified Streaming.Prelude as SP doit :: Stream (Of String) IO () -> IO () doit str = do SP.mapM_ putStrLn str SP.length_ str >>= print However, will this result in doing 2 passes over str so that the memory requirement is not constant? If so, is there a simple way to combine the two actions so that only pass is needed? I could probably use a counter in a StateT but that's not really simple. More generally, are there techniques for combining folds like how one would with the foldl package? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Jun 3 07:22:08 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 3 Jun 2020 08:22:08 +0100 Subject: [Haskell-cafe] How to compose operations in streaming In-Reply-To: References: Message-ID: <20200603072208.GA14011@cloudinit-builder> On Wed, Jun 03, 2020 at 03:04:59PM +0800, ☂Josh Chia (謝任中) wrote: > I want to putStrLn each element and then print the length of str [...] > doit :: Stream (Of String) IO () -> IO () > doit str = > do > SP.mapM_ putStrLn str > SP.length_ str >>= print Isn't it SP.length_ (SP.mapM_ putStrLn str) >>= print From joshchia at gmail.com Wed Jun 3 11:38:51 2020 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Wed, 3 Jun 2020 19:38:51 +0800 Subject: [Haskell-cafe] How to compose operations in streaming In-Reply-To: <20200603072208.GA14011@cloudinit-builder> References: <20200603072208.GA14011@cloudinit-builder> Message-ID: The type of "SP.mapM_ putStrLn str" is IO (), so I don't think "SP.length_ (SP.mapM_ putStrLn str)" type checks, unless I'm somehow misreading your code. Anyway, I just realized I can use SP.copy: do l <- SP.mapM_ putStrLn $ SP.length_ $ SP.copy str print l "l <- SP.length_ $ SP.mapM_ putStrLn $ SP.copy str" also works. On Wed, Jun 3, 2020 at 3:23 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > On Wed, Jun 03, 2020 at 03:04:59PM +0800, ☂Josh Chia (謝任中) wrote: > > I want to putStrLn each element and then print the length of str > [...] > > doit :: Stream (Of String) IO () -> IO () > > doit str = > > do > > SP.mapM_ putStrLn str > > SP.length_ str >>= print > > Isn't it > > SP.length_ (SP.mapM_ putStrLn str) >>= print > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 guthrie at miu.edu Wed Jun 3 13:11:17 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Wed, 3 Jun 2020 13:11:17 +0000 Subject: [Haskell-cafe] Popularity?! Message-ID: Ah; finally in a toip-10 list! Not for love, but for money..?! The Stack Overflow 2020 Developer Survey's top 10 "top paying" languages: 1. Perl, $76,000 2. Scala, $76,000 3. Go, $74,000 4. Rust, $74,000 5. Ruby, $71,000 6. Bash/Shell/PowerShell, $65,000 7. Objective-C, $64,000 8. Haskell, $60,000 9. Julia, $59,000 10. Python, $59,000 Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Jun 3 13:27:55 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 3 Jun 2020 14:27:55 +0100 Subject: [Haskell-cafe] How to compose operations in streaming In-Reply-To: References: <20200603072208.GA14011@cloudinit-builder> Message-ID: <20200603132755.GC14011@cloudinit-builder> On Wed, Jun 03, 2020 at 07:38:51PM +0800, ☂Josh Chia (謝任中) wrote: > The type of "SP.mapM_ putStrLn str" is IO (), so I don't think "SP.length_ > (SP.mapM_ putStrLn str)" type checks, unless I'm somehow misreading your > code. I meant `SP.mapM`. This works: doit :: Stream (Of String) IO () -> IO () doit str = SP.length_ (SP.mapM putStrLn str) >>= Prelude.print `copy` is an intruiging solution though! From ruben.astud at gmail.com Wed Jun 3 15:44:55 2020 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Wed, 3 Jun 2020 11:44:55 -0400 Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: Message-ID: On 03-06-20 09:11, Gregory Guthrie wrote: > The Stack Overflow 2020 Developer Survey's top 10 "top paying" languages Can you provide a link? This is great. -- -- Rubén -- pgp: 4EE9 28F7 932E F4AD -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From cdsmith at gmail.com Wed Jun 3 15:51:31 2020 From: cdsmith at gmail.com (Chris Smith) Date: Wed, 3 Jun 2020 11:51:31 -0400 Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: Message-ID: https://insights.stackoverflow.com/survey/2020#top-paying-technologies is the link. Honestly, though, the salary numbers seem so wrong that I find it hard to take them seriously. I imagine what's going on here is that salaries vary mainly by location. Technologies that have not been adopted in regions where salaries are lower will show up at the top of this list. It says nothing about how salaries in any given area will compare. Interpreting correlations like this is tricky. On Wed, Jun 3, 2020 at 11:45 AM Ruben Astudillo wrote: > On 03-06-20 09:11, Gregory Guthrie wrote: > > The Stack Overflow 2020 Developer Survey's top 10 "top paying" languages > > Can you provide a link? This is great. > > -- > -- Rubén > -- pgp: 4EE9 28F7 932E F4AD > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Jun 3 16:00:57 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 3 Jun 2020 17:00:57 +0100 Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: Message-ID: <20200603160057.GD14011@cloudinit-builder> On Wed, Jun 03, 2020 at 11:51:31AM -0400, Chris Smith wrote: > https://insights.stackoverflow.com/survey/2020#top-paying-technologies is > the link. Honestly, though, the salary numbers seem so wrong that I find > it hard to take them seriously. I imagine what's going on here is that > salaries vary mainly by location. Technologies that have not been adopted > in regions where salaries are lower will show up at the top of this list. > It says nothing about how salaries in any given area will compare. > Interpreting correlations like this is tricky. Perl as top-paying programming language, and Bash/Shell/PowerShell as number 6 are particularly hard to believe. From lemming at henning-thielemann.de Wed Jun 3 16:30:58 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 3 Jun 2020 18:30:58 +0200 (CEST) Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: Message-ID: On Wed, 3 Jun 2020, Chris Smith wrote: > https://insights.stackoverflow.com/survey/2020#top-paying-technologies  > is the link.  Honestly, though, the salary numbers seem so wrong that I > find it hard to take them seriously.  I imagine what's going on here is > that salaries vary mainly by location.  Technologies that have not been > adopted in regions where salaries are lower will show up at the top of > this list.  It says nothing about how salaries in any given area will > compare.  Interpreting correlations like this is tricky. Averages are hard to interpret, if you do not know the variance. It would help if they added the standard deviation to each of the salary average. From guthrie at miu.edu Wed Jun 3 16:33:02 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Wed, 3 Jun 2020 16:33:02 +0000 Subject: [Haskell-cafe] Popularity?! In-Reply-To: <20200603160057.GD14011@cloudinit-builder> References: <20200603160057.GD14011@cloudinit-builder> Message-ID: Yep. But hey, why doubt good PR! Even COBOL jobs are high paying recently. Nonetheless, This is (real) data from a survey, from one place where language techies hang-out. Not definitive, but interesting. Haskell gets such little respect and good PR, anything is nice to see. And I think that anyone who has to program in Perl deserves higher pay than ... :-) Don't take the numbers "seriously", just enjoy. Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- -----Original Message----- From: Haskell-Cafe On Behalf Of Tom Ellis Sent: Wednesday, June 3, 2020 11:01 AM To: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Popularity?! On Wed, Jun 03, 2020 at 11:51:31AM -0400, Chris Smith wrote: > https://insights.stackoverflow.com/survey/2020#top-paying-technologies > is the link. Honestly, though, the salary numbers seem so wrong that > I find it hard to take them seriously. I imagine what's going on here > is that salaries vary mainly by location. Technologies that have not > been adopted in regions where salaries are lower will show up at the top of this list. > It says nothing about how salaries in any given area will compare. > Interpreting correlations like this is tricky. Perl as top-paying programming language, and Bash/Shell/PowerShell as number 6 are particularly hard to believe. _______________________________________________ From migmit at gmail.com Wed Jun 3 17:42:52 2020 From: migmit at gmail.com (MigMit) Date: Wed, 3 Jun 2020 19:42:52 +0200 Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: <20200603160057.GD14011@cloudinit-builder> Message-ID: Isn't it self-reported? > On 3 Jun 2020, at 18:33, Gregory Guthrie wrote: > > Yep. But hey, why doubt good PR! > > Even COBOL jobs are high paying recently. > > Nonetheless, This is (real) data from a survey, from one place where language techies hang-out. Not definitive, but interesting. Haskell gets such little respect and good PR, anything is nice to see. > > And I think that anyone who has to program in Perl deserves higher pay than ... :-) > > Don't take the numbers "seriously", just enjoy. > > Dr. Gregory Guthrie > Maharishi International University > ---------------------------------------------------------------- > > -----Original Message----- > From: Haskell-Cafe On Behalf Of Tom Ellis > Sent: Wednesday, June 3, 2020 11:01 AM > To: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Popularity?! > > On Wed, Jun 03, 2020 at 11:51:31AM -0400, Chris Smith wrote: >> https://insights.stackoverflow.com/survey/2020#top-paying-technologies >> is the link. Honestly, though, the salary numbers seem so wrong that >> I find it hard to take them seriously. I imagine what's going on here >> is that salaries vary mainly by location. Technologies that have not >> been adopted in regions where salaries are lower will show up at the top of this list. >> It says nothing about how salaries in any given area will compare. >> Interpreting correlations like this is tricky. > > Perl as top-paying programming language, and Bash/Shell/PowerShell as number 6 are particularly hard to believe. > _______________________________________________ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 will.song at trailofbits.com Wed Jun 3 19:15:52 2020 From: will.song at trailofbits.com (Will Song) Date: Wed, 3 Jun 2020 14:15:52 -0500 Subject: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't Message-ID: <29FB7A51-9145-4DD6-8B1A-BE2CBA1D2905@trailofbits.com> Hey all, I am experiencing some weird build issues with respect to GHC. I would like to mention that what I am doing is somewhat non-standard but theoretically I think it should work. I am developing a Haskell program which depends on a library, hevm, with several external library dependencies, libsecp256k1 and libff. Since these libraries are a bit of a pain to install by default in the macOS ecosystem, having no brew packages, my plan is to statically link these libraries into the release builds. To start off this task, I have simply moved the dynamic libraries for secp256k1 to another location, e.g. # mv /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm appears to work as expected. It compiles fine, and otool reports the following. % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) libff.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0) We can check libHShevm... as well and it does not depend on the secp256k1 dylib anymore. However, moving back onto my program, the build fails. % stack build Building all executables for `echidna' once. After a successful build of all of them, only specified executables will be rebuilt. echidna-1.5.0: configure (lib + exe) Configuring echidna-1.5.0... Warning: 'ghc-options: -threaded' has no effect for libraries. It should only be used for executables. echidna-1.5.0: build (lib + exe) Preprocessing library for echidna-1.5.0.. Building library for echidna-1.5.0.. [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) : can't load .so/.DLL for: libsecp256k1.dylib (dlopen(libsecp256k1.dylib, 5): image not found) -- While building package echidna-1.5.0 using: /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Would anyone happen to know why this failure is occurring? We have no C sources that would create unresolved references to this library, all the code is Haskell. My understanding is that ghc should end up using the static variant now that there is no dynamic library but clearly this intuition is misguided. From michael at orlitzky.com Wed Jun 3 16:11:58 2020 From: michael at orlitzky.com (Michael Orlitzky) Date: Wed, 3 Jun 2020 12:11:58 -0400 Subject: [Haskell-cafe] Popularity?! In-Reply-To: References: Message-ID: <1a86d0da-52c5-1df9-a3f9-2d40e44aef32@orlitzky.com> On 6/3/20 11:51 AM, Chris Smith wrote: > https://insights.stackoverflow.com/survey/2020#top-paying-technologies  > is the link.  Honestly, though, the salary numbers seem so wrong that I > find it hard to take them seriously.  I imagine what's going on here is > that salaries vary mainly by location.  Technologies that have not been > adopted in regions where salaries are lower will show up at the top of > this list.  It says nothing about how salaries in any given area will > compare.  Interpreting correlations like this is tricky. Measuring quality by salary a priori misses the point. If you control for everything else, the numbers will go up as the language gets less desirable to work with. To say nothing of the fact that a language survey on stack overflow is like asking a fish if it prefers Newton or Leibniz notation. From jinwoo68 at gmail.com Thu Jun 4 18:51:04 2020 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Thu, 4 Jun 2020 11:51:04 -0700 Subject: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't In-Reply-To: <29FB7A51-9145-4DD6-8B1A-BE2CBA1D2905@trailofbits.com> References: <29FB7A51-9145-4DD6-8B1A-BE2CBA1D2905@trailofbits.com> Message-ID: Does your code use TemplateHaskell? In that case, the compiler will try to load the library for the compile-time computation. On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hey all, I am experiencing some weird build issues with respect to GHC. I > would like to mention that what I am doing is somewhat non-standard but > theoretically I think it should work. > > I am developing a Haskell program which depends on a library, hevm, with > several external library dependencies, libsecp256k1 and libff. Since these > libraries are a bit of a pain to install by default in the macOS ecosystem, > having no brew packages, my plan is to statically link these libraries into > the release builds. To start off this task, I have simply moved the dynamic > libraries for secp256k1 to another location, e.g. # mv > /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm > appears to work as expected. It compiles fine, and otool reports the > following. > > % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm > .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current > version 1281.0.0) > libff.dylib (compatibility version 0.0.0, current version 0.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current > version 800.7.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current > version 1.2.11) > /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, > current version 5.4.0) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current > version 7.0.0) > /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current > version 2.0.0) > > We can check libHShevm... as well and it does not depend on the secp256k1 > dylib anymore. > > However, moving back onto my program, the build fails. > > % stack build > Building all executables for `echidna' once. After a successful build of > all of them, only specified executables will be rebuilt. > echidna-1.5.0: configure (lib + exe) > Configuring echidna-1.5.0... > Warning: 'ghc-options: -threaded' has no effect for libraries. It should > only > be used for executables. > echidna-1.5.0: build (lib + exe) > Preprocessing library for echidna-1.5.0.. > Building library for echidna-1.5.0.. > [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, > .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) > [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, > .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) > : can't load .so/.DLL for: libsecp256k1.dylib > (dlopen(libsecp256k1.dylib, 5): image not found) > > -- While building package echidna-1.5.0 using: > > /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 > --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna > exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file > -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > > Would anyone happen to know why this failure is occurring? We have no C > sources that would create unresolved references to this library, all the > code is Haskell. My understanding is that ghc should end up using the > static variant now that there is no dynamic library but clearly this > intuition is misguided. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 will.song at trailofbits.com Thu Jun 4 18:58:02 2020 From: will.song at trailofbits.com (Will Song) Date: Thu, 4 Jun 2020 13:58:02 -0500 Subject: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't In-Reply-To: References: <29FB7A51-9145-4DD6-8B1A-BE2CBA1D2905@trailofbits.com> Message-ID: The 2nd module to compile uses TemplateHaskell and that's where stack build will fail. However, trying to load Echidna.Mutator into ghci will also fail for the same reason, but it compiles just fine. The import list is pasted below. {-# LANGUAGE FlexibleContexts #-} module Echidna.Mutator where import Control.Monad.Random.Strict (fromList, MonadRandom, getRandomR) import Data.Maybe (maybe) import qualified Data.ListLike as LL > On Jun 4, 2020, at 1:51 PM, Jinwoo Lee wrote: > > Does your code use TemplateHaskell? In that case, the compiler will try to load the library for the compile-time computation. > > > On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe > wrote: > Hey all, I am experiencing some weird build issues with respect to GHC. I would like to mention that what I am doing is somewhat non-standard but theoretically I think it should work. > > I am developing a Haskell program which depends on a library, hevm, with several external library dependencies, libsecp256k1 and libff. Since these libraries are a bit of a pain to install by default in the macOS ecosystem, having no brew packages, my plan is to statically link these libraries into the release builds. To start off this task, I have simply moved the dynamic libraries for secp256k1 to another location, e.g. # mv /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm appears to work as expected. It compiles fine, and otool reports the following. > > % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm > .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) > libff.dylib (compatibility version 0.0.0, current version 0.0.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) > /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0) > > We can check libHShevm... as well and it does not depend on the secp256k1 dylib anymore. > > However, moving back onto my program, the build fails. > > % stack build > Building all executables for `echidna' once. After a successful build of all of them, only specified executables will be rebuilt. > echidna-1.5.0: configure (lib + exe) > Configuring echidna-1.5.0... > Warning: 'ghc-options: -threaded' has no effect for libraries. It should only > be used for executables. > echidna-1.5.0: build (lib + exe) > Preprocessing library for echidna-1.5.0.. > Building library for echidna-1.5.0.. > [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) > [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) > : can't load .so/.DLL for: libsecp256k1.dylib (dlopen(libsecp256k1.dylib, 5): image not found) > > -- While building package echidna-1.5.0 using: > /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > > Would anyone happen to know why this failure is occurring? We have no C sources that would create unresolved references to this library, all the code is Haskell. My understanding is that ghc should end up using the static variant now that there is no dynamic library but clearly this intuition is misguided. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 will.song at trailofbits.com Thu Jun 4 19:32:05 2020 From: will.song at trailofbits.com (Will Song) Date: Thu, 4 Jun 2020 14:32:05 -0500 Subject: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't In-Reply-To: References: <29FB7A51-9145-4DD6-8B1A-BE2CBA1D2905@trailofbits.com> Message-ID: <8101FC38-3335-480F-9649-BF66AC3DF3FC@trailofbits.com> Is the shared library of the dependency that has it statically linked in not enough? At this point I am also unsure how ghc is able to determine which library to dynamically load. > On Jun 4, 2020, at 2:03 PM, Brandon Allbery wrote: > > ghci loads dynamically for the same reason TH does: you would > otherwise need a ghc linked against your static library. (You could > try -fobject-code and/or an explicit -l option for the library with > ghci.) > > On 6/4/20, Will Song via Haskell-Cafe > wrote: >> The 2nd module to compile uses TemplateHaskell and that's where stack build >> will fail. However, trying to load Echidna.Mutator into ghci will also fail >> for the same reason, but it compiles just fine. The import list is pasted >> below. >> >> {-# LANGUAGE FlexibleContexts #-} >> >> module Echidna.Mutator where >> >> import Control.Monad.Random.Strict (fromList, MonadRandom, getRandomR) >> import Data.Maybe (maybe) >> >> import qualified Data.ListLike as LL >> >>> On Jun 4, 2020, at 1:51 PM, Jinwoo Lee wrote: >>> >>> Does your code use TemplateHaskell? In that case, the compiler will try to >>> load the library for the compile-time computation. >>> >>> >>> On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe >>> >> wrote: >>> Hey all, I am experiencing some weird build issues with respect to GHC. I >>> would like to mention that what I am doing is somewhat non-standard but >>> theoretically I think it should work. >>> >>> I am developing a Haskell program which depends on a library, hevm, with >>> several external library dependencies, libsecp256k1 and libff. Since these >>> libraries are a bit of a pain to install by default in the macOS >>> ecosystem, having no brew packages, my plan is to statically link these >>> libraries into the release builds. To start off this task, I have simply >>> moved the dynamic libraries for secp256k1 to another location, e.g. # mv >>> /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm >>> appears to work as expected. It compiles fine, and otool reports the >>> following. >>> >>> % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm >>> .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1281.0.0) >>> libff.dylib (compatibility version 0.0.0, current version 0.0.0) >>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current >>> version 800.7.0) >>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current >>> version 1.2.11) >>> /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, >>> current version 5.4.0) >>> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current >>> version 7.0.0) >>> /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current >>> version 2.0.0) >>> >>> We can check libHShevm... as well and it does not depend on the secp256k1 >>> dylib anymore. >>> >>> However, moving back onto my program, the build fails. >>> >>> % stack build >>> Building all executables for `echidna' once. After a successful build of >>> all of them, only specified executables will be rebuilt. >>> echidna-1.5.0: configure (lib + exe) >>> Configuring echidna-1.5.0... >>> Warning: 'ghc-options: -threaded' has no effect for libraries. It should >>> only >>> be used for executables. >>> echidna-1.5.0: build (lib + exe) >>> Preprocessing library for echidna-1.5.0.. >>> Building library for echidna-1.5.0.. >>> [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) >>> [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) >>> : can't load .so/.DLL for: libsecp256k1.dylib >>> (dlopen(libsecp256k1.dylib, 5): image not found) >>> >>> -- While building package echidna-1.5.0 using: >>> >>> /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 >>> --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna >>> exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file >>> -fdiagnostics-color=always" >>> Process exited with code: ExitFailure 1 >>> >>> Would anyone happen to know why this failure is occurring? We have no C >>> sources that would create unresolved references to this library, all the >>> code is Haskell. My understanding is that ghc should end up using the >>> static variant now that there is no dynamic library but clearly this >>> intuition is misguided. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> > >>> Only members subscribed via the mailman list are allowed to post. >> >> > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Fri Jun 5 11:05:24 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 5 Jun 2020 23:05:24 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a 'publication' and is not by Dijkstra, right? It's taking some of the ideas from Dijkstra's EWD1300, but misapplying them to Haskell in a rather badly-informed way. After all, Haskell already has a 'Application Operator' spelled ($), which is perfectly first-class and with which you can do the equational reasoning (with lambdas) that the doco is talking about. Also it doesn't seem to know Haskellers very well; nor Dijkstra's well-known support for Haskell in education. There's other bits and pieces of 'Publications' on that the-magus site; including spoofs of Dijkstra which can't even spell his first name right. I rather suspect the ewd.pdf is a spoof that didn't turn out very funny. So altogether it's a couple of dudes shooting the breeze. AntC > On 4/9/19 11:09 AM, Michael Orlitzky wrote: > *>> On 4/9/19 10:41 AM, jaro.reinders at gmail.com wrote: *>>* I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html *>>> >> * Thank you, this is obviously also relevant, but it's not the one I'm * >> * remembering. The notation is the same, though, so this explains what I'm * >> * looking for (and is also an interesting read). * > After the Dijkstra hint, I was able to track it down: > http://www.the-magus.in/Publications/ewd.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Fri Jun 5 11:43:40 2020 From: michael at orlitzky.com (Michael Orlitzky) Date: Fri, 5 Jun 2020 07:43:40 -0400 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: <5fdc308a-483d-1aff-d21c-5122cecb0d5c@orlitzky.com> On 6/5/20 7:05 AM, Anthony Clayden wrote: > Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a > 'publication' and is not by Dijkstra, right? Sure. > It's taking some of the ideas from Dijkstra's EWD1300, but misapplying > them to Haskell in a rather badly-informed way. I wouldn't say so, for reasons explained below. > After all, Haskell already has a 'Application Operator' spelled ($), > which is perfectly first-class and with which you can do the equational > reasoning (with lambdas) that the doco is talking about. The thread that I was recalling (Language complexity & beginners) can be found here, https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt and it started as a discussion about the use of ($) for function application. Namely, what should its type be? Whatever you answer is going to be wrong. The root of that problem is that ($) is itself a function, and you can't insist on using a function to apply function application without risk of severe injury. So the only way to even use ($) is via the true function application syntax, namely whitespace. But whitespace as function application syntax has its own problems. So we want something like ($), but we want it to be *syntax*, and it should take the place of " " rather than supplement it. That's the argument those guys (and the paper Ben suggested) are trying to make. > Also it doesn't seem to know Haskellers very well; nor Dijkstra's > well-known support for Haskell in education. > > There's other bits and pieces of 'Publications' on that the-magus site; > including spoofs of Dijkstra which can't even spell his first name > right. I rather suspect the ewd.pdf is a spoof that didn't turn out very > funny. So altogether it's a couple of dudes shooting the breeze. These all seem pretty irrelevant to the point being made, which I think has merit. This is all just a language design curiosity to me, though, and I'm not looking to start a new religious war until some of the present ones are resolved. From victor.lanvin at irif.fr Sat Jun 6 17:20:53 2020 From: victor.lanvin at irif.fr (Victor Lanvin) Date: Sat, 6 Jun 2020 19:20:53 +0200 Subject: [Haskell-cafe] ICFP 2020: First Call for Students Volunteers Message-ID: Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'20 FIRST CALL FOR STUDENT VOLUNTEERS ========================================= ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'20 will take place **virtually** from Sun 23 - Fri 28 August 2020. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2020 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing the various slack channels and social activities. To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://forms.gle/TRN9LxWWkfR3sHtN6 The permanent link to this form can be found on the official conference website. https://icfp20.sigplan.org/track/icfp-2020-student-volunteering There are two rounds of calls with the following deadlines: * deadline for first round: June 21st, 2020 AoE (notification: June 23rd) * deadline for second round: July 19th, 2020 AoE (notification: July 21th) **Please note that the first deadline is in two weeks only!** Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. If your application is not accepted in the first round, it will automatically be included in the 2nd round. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hilco.wijbenga at gmail.com Sat Jun 6 20:34:37 2020 From: hilco.wijbenga at gmail.com (Hilco Wijbenga) Date: Sat, 6 Jun 2020 13:34:37 -0700 Subject: [Haskell-cafe] Building Asterius locally Message-ID: Hi all, Has anyone tried building Asterius (https://asterius.netlify.app/building.html)? I'm stuck because GHC/GCC can't find binaryen-c.h which is available in /usr/include/binaryen. If I add a symbolic link in /usr/include to binaryen-c.h then this one is found but the next one isn't. Obviously, I don't want to link to every binaryen header file like that. binaryen > /tmp/stack-b6b7026e470b48c5/binaryen-0.0.1.1/cbits/wrappers.c:1:10: error: binaryen > fatal error: binaryen-c.h: No such file or directory binaryen > 1 | #include binaryen > | ^~~~~~~~~~~~~~ binaryen > | binaryen > 1 | #include binaryen > | ^ binaryen > compilation terminated. binaryen > `gcc' failed in phase `C Compiler'. (Exit code: 1) I've tried adding include-dirs: /usr/include/binaryen in various places (in package.yaml) but that did not make any difference. In short, how do I make sure /usr/include/binaryen is part of the search path for C header files? Cheers, Hilco From david.feuer at gmail.com Sat Jun 6 21:32:17 2020 From: david.feuer at gmail.com (David Feuer) Date: Sat, 6 Jun 2020 17:32:17 -0400 Subject: [Haskell-cafe] Sliding windows for streaming Message-ID: I'm looking for a bit of help with a library design choice. The streaming package currently offers a slidingWindow function converting a stream into a stream of fixed-size windows of that stream[1]: slidingWindow :: Monad m => Int -- Window size -> Stream (Of a) m b -> Stream (Of (Seq a)) m b This is based directly on a similar function in conduit. Using a rough translation into the world of lists, we have slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] The awkward case where the stream is shorter than the window is handled by potentially producing a short sequence at the end: slidingWindow 3 "ab" = ["ab"] slidingWindow 3 "" = [""] I recently merged a pull request that adds variations on sliding window maxima and minima using what's apparently a "folklore" algorithm. For example slidingWindowMax 3 "abcbab" = "abcccb" This is basically like slidingWindowMax k = map maximum . slidingWindow k except that an empty stream doesn't yield anything, to avoid undefined values. The big advantage of these specialized functions is that rather than having to take a maximum over a sequence of length `k` at each step, they only do a constant (amortized) amount of work at each step. Nice! But not very general. Suppose we want to take a moving average of some sort, like an arithmetic mean, geometric mean, harmonic mean, or median? That thought leads quite naturally to a data structure: a queue holding elements of some arbitrary *semigroup* that efficiently keeps track of the sum of all the elements in the queue[2]. While the choice of *data structure* is moderately obvious, the choice of *sliding window function* is less so. The tricky bit is, again, what happens when the stream is too short for the window. If you work in the Sum semigroup and divide the results by the window size to get a moving average, then a too-short stream will give a (single) result that's completely wrong! Oof. What would be the most useful way to deal with this? The streams in `streaming` give us the option of producing a distinguished "return" value that comes after all the yields. Would it make sense to *return* the incomplete sum, and the number of elements that went into it, instead of *yielding* it into the result stream? That seems flexible, but maybe a tad annoying. What do y'all think? [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelude.html#v:slidingWindow [2] See the AnnotatedQueue in https://github.com/haskell-streaming/streaming/pull/99/files which basically modifies Okasaki's implicit queues using some of the basic ideas that appear in Hinze-Paterson 2–3 trees. From gershomb at gmail.com Sun Jun 7 00:06:54 2020 From: gershomb at gmail.com (Gershom B) Date: Sat, 6 Jun 2020 20:06:54 -0400 Subject: [Haskell-cafe] Sliding windows for streaming In-Reply-To: References: Message-ID: <2c70d187-3ac6-4cf1-8fba-75deb2a60556@Spark> On the specific question, the most general and natural thing to do, though not necessarily the most efficient, is to let users keep the length of items in each chunk as part of the semigroup. More broadly, not a direct answer, but you may be interested in section 13 (on windowed algorithms) of http://gbaz.github.io/slides/buildable2014.pdf The “parallelogram” algorithm there is quite general. The paper also covers other interesting streaming algorithms worth having around such as (generalized) maximum segment sum, and parallel prefix scan. -g On Jun 6, 2020, 5:33 PM -0400, David Feuer , wrote: > I'm looking for a bit of help with a library design choice. > > The streaming package currently offers a slidingWindow function > converting a stream into a stream of fixed-size windows of that > stream[1]: > > slidingWindow > :: Monad m > => Int -- Window size > -> Stream (Of a) m b > -> Stream (Of (Seq a)) m b > > This is based directly on a similar function in conduit. Using a rough > translation into the world of lists, we have > > slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] > > The awkward case where the stream is shorter than the window is > handled by potentially producing a short sequence at the end: > > slidingWindow 3 "ab" = ["ab"] > slidingWindow 3 "" = [""] > > I recently merged a pull request that adds variations on sliding > window maxima and minima using what's apparently a "folklore" > algorithm. For example > > slidingWindowMax 3 "abcbab" = "abcccb" > > This is basically like > > slidingWindowMax k = map maximum . slidingWindow k > > except that an empty stream doesn't yield anything, to avoid undefined values. > > The big advantage of these specialized functions is that rather than > having to take a maximum over a sequence of length `k` at each step, > they only do a constant (amortized) amount of work at each step. Nice! > But not very general. Suppose we want to take a moving average of some > sort, like an arithmetic mean, geometric mean, harmonic mean, or > median? That thought leads quite naturally to a data structure: a > queue holding elements of some arbitrary *semigroup* that efficiently > keeps track of the sum of all the elements in the queue[2]. > > While the choice of *data structure* is moderately obvious, the choice > of *sliding window function* is less so. The tricky bit is, again, > what happens when the stream is too short for the window. If you work > in the Sum semigroup and divide the results by the window size to get > a moving average, then a too-short stream will give a (single) result > that's completely wrong! Oof. What would be the most useful way to > deal with this? The streams in `streaming` give us the option of > producing a distinguished "return" value that comes after all the > yields. Would it make sense to *return* the incomplete sum, and the > number of elements that went into it, instead of *yielding* it into > the result stream? That seems flexible, but maybe a tad annoying. What > do y'all think? > > [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelude.html#v:slidingWindow > > [2] See the AnnotatedQueue in > https://github.com/haskell-streaming/streaming/pull/99/files which > basically modifies Okasaki's implicit queues using some of the basic > ideas that appear in Hinze-Paterson 2–3 trees. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jun 7 01:28:29 2020 From: david.feuer at gmail.com (David Feuer) Date: Sat, 6 Jun 2020 21:28:29 -0400 Subject: [Haskell-cafe] Sliding windows for streaming In-Reply-To: <2c70d187-3ac6-4cf1-8fba-75deb2a60556@Spark> References: <2c70d187-3ac6-4cf1-8fba-75deb2a60556@Spark> Message-ID: Unfortunately, much of that paper goes way over my head. On Sat, Jun 6, 2020, 8:07 PM Gershom B wrote: > On the specific question, the most general and natural thing to do, though > not necessarily the most efficient, is to let users keep the length of > items in each chunk as part of the semigroup. > > More broadly, not a direct answer, but you may be interested in section 13 > (on windowed algorithms) of http://gbaz.github.io/slides/buildable2014.pdf > > The “parallelogram” algorithm there is quite general. > > The paper also covers other interesting streaming algorithms worth having > around such as (generalized) maximum segment sum, and parallel prefix scan. > > - g > On Jun 6, 2020, 5:33 PM -0400, David Feuer , wrote: > > I'm looking for a bit of help with a library design choice. > > The streaming package currently offers a slidingWindow function > converting a stream into a stream of fixed-size windows of that > stream[1]: > > slidingWindow > :: Monad m > => Int -- Window size > -> Stream (Of a) m b > -> Stream (Of (Seq a)) m b > > This is based directly on a similar function in conduit. Using a rough > translation into the world of lists, we have > > slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] > > The awkward case where the stream is shorter than the window is > handled by potentially producing a short sequence at the end: > > slidingWindow 3 "ab" = ["ab"] > slidingWindow 3 "" = [""] > > I recently merged a pull request that adds variations on sliding > window maxima and minima using what's apparently a "folklore" > algorithm. For example > > slidingWindowMax 3 "abcbab" = "abcccb" > > This is basically like > > slidingWindowMax k = map maximum . slidingWindow k > > except that an empty stream doesn't yield anything, to avoid undefined > values. > > The big advantage of these specialized functions is that rather than > having to take a maximum over a sequence of length `k` at each step, > they only do a constant (amortized) amount of work at each step. Nice! > But not very general. Suppose we want to take a moving average of some > sort, like an arithmetic mean, geometric mean, harmonic mean, or > median? That thought leads quite naturally to a data structure: a > queue holding elements of some arbitrary *semigroup* that efficiently > keeps track of the sum of all the elements in the queue[2]. > > While the choice of *data structure* is moderately obvious, the choice > of *sliding window function* is less so. The tricky bit is, again, > what happens when the stream is too short for the window. If you work > in the Sum semigroup and divide the results by the window size to get > a moving average, then a too-short stream will give a (single) result > that's completely wrong! Oof. What would be the most useful way to > deal with this? The streams in `streaming` give us the option of > producing a distinguished "return" value that comes after all the > yields. Would it make sense to *return* the incomplete sum, and the > number of elements that went into it, instead of *yielding* it into > the result stream? That seems flexible, but maybe a tad annoying. What > do y'all think? > > [1] > https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelude.html#v:slidingWindow > > [2] See the AnnotatedQueue in > https://github.com/haskell-streaming/streaming/pull/99/files which > basically modifies Okasaki's implicit queues using some of the basic > ideas that appear in Hinze-Paterson 2–3 trees. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at gmail.com Sun Jun 7 02:46:45 2020 From: monkleyon at gmail.com (MarLinn) Date: Sun, 7 Jun 2020 04:46:45 +0200 Subject: [Haskell-cafe] Sliding windows for streaming In-Reply-To: References: Message-ID: Hi David, this problem reminds me a lot of a whole bunch of functions in OpenCV, the image manipulation library. Applying a function on every possible window of a specific size is one of the core tools in image analysis, either as a moving 1D-function applied to every row, or as a moving 2D-function on the whole image. So you might find a lot of inspiration there. Note that the applied function is called a "kernel" in that area. I haven't looked at the library in some time, but here are a few thoughts from what I remember: First of all, thinking about the end of the stream is a good idea. But what about the start of the stream? If the end of the stream can have non-full windows, why shouldn't the first window have exactly one element, the second have two, and so on until the window size is reached? Or something completely different? Now the most general idea for start and end of the stream would be to let the user decide. In OpenCV, there are several standard methods to handle image borders: cut all non-full windows (like you do at the start of the stream right now), repeat the value at the border to fill the gaps, take the min/max/average of the last full window to fill the gaps etc. Why not let the user provide two functions (Seq a → Seq a → Maybe (Seq a)). The first argument is the first/last "full" sequence, the second one is the non-full sequence to be filled, and the result is either a sequence of up to window-size or Nothing to represent that the result is to be cut. Let the user provide a record with these functions as settings, provide several reasonable defaults, and there you go. So in essence, what I'm suggesting is something like data WindowingSettings a x m = WindowingSettings     { windowStartHandler :: Seq a -> Seq a -> m (Maybe (Seq a))     , windowEndHandler   :: Seq a -> Seq a -> m (Maybe (Seq a))     , windowFunction     :: a -> m x     } slidingWindowWith     :: (Monad m, Semigroup x)     => WindowingSettings a x m -> Int     -> Stream (Of a) m b     -> Stream (Of x) m b I would also suggest offering a version where windowFunction is basically id. Why? Several of the most useful tools want to apply their function to the whole window each time, for example to calculate a weighted average or for edge/blob detection. But they also need reasonable border handling. So their implementation might look something like weightedAverage weigh size = fmap (average . weigh) . slidingWindowWith (bothEndsWith interpolateLinear) size Of course a (Seq a) is a Semigroup, so if the user wants a full (Seq a) they could always rebuild it inside windowFunction. But why make that extra difficult. In fact id could be the default impelentation because WindowingSettings should make a decent Functor. So a moving maximum might look something like slidingWindowMax size = slidingWindowWith (Max <$> repeatBorders) size Of course these cents still have some rough edges to iron out. For example, I'm coming from the user side, so I have no idea what's even possible on the inside. But I hope they are of use anyway. Cheers, MarLinn On 06/06/2020 23.32, David Feuer wrote: > I'm looking for a bit of help with a library design choice. > > The streaming package currently offers a slidingWindow function > converting a stream into a stream of fixed-size windows of that > stream[1]: > > slidingWindow > :: Monad m > => Int -- Window size > -> Stream (Of a) m b > -> Stream (Of (Seq a)) m b > > This is based directly on a similar function in conduit. Using a rough > translation into the world of lists, we have > > slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] > > The awkward case where the stream is shorter than the window is > handled by potentially producing a short sequence at the end: > > slidingWindow 3 "ab" = ["ab"] > slidingWindow 3 "" = [""] > > I recently merged a pull request that adds variations on sliding > window maxima and minima using what's apparently a "folklore" > algorithm. For example > > slidingWindowMax 3 "abcbab" = "abcccb" > > This is basically like > > slidingWindowMax k = map maximum . slidingWindow k > > except that an empty stream doesn't yield anything, to avoid undefined values. > > The big advantage of these specialized functions is that rather than > having to take a maximum over a sequence of length `k` at each step, > they only do a constant (amortized) amount of work at each step. Nice! > But not very general. Suppose we want to take a moving average of some > sort, like an arithmetic mean, geometric mean, harmonic mean, or > median? That thought leads quite naturally to a data structure: a > queue holding elements of some arbitrary *semigroup* that efficiently > keeps track of the sum of all the elements in the queue[2]. > > While the choice of *data structure* is moderately obvious, the choice > of *sliding window function* is less so. The tricky bit is, again, > what happens when the stream is too short for the window. If you work > in the Sum semigroup and divide the results by the window size to get > a moving average, then a too-short stream will give a (single) result > that's completely wrong! Oof. What would be the most useful way to > deal with this? The streams in `streaming` give us the option of > producing a distinguished "return" value that comes after all the > yields. Would it make sense to *return* the incomplete sum, and the > number of elements that went into it, instead of *yielding* it into > the result stream? That seems flexible, but maybe a tad annoying. What > do y'all think? > > [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelude.html#v:slidingWindow > > [2] See the AnnotatedQueue in > https://github.com/haskell-streaming/streaming/pull/99/files which > basically modifies Okasaki's implicit queues using some of the basic > ideas that appear in Hinze-Paterson 2–3 trees. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 david.feuer at gmail.com Sun Jun 7 03:24:32 2020 From: david.feuer at gmail.com (David Feuer) Date: Sat, 6 Jun 2020 23:24:32 -0400 Subject: [Haskell-cafe] Sliding windows for streaming In-Reply-To: References: Message-ID: In the current windowy function in streaming, a non-full window occurs only when the stream is too short to fill the window. We fill the window completely before we start yielding results, and stop yielding when we process the last element of the stream. So the output stream is generally shorter than the input stream. Is this the most useful behavior? I don't know. It's what we "inherited" from conduit. But since I'm trying to make something more useful, I need to know what people tend to find useful. On Sat, Jun 6, 2020, 10:49 PM MarLinn wrote: > Hi David, > > this problem reminds me a lot of a whole bunch of functions in OpenCV, the > image manipulation library. Applying a function on every possible window of > a specific size is one of the core tools in image analysis, either as a > moving 1D-function applied to every row, or as a moving 2D-function on the > whole image. So you might find a lot of inspiration there. Note that the > applied function is called a "kernel" in that area. > > I haven't looked at the library in some time, but here are a few thoughts > from what I remember: > > First of all, thinking about the end of the stream is a good idea. But > what about the start of the stream? If the end of the stream can have > non-full windows, why shouldn't the first window have exactly one element, > the second have two, and so on until the window size is reached? Or > something completely different? > > Now the most general idea for start and end of the stream would be to let > the user decide. In OpenCV, there are several standard methods to handle > image borders: cut all non-full windows (like you do at the start of the > stream right now), repeat the value at the border to fill the gaps, take > the min/max/average of the last full window to fill the gaps etc. Why not > let the user provide two functions (Seq a → Seq a → Maybe (Seq a)). The > first argument is the first/last "full" sequence, the second one is the > non-full sequence to be filled, and the result is either a sequence of up > to window-size or Nothing to represent that the result is to be cut. Let > the user provide a record with these functions as settings, provide several > reasonable defaults, and there you go. > > So in essence, what I'm suggesting is something like > > data WindowingSettings a x m = WindowingSettings > { windowStartHandler :: Seq a -> Seq a -> m (Maybe (Seq a)) > , windowEndHandler :: Seq a -> Seq a -> m (Maybe (Seq a)) > , windowFunction :: a -> m x > } > > slidingWindowWith > :: (Monad m, Semigroup x) > => WindowingSettings a x m > -> Int > -> Stream (Of a) m b > -> Stream (Of x) m b > > I would also suggest offering a version where windowFunction is basically > id. Why? Several of the most useful tools want to apply their function to > the whole window each time, for example to calculate a weighted average or > for edge/blob detection. But they also need reasonable border handling. So > their implementation might look something like > > weightedAverage weigh size > = fmap (average . weigh) > . slidingWindowWith (bothEndsWith interpolateLinear) size > > Of course a (Seq a) is a Semigroup, so if the user wants a full (Seq a) > they could always rebuild it inside windowFunction. But why make that > extra difficult. > > In fact id could be the default impelentation because WindowingSettings > should make a decent Functor. So a moving maximum might look something > like > > slidingWindowMax size = slidingWindowWith (Max <$> repeatBorders) size > > Of course these cents still have some rough edges to iron out. For > example, I'm coming from the user side, so I have no idea what's even > possible on the inside. But I hope they are of use anyway. > > Cheers, > MarLinn > On 06/06/2020 23.32, David Feuer wrote: > > I'm looking for a bit of help with a library design choice. > > The streaming package currently offers a slidingWindow function > converting a stream into a stream of fixed-size windows of that > stream[1]: > > slidingWindow > :: Monad m > => Int -- Window size > -> Stream (Of a) m b > -> Stream (Of (Seq a)) m b > > This is based directly on a similar function in conduit. Using a rough > translation into the world of lists, we have > > slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] > > The awkward case where the stream is shorter than the window is > handled by potentially producing a short sequence at the end: > > slidingWindow 3 "ab" = ["ab"] > slidingWindow 3 "" = [""] > > I recently merged a pull request that adds variations on sliding > window maxima and minima using what's apparently a "folklore" > algorithm. For example > > slidingWindowMax 3 "abcbab" = "abcccb" > > This is basically like > > slidingWindowMax k = map maximum . slidingWindow k > > except that an empty stream doesn't yield anything, to avoid undefined values. > > The big advantage of these specialized functions is that rather than > having to take a maximum over a sequence of length `k` at each step, > they only do a constant (amortized) amount of work at each step. Nice! > But not very general. Suppose we want to take a moving average of some > sort, like an arithmetic mean, geometric mean, harmonic mean, or > median? That thought leads quite naturally to a data structure: a > queue holding elements of some arbitrary *semigroup* that efficiently > keeps track of the sum of all the elements in the queue[2]. > > While the choice of *data structure* is moderately obvious, the choice > of *sliding window function* is less so. The tricky bit is, again, > what happens when the stream is too short for the window. If you work > in the Sum semigroup and divide the results by the window size to get > a moving average, then a too-short stream will give a (single) result > that's completely wrong! Oof. What would be the most useful way to > deal with this? The streams in `streaming` give us the option of > producing a distinguished "return" value that comes after all the > yields. Would it make sense to *return* the incomplete sum, and the > number of elements that went into it, instead of *yielding* it into > the result stream? That seems flexible, but maybe a tad annoying. What > do y'all think? > > [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelude.html#v:slidingWindow > > [2] See the AnnotatedQueue inhttps://github.com/haskell-streaming/streaming/pull/99/files which > basically modifies Okasaki's implicit queues using some of the basic > ideas that appear in Hinze-Paterson 2–3 trees. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 anthony_clayden at clear.net.nz Sun Jun 7 10:40:27 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 7 Jun 2020 22:40:27 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: >> On 6/5/20 7:05 AM, Anthony Clayden wrote: >>* Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a* >>* 'publication' and is not by Dijkstra, right?* > Sure. >> *It's taking some of the ideas from Dijkstra's EWD1300, but misapplying* >>* them to Haskell in a rather badly-informed way.* > I wouldn't say so, for reasons explained below. An undated pdf without even the authors names, but using a respected author's name seems dodgy to me. It's not "with E.W.Dijkstra" at all, indeed I'd say it's "against" him. I think what they impute to EWD is wrong in fact and wrong in attitude, for reasons explained below. >>* After all, Haskell already has a 'Application Operator' spelled ($),* >>* which is perfectly first-class and with which you can do the equational* >>* reasoning (with lambdas) that the doco is talking about.* > The thread that I was recalling (Language complexity & beginners) can be found here, > > https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt > and it started as a discussion about the use of ($) for function > application. Namely, what should its type be? Its type is :: (a -> b) -> a -> b; that's in the Haskell Report and what you get at the GHCi prompt :t ($) -- at GHC 6.5 with no extensions on. Also while we're at it Data.Function.& :: a -> (a -> b) -> b -- reverse application, which'll do for the paper Ben suggested. > Whatever you answer is going to be wrong. That's a fine type for the purposes of the 'thought-dialogue' -- which is not a language specification. If GHC's type under the hood is polykinded/higher-ordered/typeRep'd/etc yes that'll confuse beginners, but won't upset the 'thought'. > The root of that problem is that ($) is itself a > function, and you can't insist on using a function to apply function > application without risk of severe injury. So the only way to even use > ($) is via the true function application syntax, namely whitespace. So that's what the authors of EWD.pdf do at the end of the piece, so that they derive (.) by eta-reduction. It's bogus. Also bogus their is putting '.' between the lambda and the bound variable. WTF is that? You don't 'apply' lambda to a variable; it's not a function; it's a binding mechanism. Some syntaxes for lambda calculus put a dot _after_ the bound variable, where Haskell uses ->. To put it bluntly: the authors are blundering. > But whitespace as function application syntax has its own problems. EWD1300 has only a short section on 'Invisible operators'. Dijkstra doesn't like them. To expand his examples, in: > π + x sin(y) The invisible space (juxtaposition) between x and sin means multiplication; the invisible non-spaces within "sin" are not juxtaposition, they're merely a multi-letter name; the invisible non-space between "sin" and parens is function application. (To be precise in C-family languages, it's the pair of parens: rand() is niladic function rand applied to no arguments.) Practical programming languages are limited to ASCII, so can't have UTF-8 chars in names, so we'd have to spell π as "pi" -- which includes another invisible non-space. Then EWD1300 wants to put alternating operators with names, thusly: > pi + x * sin.y > So we want something like ($), but we want it to be *syntax*, Yes. EWD1300's syntax is that (presumably) what's lexed as a (sequence-of) symbol alternates with what's lexed as a name/sequence-of letter. And there's precedence/associativity; and parens' only purpose is to override. EWD1300 does not claim that what's between "pi" and + or between + and x is function application. EWD1300 does not consider operator sections or partial application of operators; only partial application of functions. There's brief mention of 'lambda-abstraction' (partial application), but no working of actual lambda expressions. EWD1300 is not talking about Haskell's peculiar syntax at all. Including not talking about lambda syntax. And I'm sure he'd complain about the iffy use of parens in operator sections -- they're not there merely to override precedence; (5) === 5; (pi) === pi; (+) =/= + > and it should take the place of " " rather than supplement it. > That's the argument those guys (and the paper Ben suggested) are trying to make. EWD1300 does not suggest there's function application between an operator and its operands -- although one could argue that's just as much juxtaposition. Suggesting that for any other operator than ($) would be OK and thereby deals with Haskell's operator sections. But suggesting it for ($) leads to infinite regress. Dijkstra (the real one) was smart enough to see that. The pdf poses a bogus problem; direct consequence of the authors not understanding EWD1300. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sun Jun 7 11:28:50 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 7 Jun 2020 23:28:50 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: >> On 6/5/20 7:05 AM, Anthony Clayden wrote: ... >>* Also it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education. *>> >>* There's other bits and pieces of 'Publications' on that the-magus site; *>>* including spoofs of Dijkstra which can't even spell his first name *>>* right. I rather suspect the ewd.pdf is a spoof that didn't turn out very *>>* funny. So altogether it's a couple of dudes shooting the breeze. * > These all seem pretty irrelevant to the point being made, which I think > has merit. (See my prev post about its lack of merit.) No Haskeller I've ever come across would accuse Dijkstra of "stick[ing] to the antiquated imperative paradigm". Dijkstra advocated teaching Haskell as an antidote to imperativism. EWD1300 is advocating for his own 'notational conventions', chiefly for writing math and formalising proofs. I don't see anything very specific to programming languages; certainly nothing specific to any paradigm. The pdf (words imputed to 'Haskeller') doesn't understand 'first-class': The term dates back to Strachey 1967; it's to do with semantics of names; what in a FP context we'd call 'referential transparency'. It has nothing to do with syntax. Column 2 of page 1 is bogus. Even if 'Haskeller' didn't know that CompSci archaeology, they'd certainly know the ($) operator. Whether or not it's the most important operator, there _is_ an operator and it is first-class. 'Haskeller' gets several answers wrong at the top of p2; finally gets to $ and gets that wrong too: EWD's question re `length $ [] = 0` is not a way to define `length`. Any Haskell beginner could stick that into an actual Haskell compiler and see why. Towards the bottom of p2 EWD admits "I do not know your Haskell very well ...". I'd say this faux-Haskeller knows Haskell less well than faux-EWD. Just before that admission is another piece of bogus notation for operator sections of `x * y`. None of that appears in EWD1300. > This is all just a language design curiosity to me, though, > and I'm not looking to start a new religious war until some of the > present ones are resolved. Well, don't look for pointers to language design from the couple of jokers portrayed in that pdf. I find it actually insulting to the good sense the real Dijkstra always showed; and insulting to Haskellers -- what's with all this gratuitous imputing of emotion? What's with just getting Haskell wrong? It's easy to check those claims; it's easy to get the (alleged) 'thought' peer-reviewed from the Haskell community. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Jun 7 15:42:57 2020 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 7 Jun 2020 17:42:57 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: > Well, don't look for pointers to language design from the couple of > jokers portrayed in that pdf. > > I find it actually insulting to the good sense the real Dijkstra > always showed; and insulting to Haskellers -- what's with all this > gratuitous imputing of emotion? What's with just getting Haskell > wrong? It's easy to check those claims; it's easy to get the (alleged) > 'thought' peer-reviewed from the Haskell community. Who is insulting and emotional here? I really don't get why you're so upset about this harmless opinionated piece that, in a humorous and obviously exaggerated way, applies some of Dijkstra's ideas about programming language syntax to Haskell ("notational conventions" is just an informal synonym for syntax.) Putting these words into Dijkstra's mouth is just an artist's freedom, and in fact it gave me pause to think about the issues raised. (That was along time ago, BTW). Despite your endless ranting the authors quite obviously do understand EWD1300. Their use of the word "first-class" may drive the rhetoric a bit over the top but that's pretty superficial IMO. The main point is that in a language like Haskell whitespace is overloaded: it can mean application or it can be a mere separator; which it is depends on the context. If Haskell /required/ the use of an explicit built-in infix operator for application then this context-dependency would disappear and white space would become only a separator. It is valid to argue that this would make the language esier to read. This has nothing to do with the fact that in Haskell you onbviously /can/ define infix application operator. (The argument about the type of application is bogus, though, I agree with you on that one.) I also don't see how this has anything to do with Dijkstra promoting Haskell for teaching. In fact, I find it much less insulting to suggest that Dijkstra would have things to criticise about Haskell (he /was/ very much a perfectionist and if I can enumerate several shortcomings in Haskell off the top of my head, then so I guess he could have), than to suggest that this would be a reason for him to oppose using Haskell for teaching! I would venture that Dijkstra was realist enough to prefer something imperfect when it clearly trumps the competition. That said, he did write in one of his EWDs that beginners(!) should be tought programming with a language that does /not/ have an implementation available, in order to enourage thinking denotationally about programs rather than operationally, right from the start. The reason he preferred an imperative language for such a beginner's course (and also for communicating algorithms) is that recursion has a more complicated semantics (in terms of weakest preconditions) than his 'do' loop construct. This is important if, like Dijkstra did, you introduce every language construct by formally stating its denotational semantics, playing down the operational aspect as much as possible. Cheers Ben From targen at gmail.com Sun Jun 7 16:25:31 2020 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Sun, 7 Jun 2020 18:25:31 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: On Sun, Jun 7, 2020 at 5:44 PM Ben Franksen wrote: > That said, he did write in one of his EWDs that beginners(!) should be > tought programming with a language that does /not/ have an > implementation available, in order to enourage thinking denotationally > about programs rather than operationally, right from the start. The > reason he preferred an imperative language for such a beginner's course > (and also for communicating algorithms) is that recursion has a more > complicated semantics (in terms of weakest preconditions) than his 'do' > loop construct. This is important if, like Dijkstra did, you introduce > every language construct by formally stating its denotational semantics, > playing down the operational aspect as much as possible. As a fun anecdote, Dijkstra's language referred to here, the Guarded Command Language, has actually seen several implementations despite his explicit intent for implementations never to exist: https://metacpan.org/pod/Commands::Guarded https://web.archive.org/web/20091214010836/http://www.dc.fi.udc.es/ai/~cabalar/gcl/ https://web.archive.org/web/20080622163307/http://gacela.labf.usb.ve/GacelaWiki/ The last one there was actually used in the university I went to as the language for the first programming course for incoming CS students for the better part of a decade, until the department switched those courses to Python. Of note, also, is that 12 years passed from EWD1036 to his letter on using Haskell to teach introductory programming. I wonder if he ever wrote or shared his thoughts on whether this was merely a pragmatist's compromise, or a change of heart in light of Haskell's progress over those years: why did he not stick to GCL? From haskell-cafe at chrisdone.com Sun Jun 7 17:46:24 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Sun, 07 Jun 2020 18:46:24 +0100 Subject: [Haskell-cafe] Generalization of types during inference Message-ID: I'm writing a type checker with type classes and for some reason thought that the below program should be inferred and generalized automatically. I wasn't sure whether or not GHC would actually accept this or not, so I had to test. For both Hugs and GHC, a recursive definition's type is not generalized by the inferer. You need a type signature. See below. I checked with Hugs just in case there was a generalization limit in GHC due to its more exotic capabilities (like how let generalization is disabled by type families). I wonder: is it in general impossible or super hard to infer the most general type for all cases like this without a type signature? Or is it just considered a rare case that we don't care about? Perhaps it has subtler downsides? It any case, I'm happy to just copy GHC and Hugs as it makes my life easier to just require an explicit signature in this case. Cheers -- ERROR "Q.hs":4 - Type error in application -- *** Expression : f (n - 1) 'a' -- *** Term : 'a' -- *** Type : Char -- *** Does not match : () -- • Couldn't match expected type ‘()’ with actual type ‘Char’ -- • In the second argument of ‘f’, namely ‘'a'’ -- In the expression: f (n - 1) 'a' -- f :: Int -> a -> Int f 0 x = 0 f 1 x = f 0 () f n x = f (n-1) 'a' -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Sun Jun 7 17:53:03 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Sun, 7 Jun 2020 18:53:03 +0100 Subject: [Haskell-cafe] Generalization of types during inference In-Reply-To: References: Message-ID: Yours is an example of polymorphic recursion, when a function calls itself at a different type than at which it was, itself, called. (What an ugly English construction. Apologies. But it's hard to describe this somehow.) Inference of polymorphic recursion is undecidable in the general case: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.3091&rep=rep1&type=pdf Some special cases can be inferred, and indeed GHC does a little inference of this in types, in some scenarios. (We'd actually prefer not to, in order to be consistent, but oddly it's hard to avoid in our algorithm.) But generally inferencers avoid trying here. Richard > On Jun 7, 2020, at 6:46 PM, chris done wrote: > > I'm writing a type checker with type classes and for some reason thought > that the below program should be inferred and generalized automatically. I > wasn't sure whether or not GHC would actually accept this or not, so I had to test. > > For both Hugs and GHC, a recursive definition's type is not generalized > by the inferer. You need a type signature. See below. I checked with > Hugs just in case there was a generalization limit in GHC due to its more exotic > capabilities (like how let generalization is disabled by type families). > > I wonder: is it in general impossible or super hard to infer the most > general type for all cases like this without a type signature? Or is it just considered a > rare case that we don't care about? Perhaps it has subtler downsides? > > It any case, I'm happy to just copy GHC and Hugs as it makes my life > easier to just require an explicit signature in this case. > > Cheers > > -- ERROR "Q.hs":4 - Type error in application > -- *** Expression : f (n - 1) 'a' > -- *** Term : 'a' > -- *** Type : Char > -- *** Does not match : () > > -- • Couldn't match expected type ‘()’ with actual type ‘Char’ > -- • In the second argument of ‘f’, namely ‘'a'’ > -- In the expression: f (n - 1) 'a' > > -- f :: Int -> a -> Int > f 0 x = 0 > f 1 x = f 0 () > f n x = f (n-1) 'a' > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Sun Jun 7 18:02:30 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Sun, 07 Jun 2020 19:02:30 +0100 Subject: [Haskell-cafe] Generalization of types during inference In-Reply-To: References: Message-ID: <9fbd0f50-9a36-44b5-b75a-585778a8a761@www.fastmail.com> Thanks Richard and for the paper link! This answers my question and then some. Cheers! On Sun, Jun 7, 2020, at 6:53 PM, Richard Eisenberg wrote: > Yours is an example of polymorphic recursion, when a function calls itself at a different type than at which it was, itself, called. (What an ugly English construction. Apologies. But it's hard to describe this somehow.) Inference of polymorphic recursion is undecidable in the general case: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.42.3091&rep=rep1&type=pdf > > Some special cases can be inferred, and indeed GHC does a little inference of this in types, in some scenarios. (We'd actually prefer not to, in order to be consistent, but oddly it's hard to avoid in our algorithm.) But generally inferencers avoid trying here. > > Richard > >> On Jun 7, 2020, at 6:46 PM, chris done wrote: >> >> I'm writing a type checker with type classes and for some reason thought >> that the below program should be inferred and generalized automatically. I >> wasn't sure whether or not GHC would actually accept this or not, so I had to test. >> >> For both Hugs and GHC, a recursive definition's type is not generalized >> by the inferer. You need a type signature. See below. I checked with >> Hugs just in case there was a generalization limit in GHC due to its more exotic >> capabilities (like how let generalization is disabled by type families). >> >> I wonder: is it in general impossible or super hard to infer the most >> general type for all cases like this without a type signature? Or is it just considered a >> rare case that we don't care about? Perhaps it has subtler downsides? >> >> It any case, I'm happy to just copy GHC and Hugs as it makes my life >> easier to just require an explicit signature in this case. >> >> Cheers >> >> -- ERROR "Q.hs":4 - Type error in application >> -- *** Expression : f (n - 1) 'a' >> -- *** Term : 'a' >> -- *** Type : Char >> -- *** Does not match : () >> >> -- • Couldn't match expected type ‘()’ with actual type ‘Char’ >> -- • In the second argument of ‘f’, namely ‘'a'’ >> -- In the expression: f (n - 1) 'a' >> >> -- f :: Int -> a -> Int >> f 0 x = 0 >> f 1 x = f 0 () >> f n x = f (n-1) 'a' >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 duke.j.david at gmail.com Sun Jun 7 19:40:36 2020 From: duke.j.david at gmail.com (David Duke) Date: Sun, 7 Jun 2020 20:40:36 +0100 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: Rather than denotationally, I'd emphasise the axiomatic foundations of GCL in terms of wp. Whilst EWD had plenty to say about programming languages his over arching concern was programming methodology and the implementation of correct programs wrt a specification. It is not just a matter of simpler semantics. In EWD798 Dijkstra writes that (at the event) he gave a correctness proof that went against the assumption that applicative programs are easier to prove correct than imperative ones. I believe he repeats that comment elsewhere though I can't find a reference. (I was curious to find what the algorithm was that he presented. I tried emailing a few people whom I thought might have been at the meeting, unfortunately no one had notes or could recall. The event was "Advanced Course on Functional Programming and its Applications" 1981.Whilst I believe on the basis of the EWD'staDijkstra thought highly of FP in that it supported the style of calculational proof/development that he advocated, I don't believe that he saw FP as a 'silver bullet' or necessarily the best option. And his support for Haskell must be seen in the context of a discussion on alternatives for a programming course rather than advocacy per se. Indeed he was careful to write: inally, in the specific comparison of Haskell versus Java, "Haskell, though not perfect, is of a quality that is several orders of magnitude higher than Java, which is a mess" [Dijkstra "*To the members of the Budget Council" 12 April 2001.* Indeed On Sun, Jun 7, 2020 at 5:27 PM Manuel Gómez wrote: > On Sun, Jun 7, 2020 at 5:44 PM Ben Franksen > wrote: > > That said, he did write in one of his EWDs that beginners(!) should be > > tought programming with a language that does /not/ have an > > implementation available, in order to enourage thinking denotationally > > about programs rather than operationally, right from the start. The > > reason he preferred an imperative language for such a beginner's course > > (and also for communicating algorithms) is that recursion has a more > > complicated semantics (in terms of weakest preconditions) than his 'do' > > loop construct. This is important if, like Dijkstra did, you introduce > > every language construct by formally stating its denotational semantics, > > playing down the operational aspect as much as possible. > > As a fun anecdote, Dijkstra's language referred to here, the Guarded > Command Language, has actually seen several implementations despite > his explicit intent for implementations never to exist: > > https://metacpan.org/pod/Commands::Guarded > > https://web.archive.org/web/20091214010836/http://www.dc.fi.udc.es/ai/~cabalar/gcl/ > > https://web.archive.org/web/20080622163307/http://gacela.labf.usb.ve/GacelaWiki/ > > The last one there was actually used in the university I went to as > the language for the first programming course for incoming CS students > for the better part of a decade, until the department switched those > courses to Python. > > Of note, also, is that 12 years passed from EWD1036 to his letter on > using Haskell to teach introductory programming. I wonder if he ever > wrote or shared his thoughts on whether this was merely a pragmatist's > compromise, or a change of heart in light of Haskell's progress over > those years: why did he not stick to GCL? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- David Duke Professor of Computer Science School of Computing University of Leeds UK E:duke.j.david at gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at joyful.com Sun Jun 7 20:16:31 2020 From: simon at joyful.com (Simon Michael) Date: Sun, 07 Jun 2020 13:16:31 -0700 Subject: [Haskell-cafe] ANN: hledger 1.18 Message-ID: <858c3d3a-1747-4dc4-9868-bcc8f0f49435@www.fastmail.com> I'm pleased to announce hledger 1.18. hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investments, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org HIGHLIGHTS: Fixed JSON output; market prices inferred from transactions; more Ledger file compatibility; more flexible journal entries from CSV; misc. fixes and improvements. See all changes at https://hledger.org/release-notes . Thanks to release contributors Stephen Morgan, Dmitry Astapov, Henning Thielemann, Andriy Mykhaylyk, Pavan Rikhi, and Vladimir Sorokin. GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.18 hledger-1.18 hledger-ui-1.18 hledger-web-1.18 --silent or: cabal v2-update; cabal v2-install hledger-1.18 hledger-web-1.18 hledger-ui-1.18 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-install/hledger-install.sh less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org). New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon From olf at aatal-apotheke.de Sun Jun 7 20:18:36 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 07 Jun 2020 22:18:36 +0200 Subject: [Haskell-cafe] Generalization of types during inference Message-ID: > f 0 x = 0 > f 1 x = f 0 () > f n x = f (n-1) 'a' That's very interesting, I learned something new about GHC today. I used to believe that my Haskell compiler always type checks declarations on its own, and after that unifies its result with the type declaration that I provide. Polymorphic recursion yields a case where the compiler's inference procedure is evidently not independent of my provided type declaration. Can the above be abused to compile programs containing false type declarations? (It seems the answer is no, but maybe I lack the fantasy.) Thanks, Olaf From jake.mcarthur at gmail.com Sun Jun 7 21:45:57 2020 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Sun, 7 Jun 2020 17:45:57 -0400 Subject: [Haskell-cafe] Generalization of types during inference In-Reply-To: References: Message-ID: I don't actually know much about GHC's type checker itself, but I think it uses a form of bidirectional type checking. A bidirectional type checker has two modes: infer :: Term -> Type check :: Term -> Type -> Bool The syntax is divided into two classes. The types for one of these classes can be inferred, but the other can only be checked. Given a type checkable term, you can create a type inferable term by giving it a type annotation. That is, `infer (x :: T) = check x T`. On Sun, Jun 7, 2020 at 4:19 PM Olaf Klinke wrote: > > f 0 x = 0 > > f 1 x = f 0 () > > f n x = f (n-1) 'a' > > That's very interesting, I learned something new about GHC today. I > used to believe that my Haskell compiler always type checks > declarations on its own, and after that unifies its result with the > type declaration that I provide. Polymorphic recursion yields a case > where the compiler's inference procedure is evidently not independent > of my provided type declaration. Can the above be abused to compile > programs containing false type declarations? (It seems the answer is > no, but maybe I lack the fantasy.) > > Thanks, > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Mon Jun 8 00:07:34 2020 From: raoknz at gmail.com (Richard O'Keefe) Date: Mon, 8 Jun 2020 12:07:34 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: <5fdc308a-483d-1aff-d21c-5122cecb0d5c@orlitzky.com> References: <5fdc308a-483d-1aff-d21c-5122cecb0d5c@orlitzky.com> Message-ID: This is one of the notational issues where I venture to disagree with the Master. It's on a par with arguing that a number like 1234 would be easier to read as 1`2`3`4 where the semantics of x`y is x*10+y. More seriously, in "f x", there is an explicit operator already. It's "f". The space is needed for lexical reasons only. If you say no, functions are not operators -- though in Haskell infix operators are functions -- but application is the operator, so you should write "f at x" (usual FP notation) or "f.x" (Dijkstra), then although it isn't technically true, I've always felt that there is an infinite regress lurking in the background: if x + y means (+) x y which really stands for (+)@x at y then shouldn't that in turn stand for (@)((@)(+)x)y and what should _that_ stand for? On Fri, 5 Jun 2020 at 23:45, Michael Orlitzky wrote: > On 6/5/20 7:05 AM, Anthony Clayden wrote: > > Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a > > 'publication' and is not by Dijkstra, right? > > Sure. > > > > It's taking some of the ideas from Dijkstra's EWD1300, but misapplying > > them to Haskell in a rather badly-informed way. > > I wouldn't say so, for reasons explained below. > > > > After all, Haskell already has a 'Application Operator' spelled ($), > > which is perfectly first-class and with which you can do the equational > > reasoning (with lambdas) that the doco is talking about. > > The thread that I was recalling (Language complexity & beginners) can be > found here, > > https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt > > and it started as a discussion about the use of ($) for function > application. Namely, what should its type be? Whatever you answer is > going to be wrong. The root of that problem is that ($) is itself a > function, and you can't insist on using a function to apply function > application without risk of severe injury. So the only way to even use > ($) is via the true function application syntax, namely whitespace. > > But whitespace as function application syntax has its own problems. So > we want something like ($), but we want it to be *syntax*, and it should > take the place of " " rather than supplement it. That's the argument > those guys (and the paper Ben suggested) are trying to make. > > > > Also it doesn't seem to know Haskellers very well; nor Dijkstra's > > well-known support for Haskell in education. > > > > There's other bits and pieces of 'Publications' on that the-magus site; > > including spoofs of Dijkstra which can't even spell his first name > > right. I rather suspect the ewd.pdf is a spoof that didn't turn out very > > funny. So altogether it's a couple of dudes shooting the breeze. > > These all seem pretty irrelevant to the point being made, which I think > has merit. This is all just a language design curiosity to me, though, > and I'm not looking to start a new religious war until some of the > present ones are resolved. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 rae at richarde.dev Mon Jun 8 08:54:22 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 8 Jun 2020 09:54:22 +0100 Subject: [Haskell-cafe] Generalization of types during inference In-Reply-To: References: Message-ID: > On Jun 7, 2020, at 10:45 PM, Jake McArthur wrote: > > I don't actually know much about GHC's type checker itself, but I think it uses a form of bidirectional type checking. A bidirectional type checker has two modes: > > infer :: Term -> Type > check :: Term -> Type -> Bool > > The syntax is divided into two classes. The types for one of these classes can be inferred, but the other can only be checked. Given a type checkable term, you can create a type inferable term by giving it a type annotation. That is, `infer (x :: T) = check x T`. Exactly so. (Well, those types aren't the types of the relevant functions within GHC, but they are are very useful approximation.) This is explained in a relatively accessible way here: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/putting.pdf Bidirectional type checking is needed in order to check higher-rank types; a higher-rank type has a `forall` to the left of an arrow, like the type in `foo :: (forall a. a -> a) -> Int`. > > On Sun, Jun 7, 2020 at 4:19 PM Olaf Klinke > wrote: > > f 0 x = 0 > > f 1 x = f 0 () > > f n x = f (n-1) 'a' > > That's very interesting, I learned something new about GHC today. I > used to believe that my Haskell compiler always type checks > declarations on its own, and after that unifies its result with the > type declaration that I provide. Polymorphic recursion yields a case > where the compiler's inference procedure is evidently not independent > of my provided type declaration. Can the above be abused to compile > programs containing false type declarations? (It seems the answer is > no, but maybe I lack the fantasy.) Interestingly, bidirectional type checking, in all its power, is not needed to support polymorphic recursion, which can get away with weaker propagation of types when checking terms. Also, as far as I know, this aspect of Haskell is not unique to GHC, but is included in Haskell 98 and should be supported by other compilers. Can this be abused? I hope not! :) Richard > > Thanks, > Olaf > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Jun 8 10:42:07 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 8 Jun 2020 22:42:07 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: > Ben Franksen wrote: >>* Well, don't look for pointers to language design from the couple of* >>* jokers portrayed in that pdf.* >> >>* I find it actually insulting to the good sense the real Dijkstra* >>* always showed; and insulting to Haskellers ...* > I really don't get why you're so upset about this harmless opinionated > piece that, in a humorous and obviously exaggerated way, It's not apparent to me this is humour, not even intended as humour. Notoriously, it's very difficult to get across sarcasm/irony on the interwebs. The tongue-in-cheek is not apparent to one of the authors, who has actually implemented these ideas blog.languager.org/2014/09/pugofer.html and it seems inflicted them on undergraduates. Including "8. layout is the only way to denote nesting ...". While they were at it, why not introduce sugar for function definition: > length . [] = 0 would be easy to desugar as an equation defining `length`. It's not apparent from the original thread May 2019 this is all a big hoot. If it's humour, who's the butt of the joke? A caricature of a Haskell newbie who doesn't understand Haskell, and can only regurgitate FP ideals as cheap dogma, played like a trout until "Exasperated". This is cruel sport, not Socratic method. Not humorous. > applies some of Dijkstra's ideas about programming language syntax ... It's not apparent to me that EWD1300 is about programming languages; the piece addresses "polite mathematics", name-checks Whitehead, Leibniz, Tarski -- who are not well-known for their work on programming languages. > Putting these words into Dijkstra's mouth is just an artist's freedom, If it's intended as art, the least they could do is put their name to it. > Despite your endless ranting the authors quite obviously do understand > EWD1300. That's not apparent to me either. > I also don't see how this has anything to do with Dijkstra promoting > Haskell for teaching. I'm not expecting the real Dijkstra would be uncritical of Haskell. I do expect that since Dijkstra saw Haskell's value for teaching, he would respect the (always difficult) design/syntax choices in the language. It's the faux-EWD's snide tripping-up of Haskeller that is uncharacteristic of Dijkstra. Also criticising Haskell's use of semicolon, which comes from ALGOL, as the real Dijkstra would be well aware. Also criticising allowing multiple constructs to express the same algorithm/semantics -- ALGOL also has plenty of that, and by design. And cheap shots about Haskell not supporting "assignments, pointers, gotos ..." -- we all know Dijkstra considers them harmful. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Mon Jun 8 12:13:48 2020 From: publicityifl at gmail.com (Jurriaan Hage) Date: Mon, 8 Jun 2020 05:13:48 -0700 Subject: [Haskell-cafe] First call for draft papers for IFL 2020 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the final call for draft papers for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2020 32nd Symposium on Implementation and Application of Functional Languages venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Post-symposium peer-review Following IFL tradition, IFL 2020 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation IFL 2020 Chair: Olaf Chitil, University of Kent, UK IFL Publicity chair: Jurriaan Hage, Utrecht University, The Netherlands ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Mon Jun 8 14:07:18 2020 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 8 Jun 2020 10:07:18 -0400 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: <99B16B3F-6AE8-4426-839C-47F789962825@gmail.com> Haskell's reputation as a welcoming community is on shakier ground than it was a few years ago, and phrases like "despite your endless ranting" work against the collegial atmosphere we're proud of. No need to be faux polite, but when people (wrongly, in my opinion) describe us as an unwelcoming community, this is the type of convo I imagine them having come across and been scared off by. Tom El 7 jun 2020, a las 11:42, Ben Franksen escribió: >> Well, don't look for pointers to language design from the couple of >> jokers portrayed in that pdf. >> >> I find it actually insulting to the good sense the real Dijkstra >> always showed; and insulting to Haskellers -- what's with all this >> gratuitous imputing of emotion? What's with just getting Haskell >> wrong? It's easy to check those claims; it's easy to get the (alleged) >> 'thought' peer-reviewed from the Haskell community. > > Who is insulting and emotional here? > > I really don't get why you're so upset about this harmless opinionated > piece that, in a humorous and obviously exaggerated way, applies some of > Dijkstra's ideas about programming language syntax to Haskell > ("notational conventions" is just an informal synonym for syntax.) > Putting these words into Dijkstra's mouth is just an artist's freedom, > and in fact it gave me pause to think about the issues raised. (That was > along time ago, BTW). > > Despite your endless ranting the authors quite obviously do understand > EWD1300. Their use of the word "first-class" may drive the rhetoric a > bit over the top but that's pretty superficial IMO. The main point is > that in a language like Haskell whitespace is overloaded: it can mean > application or it can be a mere separator; which it is depends on the > context. If Haskell /required/ the use of an explicit built-in infix > operator for application then this context-dependency would disappear > and white space would become only a separator. It is valid to argue that > this would make the language esier to read. This has nothing to do with > the fact that in Haskell you onbviously /can/ define infix application > operator. (The argument about the type of application is bogus, though, > I agree with you on that one.) > > I also don't see how this has anything to do with Dijkstra promoting > Haskell for teaching. In fact, I find it much less insulting to suggest > that Dijkstra would have things to criticise about Haskell (he /was/ > very much a perfectionist and if I can enumerate several shortcomings in > Haskell off the top of my head, then so I guess he could have), than to > suggest that this would be a reason for him to oppose using Haskell for > teaching! I would venture that Dijkstra was realist enough to prefer > something imperfect when it clearly trumps the competition. > > That said, he did write in one of his EWDs that beginners(!) should be > tought programming with a language that does /not/ have an > implementation available, in order to enourage thinking denotationally > about programs rather than operationally, right from the start. The > reason he preferred an imperative language for such a beginner's course > (and also for communicating algorithms) is that recursion has a more > complicated semantics (in terms of weakest preconditions) than his 'do' > loop construct. This is important if, like Dijkstra did, you introduce > every language construct by formally stating its denotational semantics, > playing down the operational aspect as much as possible. > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ben.franksen at online.de Mon Jun 8 15:49:32 2020 From: ben.franksen at online.de (Ben Franksen) Date: Mon, 8 Jun 2020 17:49:32 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: <99B16B3F-6AE8-4426-839C-47F789962825@gmail.com> References: <99B16B3F-6AE8-4426-839C-47F789962825@gmail.com> Message-ID: Am 08.06.20 um 16:07 schrieb amindfv at gmail.com: > Haskell's reputation as a welcoming community is on shakier ground > than it was a few years ago, and phrases like "despite your endless > ranting" work against the collegial atmosphere we're proud of. To put this in perspective, here are a few citations from what I have called "endless ranting": > ... misapplying ... in a rather badly-informed way. > ... it doesn't seem to know Haskellers very well; nor Dijkstra's > well-known support for Haskell in education. > ... can't even spell his first name right... > ... it's a couple of dudes shooting the breeze. > ...To put it bluntly: the authors are blundering. > ... a bogus problem; direct consequence of the authors not > understanding EWD1300. Do you regard this as "welcoming" language? If not, where was your concerned reply when they hit the list? IMO the occasional ranting doesn't hurt anybody as long as it is addressed not to people but to technical shortcomings. However, the above citations are clearly ad-hominem attacks. Or is your point that I directly addressed the author of the above lines, rather than attacking some third party? Cheers Ben From m at jaspervdj.be Mon Jun 8 19:30:26 2020 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Mon, 8 Jun 2020 21:30:26 +0200 Subject: [Haskell-cafe] Reminder: ZuriHac is happening (remotely) this weekend be great fun! Message-ID: <20200608193026.GA84055@kakigori> Hi everybody! This is a reminder that not only will ZuriHac be happening this year, but because it will be remote, the number of attendees has virtually no upper limit. We're quite excited (and a little bit nervous) to see how a remote event will play out. We will for sure lose a little bit of the magic feeling of hacking on projects together, however we hope that getting together online will still be a great experience. Another benefit is that people can join from all over the world, and that the event will generate a lot fewer CO2 emissions this year, so we can all feel good about ourselves! A brief summary of what will be there - Talks by Alexis King, Rob Rix, Gabriel Gonzalez, Philip Wadler and Simon Meier & Ognjen Marić will be live-streamed on our Youtube channel: . - Well-Typed will teach two advanced sessions, one about Datatype-Generic Programming and one about InfoSec and Haskell. - Julie Moronuki will teach a beginner track. - There is a GHC track with talks by Richard Eisenberg, Divesh Otwani, Facundo Dominguez and Nicolas Frisby. - Of course, lots of Haskell hacking and socialing! You can find all information & register on our website: Warm regards Jasper Van der Jeugt From amindfv at gmail.com Mon Jun 8 20:19:08 2020 From: amindfv at gmail.com (amindfv at gmail.com) Date: Mon, 8 Jun 2020 16:19:08 -0400 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: <99B16B3F-6AE8-4426-839C-47F789962825@gmail.com> Message-ID: Sincere apologies if my message came across as me, personally, criticizing you(r actions), personally. Enforced 100% politeness isn't actually good for a community, and I have no special claim to an objective viewpoint on which messages are hurtful vs. harmful. Plus, I'm sure emails I've sent on this list have failed the test I'm describing now. On the other hand, almost certainly most people subscribed to the mailing list haven't read every email on the list, and even a message that's "justified frustration" in context can seem like a community full of jerks to people who don't have that full context. People (real people I've spoken to offline) worry their questions will be attacked or ridiculed, and so don't ask them and stay disengaged. Not the problem of one email or one author. And I certainly don't want to have to implicitly endorse (or not) whatever messages came before. The existence of other (imo) rude messages on the list underscores my point, not detracts from it. We should all try to make this place be and seem friendly. Tom > El 8 jun 2020, a las 11:49, Ben Franksen escribió: > >> Am 08.06.20 um 16:07 schrieb amindfv at gmail.com: >> Haskell's reputation as a welcoming community is on shakier ground >> than it was a few years ago, and phrases like "despite your endless >> ranting" work against the collegial atmosphere we're proud of. > > To put this in perspective, here are a few citations from what I have > called "endless ranting": > >> ... misapplying ... in a rather badly-informed way. >> ... it doesn't seem to know Haskellers very well; nor Dijkstra's >> well-known support for Haskell in education. >> ... can't even spell his first name right... >> ... it's a couple of dudes shooting the breeze. >> ...To put it bluntly: the authors are blundering. >> ... a bogus problem; direct consequence of the authors not >> understanding EWD1300. > > Do you regard this as "welcoming" language? If not, where was your > concerned reply when they hit the list? > > IMO the occasional ranting doesn't hurt anybody as long as it is > addressed not to people but to technical shortcomings. However, the > above citations are clearly ad-hominem attacks. > > Or is your point that I directly addressed the author of the above > lines, rather than attacking some third party? > > Cheers > Ben > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From spam at scientician.net Mon Jun 8 20:58:56 2020 From: spam at scientician.net (Bardur Arantsson) Date: Mon, 8 Jun 2020 22:58:56 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: <99B16B3F-6AE8-4426-839C-47F789962825@gmail.com> Message-ID: Just to add a disintered observer perspective: Maybe gmane[0] is screwing with me, or somebody replied to a digest (or didn't include the right mail headers to allow threading) and that screws up all of the thread context. That makes it hard to tell "who started it". In general: I don't find responding to invective with more invective to be productive in any way. Either just call the person out directly in a meta-reply or don't respond at all -- except perhpas in a Gray Rock fashion. (Can't definitively say I haven't succumbed to baiting in the past, but I do try my best not to. Life is too short, honestly. "Strong opinions loosely held", and all that...) [0] It's back as gmane.io! From cdsmith at gmail.com Mon Jun 8 21:42:47 2020 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 8 Jun 2020 17:42:47 -0400 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: References: <20200601182932.GM48101@straasha.imrryr.org> Message-ID: (Sorry for the delay. I overlooked this question.) > It is OK to include client-side Javascript frameworks? I was about to say no. But now that you've got me thinking, perhaps I could change this. I described by thinking at https://github.com/google/codeworld/issues/1362. So my better answer is "not yet". On Tue, Jun 2, 2020 at 7:41 AM Alberto G. Corona wrote: > It is OK to include client-side Javascript frameworks? > > El mar., 2 jun. 2020 a las 1:09, Chris Smith () > escribió: > >> Thanks for the questions. >> >> 1. Yes, network I/O is excluded. The only real exceptions here are >> stdin/err/out, and code that's specifically written to work in GHCJS, such >> as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in >> ghcjs-base. >> >> 2. Depending on bytestring is fine, because it has a shim that makes it >> work with GHCJS. I believe >> https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list of >> shimmed libraries that you don't need to worry about depending on. >> >> 3. Exporting inessential TH features is fine. It's just that people >> attempting to use your library via CodeWorld won't be able to use >> them, since CodeWorld's web interface will refuse to build anything that >> enables Template Haskell. >> >> It looks like your project is completely excluded only because of the >> network I/O. If the network I/O is not necessary and you could exclude the >> dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if >> impl(ghcjs)" in the cabal file, then it could still work. But, of course, >> of the network I/O is the whole point, then it's not going to work out. >> JavaScript >> >> On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni >> wrote: >> >>> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: >>> >>> > >>> https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal >>> > >>> > Packages that fit here are: >>> > >>> > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a >>> web >>> > browser, there is no filesystem, for example. >>> >>> I assume this also precludes network I/O? >>> >>> > 2. Do not rely on native libraries, or have dependencies that do. >>> This all >>> > depends on the library building with GHCJS. >>> >>> I guess this also excludes `bytestring`, which uses memcpy(), memchr(), >>> and writes directly allocated memory? >>> >>> -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation >>> for GHC >>> -- >>> mallocByteString :: Int -> IO (ForeignPtr a) >>> mallocByteString = mallocPlainForeignPtrBytes >>> >>> and all of its dependencies? >>> >>> > 3. Do not require use of Template Haskell by clients. It's okay if >>> your >>> > package needs template Haskell to build, but people using your library >>> via >>> > CodeWorld cannot yet use TH themselves. >>> >>> Is it that Template Haskell features in modules are not available to >>> users, or that modules that export even "inessential" TH features are >>> precluded. >>> >>> For example, can the platform support a module that exports a >>> convenience TH "splice", if the same can be done slightly less >>> conveniently (e.g. run-time, rather than compile-time error checks) at >>> runtime via alternative functions? >>> >>> [ My current project does network I/O, uses `bytestring`, and provides >>> TH-splices for two types of compile-time validated literals, so I >>> would assume is a non-starter on all three counts. ] >>> >>> -- >>> 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. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > Alberto. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Jun 9 00:46:58 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 9 Jun 2020 12:46:58 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: > Richard O'Keefe wrote: > This is one of the notational issues where I venture to disagree > with the Master. It's on a par with arguing that a number like > 1234 would be easier to read as 1`2`3`4 where the semantics of > x`y is x*10+y. Thanks Richard, and more to the point/dot: If dot means function application then `3.14` must be `3` applied to `14`. Or perhaps the Master expects Floats to be written European-style with commas? Good luck with that in Haskell. Let's also use Euro-style space as thousands separator! Or perhaps Dijkstra as more mathematician doesn't dirty his hands with Floats. Meta: all the above is tongue-in-cheek. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Tue Jun 9 04:27:41 2020 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Tue, 9 Jun 2020 06:27:41 +0200 Subject: [Haskell-cafe] Future of lucid Message-ID: Hi! I recently noticed that the issue tracker for the lucid package at https://github.com/chrisdone/lucid has been disabled. Does this have any implications for the future maintenance of the package? Is anyone still committed to maintaining the package? (I've CC'd Oleg who made the most recent commit to the repo.) The context for my question is that we'd like to use lucid for the Dhall documentation generator that is being developed as a part of this year's GSoC. Thanks! Simon From heraldhoi at gmail.com Tue Jun 9 07:13:54 2020 From: heraldhoi at gmail.com (Geraldus) Date: Tue, 9 Jun 2020 12:13:54 +0500 Subject: [Haskell-cafe] Generating PDF from HTML with Pandoc Message-ID: Hi dear Cafe! I'm trying to achieve trivial task to generate PDF from HTML template using Pandoc. So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no luck. I want to put few words about `pdflatex` and `xelatex` creators first, for someone who will struggle with same task in future, it's quite hard to find code examples on the web. Initially I wasn't able to render document with `pdflatex` creator. I would like to mention that `pdflatex` required a lot of LaTeX stuff to be installed, especially font packages. Also I've spent several hours to make rendering happen because I haven't specified template in `WriterOptions`. `pdflatex` do not capable to handle Cyrillic Unicode characters, and finally I figured out I have to use `xelatex` creator. Also I've found and used default template: > pandoc <- readHtml def (toStrict $ renderHtml html) > tpl' <- getDefaultTemplate "latex" > makePDF "xelatex" [] writeLaTeX (def {writerTemplate = Just tpl'}) pandoc But in this case I got white space instead of Cyrillic chars in resulting PDF and a bunch of warnings about missing chars in default font in console. I assume the font itself is specified in template. I've looked into default template and it's huge. I guess I can prepare more simple template for my own needs but it will take a lot of time to get familiar with LaTeX document syntax. I've tried `wkhtmltopdf`, which seems to be lightweight and easy solution. It seemed to work well except encoding issues: resulting PDF contains Cyrillic which rendered incorrectly. I've tried to pass `["encoding utf-8"]` as arguments in `makePDF` call, but this results in runtime error: > --margin-bottom specified in incorrect location Googling around this issue led me to glue that when I pass encoding argument to `wkhtmltopdf` it breaks expected arguments order in command which Pandoc generates. This is likely could be easily fixed, but Pandoc have a lot of opened issues on Github and also it requires some digging into `wkhtmltopdf` command line arguments syntax. I've looked into Pandoc sources and it seems possible to provide simple patch, but I need a guidance. According to `wkhtmltopdf` it distinguish global args, page args, cover args, table of contents args. `encoding` argument is page level argument, but Pandoc put extra args specified in `makePDF` after default page arguments (`pdfargs` in following code sample): > let args = mathArgs ++ concatMap toArgs > [("page-size", getField "papersize" meta') > ,("title", getField "title" meta') > ,("margin-bottom", Just $ fromMaybe "1.2in" > (getField "margin-bottom" meta')) > ,("margin-top", Just $ fromMaybe "1.25in" > (getField "margin-top" meta')) > ,("margin-right", Just $ fromMaybe "1.25in" > (getField "margin-right" meta')) > ,("margin-left", Just $ fromMaybe "1.25in" > (getField "margin-left" meta')) > ,("footer-html", getField "footer-html" meta') > ,("header-html", getField "header-html" meta') > ] ++ pdfargs Likely this breaks everything. The quickest and dirtiest workaround I see is to check each argument, and if it is a page level argument put it for each page object. Another solution may be to specify encoding for Pandoc document some other way, but I can't guess how to do that yet. Maybe someone have already faced similar task and knows easier way to render HTML to PDF with Haskell. I will very grateful for any help, advice or other glues how to achieve my goal. Arthur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Tue Jun 9 08:29:17 2020 From: chpatrick at gmail.com (Patrick Chilton) Date: Tue, 9 Jun 2020 10:29:17 +0200 Subject: [Haskell-cafe] Generating PDF from HTML with Pandoc In-Reply-To: References: Message-ID: Could you call wkhtmltopdf directly with System.Process? Pandoc doesn't seem to add much value here. On Tue, Jun 9, 2020, 09:15 Geraldus wrote: > Hi dear Cafe! > > I'm trying to achieve trivial task to generate PDF from HTML template > using Pandoc. > > So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no > luck. > > I want to put few words about `pdflatex` and `xelatex` creators first, for > someone who will struggle with same task in future, it's quite hard to find > code examples on the web. > > Initially I wasn't able to render document with `pdflatex` creator. I > would like to mention that `pdflatex` required a lot of LaTeX stuff to be > installed, especially font packages. Also I've spent several hours to make > rendering happen because I haven't specified template in `WriterOptions`. > `pdflatex` do not capable to handle Cyrillic Unicode characters, and > finally I figured out I have to use `xelatex` creator. Also I've found and > used default template: > > > pandoc <- readHtml def (toStrict $ renderHtml html) > > tpl' <- getDefaultTemplate "latex" > > makePDF "xelatex" [] writeLaTeX (def {writerTemplate = Just tpl'}) > pandoc > > But in this case I got white space instead of Cyrillic chars in resulting > PDF and a bunch of warnings about missing chars in default font in > console. I assume the font itself is specified in template. I've looked > into default template and it's huge. I guess I can prepare more simple > template for my own needs but it will take a lot of time to get familiar > with LaTeX document syntax. > > I've tried `wkhtmltopdf`, which seems to be lightweight and easy > solution. It seemed to work well except encoding issues: resulting PDF > contains Cyrillic which rendered incorrectly. I've tried to pass > `["encoding utf-8"]` as arguments in `makePDF` call, but this results in > runtime error: > > > --margin-bottom specified in incorrect location > > Googling around this issue led me to glue that when I pass encoding > argument to `wkhtmltopdf` it breaks expected arguments order in command > which Pandoc generates. This is likely could be easily fixed, but Pandoc > have a lot of opened issues on Github and also it requires some digging > into `wkhtmltopdf` command line arguments syntax. I've looked into Pandoc > sources and it seems possible to provide simple patch, but I need a > guidance. According to `wkhtmltopdf` it distinguish global args, page > args, cover args, table of contents args. `encoding` argument is page > level argument, but Pandoc put extra args specified in `makePDF` after > default page arguments (`pdfargs` in following code sample): > > > let args = mathArgs ++ concatMap toArgs > > [("page-size", getField "papersize" meta') > > ,("title", getField "title" meta') > > ,("margin-bottom", Just $ fromMaybe "1.2in" > > (getField "margin-bottom" meta')) > > ,("margin-top", Just $ fromMaybe "1.25in" > > (getField "margin-top" meta')) > > ,("margin-right", Just $ fromMaybe "1.25in" > > (getField "margin-right" meta')) > > ,("margin-left", Just $ fromMaybe "1.25in" > > (getField "margin-left" meta')) > > ,("footer-html", getField "footer-html" meta') > > ,("header-html", getField "header-html" meta') > > ] ++ pdfargs > > Likely this breaks everything. The quickest and dirtiest workaround I see > is to check each argument, and if it is a page level argument put it for > each page object. Another solution may be to specify encoding for Pandoc > document some other way, but I can't guess how to do that yet. > > Maybe someone have already faced similar task and knows easier way to > render HTML to PDF with Haskell. I will very grateful for any help, advice > or other glues how to achieve my goal. > > Arthur. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 heraldhoi at gmail.com Tue Jun 9 08:42:35 2020 From: heraldhoi at gmail.com (Geraldus) Date: Tue, 9 Jun 2020 13:42:35 +0500 Subject: [Haskell-cafe] Generating PDF from HTML with Pandoc In-Reply-To: References: Message-ID: Thank you Patrick. This is exact solution I've came up with right after I've sent letter to Cafe. For some reason I didn't received copy of my own message and wasn't able to respond until someone respond first. Many thanks. Indeed in most cases if you can ask a question you can find a solution. вт, 9 июн. 2020 г. в 13:29, Patrick Chilton : > Could you call wkhtmltopdf directly with System.Process? Pandoc doesn't > seem to add much value here. > > On Tue, Jun 9, 2020, 09:15 Geraldus wrote: > >> Hi dear Cafe! >> >> I'm trying to achieve trivial task to generate PDF from HTML template >> using Pandoc. >> >> So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no >> luck. >> >> I want to put few words about `pdflatex` and `xelatex` creators >> first, for someone who will struggle with same task in future, it's quite >> hard to find code examples on the web. >> >> Initially I wasn't able to render document with `pdflatex` creator. I >> would like to mention that `pdflatex` required a lot of LaTeX stuff to be >> installed, especially font packages. Also I've spent several hours to make >> rendering happen because I haven't specified template in `WriterOptions`. >> `pdflatex` do not capable to handle Cyrillic Unicode characters, and >> finally I figured out I have to use `xelatex` creator. Also I've found and >> used default template: >> >> > pandoc <- readHtml def (toStrict $ renderHtml html) >> > tpl' <- getDefaultTemplate "latex" >> > makePDF "xelatex" [] writeLaTeX (def {writerTemplate = Just tpl'}) >> pandoc >> >> But in this case I got white space instead of Cyrillic chars in resulting >> PDF and a bunch of warnings about missing chars in default font in >> console. I assume the font itself is specified in template. I've looked >> into default template and it's huge. I guess I can prepare more simple >> template for my own needs but it will take a lot of time to get familiar >> with LaTeX document syntax. >> >> I've tried `wkhtmltopdf`, which seems to be lightweight and easy >> solution. It seemed to work well except encoding issues: resulting PDF >> contains Cyrillic which rendered incorrectly. I've tried to pass >> `["encoding utf-8"]` as arguments in `makePDF` call, but this results in >> runtime error: >> >> > --margin-bottom specified in incorrect location >> >> Googling around this issue led me to glue that when I pass encoding >> argument to `wkhtmltopdf` it breaks expected arguments order in command >> which Pandoc generates. This is likely could be easily fixed, but Pandoc >> have a lot of opened issues on Github and also it requires some digging >> into `wkhtmltopdf` command line arguments syntax. I've looked into Pandoc >> sources and it seems possible to provide simple patch, but I need a >> guidance. According to `wkhtmltopdf` it distinguish global args, page >> args, cover args, table of contents args. `encoding` argument is page >> level argument, but Pandoc put extra args specified in `makePDF` after >> default page arguments (`pdfargs` in following code sample): >> >> > let args = mathArgs ++ concatMap toArgs >> > [("page-size", getField "papersize" meta') >> > ,("title", getField "title" meta') >> > ,("margin-bottom", Just $ fromMaybe "1.2in" >> > (getField "margin-bottom" meta')) >> > ,("margin-top", Just $ fromMaybe "1.25in" >> > (getField "margin-top" meta')) >> > ,("margin-right", Just $ fromMaybe "1.25in" >> > (getField "margin-right" meta')) >> > ,("margin-left", Just $ fromMaybe "1.25in" >> > (getField "margin-left" meta')) >> > ,("footer-html", getField "footer-html" meta') >> > ,("header-html", getField "header-html" meta') >> > ] ++ pdfargs >> >> Likely this breaks everything. The quickest and dirtiest workaround I see >> is to check each argument, and if it is a page level argument put it for >> each page object. Another solution may be to specify encoding for Pandoc >> document some other way, but I can't guess how to do that yet. >> >> Maybe someone have already faced similar task and knows easier way to >> render HTML to PDF with Haskell. I will very grateful for any help, advice >> or other glues how to achieve my goal. >> >> Arthur. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 albert+haskell at zeitkraut.de Tue Jun 9 08:50:01 2020 From: albert+haskell at zeitkraut.de (Albert Krewinkel) Date: Tue, 09 Jun 2020 10:50:01 +0200 Subject: [Haskell-cafe] Generating PDF from HTML with Pandoc In-Reply-To: References: Message-ID: <87zh9cvd1i.fsf@zeitkraut.de> Hi Arthur, Geraldus writes: > I'm trying to achieve trivial task to generate PDF from HTML template using > Pandoc. > > So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no luck. I second Patrick's suggestion to use wkhtmltopdf directly. You may also want to post this question to the [pandoc-discuss] mailing list, as this appears to be more of a pandoc than a Haskell question. Cheers, Albert [pandoc-discuss]: https://groups.google.com/forum/#!forum/pandoc-discuss -- Albert Krewinkel GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124 From anthony_clayden at clear.net.nz Tue Jun 9 12:44:18 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 10 Jun 2020 00:44:18 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: (Golly, this went meta rather quickly.) >> Am 08.06.20 um 16:07 schrieb amindfv at gmail.com : >>* Haskell's reputation as a welcoming community is on shakier ground *>>* than it was a few years ago, and phrases like "despite your endless *>>* ranting" work against the collegial atmosphere we're proud of.* *Thank you Tom for reminding us these messages are visible to public/posterity.* *I woke up this thread because I was worried what posterity would make of last year's discussion -- which seemed to accept the 'thought-dialogue' uncritically; certainly no indication it was intended merely as a bit of humour. (I remain unconvinced that it was.) * > Ben Franksen wrote: > To put this in perspective, here are a few citations from what I have > called "endless ranting": Let's start near the beginning of the ewd.pdf, please (capitalisation and shrieks in the original) "Haskeller: WHOA! Hold it! You are misappropriating our religion!" It was Ben who described some of my language as "ranting". How would you describe Haskeller's? I'm sure we're all aware of Why Functional Programming Matters, without going so far as making a religion of it nor thinking other paradigms don't matter. The imperative paradigm is not "antiquated" (contra what Haskeller says): Turing machines and Lambda calculus hit the world in publications in the same year. And despite Ben's finely-tuned sense of humour, you seem not so finely-tuned to the Use-mention distinction en.wikipedia.org/wiki/Use-mention_distinction. I was pointing to (i.e. mentioning) the language in that pdf as not being representative of the Haskell community I know; I was not myself using such emotionally-loaded language. I'm happy to defend my observations as matters of factual error or misrepresentation; I've presented that evidence up-thread, but briefly: >>* ... misapplying ... in a rather badly-informed way.* *Fact: EWD1300 is considering mathematical notation, not programming languages. As regards using semicolon for function composition, at no point does EWD1300 consider the clash with semicolon in ALGOL-derived languages.* *Fact: Haskeller's responses top of page 2 re operator sections are incorrect, see Haskell Report.* *Fact: Haskeller's answer re `length $ []` is wrong: try it in GHC.* >>* ... it doesn't seem to know Haskellers very well; nor Dijkstra's *>>* well-known support for Haskell in education.* *Fact: See above re over-emotional opening remarks; that "Jumping", "Beaming", "Irritated", "Exasperated", "Warily" emotionality is not how Haskellers behave in my experience.* *Fact re Haskell in Education: Dijkstra's 'To the Members of the Budget Council', in his UTexas archive.* >* ... can't even spell his first name right... * *Fact: docos on that the-magus site give "Edsgar"; it's not difficult to spell someone's name right.* >* ... it's a couple of dudes shooting the breeze.* *Fact: Ben said in an earlier message, of the authors of the pdf "obviously exaggerated ... artist's freedom ... rhetoric a bit over the top ...". In comparison 'shooting the breeze' from me seems quite mild; not "ranting".* >* ...To put it bluntly: the authors are blundering.* >* ... a bogus problem; direct consequence of the authors not *>* understanding EWD1300. * *That's the conclusion I reached after analysing their mistakes. I stand by it; see the facts I pointed out in that earlier message.* > Do you regard this as "welcoming" language? If not, where was your > concerned reply when they hit the list? (Presumably that's a q to Tom.) > IMO the occasional ranting doesn't hurt anybody as long as it is > addressed not to people but to technical shortcomings. However, the > above citations are clearly ad-hominem attacks. I disagree they're attacks; I'm pointing out technical shortcomings and mis-representations. If it's ad-anybody, the people are the faux-Haskeller and faux-EWD. > Or is your point that I directly addressed the author of the above > lines, rather than attacking some third party? I had already emailed the-magus making these same points. And of course the site doesn't accept (publicly-visible) comments. I doubt I'll get a reply, since the site seems to have died several years ago. Then where do I address the authors? I thought it appropriate I reawaken the thread here from last year. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From hcc.olemiss at gmail.com Tue Jun 9 13:22:38 2020 From: hcc.olemiss at gmail.com (Conrad Cunningham) Date: Tue, 9 Jun 2020 08:22:38 -0500 Subject: [Haskell-cafe] Generating PDF from HTML with Pandoc In-Reply-To: <87zh9cvd1i.fsf@zeitkraut.de> References: <87zh9cvd1i.fsf@zeitkraut.de> Message-ID: With Pandoc, you might try using the Context engine to generate the PDF instead of the default pdflatex. I have no idea about Cyrillic characters or processing HTML directly, but the Context engine seemed to work better when I wanted to process Markdown and generate tagged PDFs for accessibility. Conrad H. Conrad Cunningham, D.Sc. Professor Emeritus Computer & Information Science University of Mississippi, USA On Tue, Jun 9, 2020 at 3:51 AM Albert Krewinkel wrote: > Hi Arthur, > > Geraldus writes: > > > I'm trying to achieve trivial task to generate PDF from HTML template > using > > Pandoc. > > > > So far I've tried `wkhtmltopdf` and `pdflatex` creators, both with no > luck. > > I second Patrick's suggestion to use wkhtmltopdf directly. > > You may also want to post this question to the [pandoc-discuss] mailing > list, as this appears to be more of a pandoc than a Haskell question. > > Cheers, > Albert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdsmith at gmail.com Tue Jun 9 20:18:55 2020 From: cdsmith at gmail.com (Chris Smith) Date: Tue, 9 Jun 2020 16:18:55 -0400 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: References: <20200601182932.GM48101@straasha.imrryr.org> Message-ID: Hi Alberto, The answer to your question has changed: yes, this now includes client-side JavaScript frameworks. You can now find the reflex-dom tutorial from https://reflex-frp.org/tutorial running on CodeWorld at https://code.world/haskell#PahNrX2gsrB7SlSnvKvtMaw. Are there other client-side frameworks you're interested in? The one restriction that remains is that the app must start with a blank page and build the UI dynamically. The CodeWorld environment does not host assets like stylesheets and images, so if they are used, they must be either hosted elsewhere or delivered as a data-scheme URL. Hope that helps, Chris On Mon, Jun 8, 2020 at 5:42 PM Chris Smith wrote: > (Sorry for the delay. I overlooked this question.) > > > It is OK to include client-side Javascript frameworks? > > I was about to say no. But now that you've got me thinking, perhaps I > could change this. I described by thinking at > https://github.com/google/codeworld/issues/1362. So my better answer is > "not yet". > > On Tue, Jun 2, 2020 at 7:41 AM Alberto G. Corona > wrote: > >> It is OK to include client-side Javascript frameworks? >> >> El mar., 2 jun. 2020 a las 1:09, Chris Smith () >> escribió: >> >>> Thanks for the questions. >>> >>> 1. Yes, network I/O is excluded. The only real exceptions here are >>> stdin/err/out, and code that's specifically written to work in GHCJS, such >>> as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in >>> ghcjs-base. >>> >>> 2. Depending on bytestring is fine, because it has a shim that makes it >>> work with GHCJS. I believe >>> https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list of >>> shimmed libraries that you don't need to worry about depending on. >>> >>> 3. Exporting inessential TH features is fine. It's just that people >>> attempting to use your library via CodeWorld won't be able to use >>> them, since CodeWorld's web interface will refuse to build anything that >>> enables Template Haskell. >>> >>> It looks like your project is completely excluded only because of the >>> network I/O. If the network I/O is not necessary and you could exclude the >>> dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if >>> impl(ghcjs)" in the cabal file, then it could still work. But, of course, >>> of the network I/O is the whole point, then it's not going to work out. >>> JavaScript >>> >>> On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni >>> wrote: >>> >>>> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: >>>> >>>> > >>>> https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal >>>> > >>>> > Packages that fit here are: >>>> > >>>> > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a >>>> web >>>> > browser, there is no filesystem, for example. >>>> >>>> I assume this also precludes network I/O? >>>> >>>> > 2. Do not rely on native libraries, or have dependencies that do. >>>> This all >>>> > depends on the library building with GHCJS. >>>> >>>> I guess this also excludes `bytestring`, which uses memcpy(), memchr(), >>>> and writes directly allocated memory? >>>> >>>> -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation >>>> for GHC >>>> -- >>>> mallocByteString :: Int -> IO (ForeignPtr a) >>>> mallocByteString = mallocPlainForeignPtrBytes >>>> >>>> and all of its dependencies? >>>> >>>> > 3. Do not require use of Template Haskell by clients. It's okay if >>>> your >>>> > package needs template Haskell to build, but people using your >>>> library via >>>> > CodeWorld cannot yet use TH themselves. >>>> >>>> Is it that Template Haskell features in modules are not available to >>>> users, or that modules that export even "inessential" TH features are >>>> precluded. >>>> >>>> For example, can the platform support a module that exports a >>>> convenience TH "splice", if the same can be done slightly less >>>> conveniently (e.g. run-time, rather than compile-time error checks) at >>>> runtime via alternative functions? >>>> >>>> [ My current project does network I/O, uses `bytestring`, and provides >>>> TH-splices for two types of compile-time validated literals, so I >>>> would assume is a non-starter on all three counts. ] >>>> >>>> -- >>>> 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. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> >> -- >> Alberto. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Tue Jun 9 21:52:55 2020 From: agocorona at gmail.com (Alberto G. Corona) Date: Tue, 9 Jun 2020 23:52:55 +0200 Subject: [Haskell-cafe] Library maintainers: Include your library in CodeWorld web-based Haskell environment In-Reply-To: References: <20200601182932.GM48101@straasha.imrryr.org> Message-ID: Thanks Chris. That is great news. I just wanted to include the client-side of my own framework, axiom. https://hackage.haskell.org/package/axiom El mar., 9 jun. 2020 a las 22:19, Chris Smith () escribió: > Hi Alberto, > > The answer to your question has changed: yes, this now includes > client-side JavaScript frameworks. You can now find the reflex-dom > tutorial from https://reflex-frp.org/tutorial running on CodeWorld at > https://code.world/haskell#PahNrX2gsrB7SlSnvKvtMaw. > > Are there other client-side frameworks you're interested in? The one > restriction that remains is that the app must start with a blank page and > build the UI dynamically. The CodeWorld environment does not host assets > like stylesheets and images, so if they are used, they must be either > hosted elsewhere or delivered as a data-scheme URL. > > Hope that helps, > Chris > > On Mon, Jun 8, 2020 at 5:42 PM Chris Smith wrote: > >> (Sorry for the delay. I overlooked this question.) >> >> > It is OK to include client-side Javascript frameworks? >> >> I was about to say no. But now that you've got me thinking, perhaps I >> could change this. I described by thinking at >> https://github.com/google/codeworld/issues/1362. So my better answer is >> "not yet". >> >> On Tue, Jun 2, 2020 at 7:41 AM Alberto G. Corona >> wrote: >> >>> It is OK to include client-side Javascript frameworks? >>> >>> El mar., 2 jun. 2020 a las 1:09, Chris Smith () >>> escribió: >>> >>>> Thanks for the questions. >>>> >>>> 1. Yes, network I/O is excluded. The only real exceptions here are >>>> stdin/err/out, and code that's specifically written to work in GHCJS, such >>>> as JavaScript.Web.XMLHttpRequest and JavaScript.Web.WebSocket modules in >>>> ghcjs-base. >>>> >>>> 2. Depending on bytestring is fine, because it has a shim that makes it >>>> work with GHCJS. I believe >>>> https://github.com/ghcjs/ghcjs/tree/ghc-8.6/lib/boot/shims is a list >>>> of shimmed libraries that you don't need to worry about depending on. >>>> >>>> 3. Exporting inessential TH features is fine. It's just that people >>>> attempting to use your library via CodeWorld won't be able to use >>>> them, since CodeWorld's web interface will refuse to build anything that >>>> enables Template Haskell. >>>> >>>> It looks like your project is completely excluded only because of the >>>> network I/O. If the network I/O is not necessary and you could exclude the >>>> dependency using a combination of "#ifdef ghcjs_HOST_OS" in source and "if >>>> impl(ghcjs)" in the cabal file, then it could still work. But, of course, >>>> of the network I/O is the whole point, then it's not going to work out. >>>> JavaScript >>>> >>>> On Mon, Jun 1, 2020 at 2:30 PM Viktor Dukhovni >>>> wrote: >>>> >>>>> On Mon, Jun 01, 2020 at 11:37:12AM -0400, Chris Smith wrote: >>>>> >>>>> > >>>>> https://github.com/google/codeworld/blob/master/codeworld-available-pkgs/codeworld-available-pkgs.cabal >>>>> > >>>>> > Packages that fit here are: >>>>> > >>>>> > 1. No I/O, except for stdin/out/err. Since CodeWorld runs code in a >>>>> web >>>>> > browser, there is no filesystem, for example. >>>>> >>>>> I assume this also precludes network I/O? >>>>> >>>>> > 2. Do not rely on native libraries, or have dependencies that do. >>>>> This all >>>>> > depends on the library building with GHCJS. >>>>> >>>>> I guess this also excludes `bytestring`, which uses memcpy(), memchr(), >>>>> and writes directly allocated memory? >>>>> >>>>> -- | Wrapper of 'mallocForeignPtrBytes' with faster implementation >>>>> for GHC >>>>> -- >>>>> mallocByteString :: Int -> IO (ForeignPtr a) >>>>> mallocByteString = mallocPlainForeignPtrBytes >>>>> >>>>> and all of its dependencies? >>>>> >>>>> > 3. Do not require use of Template Haskell by clients. It's okay if >>>>> your >>>>> > package needs template Haskell to build, but people using your >>>>> library via >>>>> > CodeWorld cannot yet use TH themselves. >>>>> >>>>> Is it that Template Haskell features in modules are not available to >>>>> users, or that modules that export even "inessential" TH features are >>>>> precluded. >>>>> >>>>> For example, can the platform support a module that exports a >>>>> convenience TH "splice", if the same can be done slightly less >>>>> conveniently (e.g. run-time, rather than compile-time error checks) at >>>>> runtime via alternative functions? >>>>> >>>>> [ My current project does network I/O, uses `bytestring`, and provides >>>>> TH-splices for two types of compile-time validated literals, so I >>>>> would assume is a non-starter on all three counts. ] >>>>> >>>>> -- >>>>> 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. >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> Only members subscribed via the mailman list are allowed to post. >>> >>> >>> >>> -- >>> Alberto. >>> >> -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Wed Jun 10 06:38:36 2020 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Wed, 10 Jun 2020 18:38:36 +1200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: > Richard O'Keefe wrote: > ... More seriously, in "f x", there is an explicit > operator already. It's "f". The space is needed for lexical > reasons only. If you say no, functions are not operators -- > though in Haskell infix operators are functions -- but > application is the operator, so you should write "f @ x " (usual > FP notation) or "f.x" (Dijkstra), then although it isn't > technically true, I've always felt that there is an infinite > regress lurking in the background: > if x + y means (+) x y > which really stands for (+)@x @ y > then shouldn't that in turn stand for (@)((@)(+)x)y > and what should _that_ stand for? Heh, heh there's another corner where Haskell semantics appears to give an infinite regress; and we have to suppose there's some internal magic that can't be expressed in the surface language: Report section 6.4.1 Numeric Literals. "An integer literal represents the application of the function `fromInteger` to the appropriate value of type `Integer`." OK. How do we write in Haskell that "appropriate value"? We could write `7 :: Integer` but that's shorthand for `(fromInteger #7#) :: Integer`, in which I've used `#7#` to denote the "appropriate value" doo-hickey. There's no way in Haskell to write a literal that's type `Integer`, except by invoking `fromInteger`. `(fromInteger (7 :: Integer)) :: Integer` ? Both the explicit and implicit `fromInteger` in there are no-ops. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Wed Jun 10 13:23:59 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Wed, 10 Jun 2020 14:23:59 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: Message-ID: Hi Simon, I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. Oleg is also a maintainer. Cheers, Chris On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > Dhall documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Wed Jun 10 13:55:26 2020 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Wed, 10 Jun 2020 15:55:26 +0200 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: Message-ID: That's good to hear, Chris! Can I suggest to include a version of this explanation in the README? Maybe you could also suggest that people post their questions on SO using the haskell-lucid tag: https://stackoverflow.com/questions/tagged/haskell-lucid Cheers! Simon Am Mi., 10. Juni 2020 um 15:23 Uhr schrieb chris done : > > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > Dhall documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > > From haskell-cafe at chrisdone.com Wed Jun 10 14:10:19 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Wed, 10 Jun 2020 15:10:19 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: Message-ID: <437eabfe-749c-40e1-83bf-209bb4816628@www.fastmail.com> I'll enable the issue tracker with an issue template explaining this. On Wed, Jun 10, 2020, at 2:23 PM, chris done wrote: > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: >> Hi! >> >> I recently noticed that the issue tracker for the lucid package at >> >> https://github.com/chrisdone/lucid >> >> has been disabled. Does this have any implications for the future >> maintenance of the package? Is anyone still committed to maintaining >> the package? >> >> (I've CC'd Oleg who made the most recent commit to the repo.) >> >> The context for my question is that we'd like to use lucid for the >> Dhall documentation generator that is being developed as a part of >> this year's GSoC. >> >> Thanks! >> Simon >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Wed Jun 10 14:23:34 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Wed, 10 Jun 2020 15:23:34 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: Message-ID: <91542fc5-6a6e-4766-bb64-83d6991c2b0a@www.fastmail.com> That's an interesting idea, Simon. Thanks. On Wed, Jun 10, 2020, at 2:55 PM, Simon Jakobi wrote: > That's good to hear, Chris! > > Can I suggest to include a version of this explanation in the README? > > Maybe you could also suggest that people post their questions on SO > using the haskell-lucid tag: > https://stackoverflow.com/questions/tagged/haskell-lucid > > Cheers! > Simon > > Am Mi., 10. Juni 2020 um 15:23 Uhr schrieb chris done > : > > > > Hi Simon, > > > > I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. > > > > In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. > > > > However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. > > > > Oleg is also a maintainer. > > > > Cheers, > > > > Chris > > > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > > > Hi! > > > > I recently noticed that the issue tracker for the lucid package at > > > > https://github.com/chrisdone/lucid > > > > has been disabled. Does this have any implications for the future > > maintenance of the package? Is anyone still committed to maintaining > > the package? > > > > (I've CC'd Oleg who made the most recent commit to the repo.) > > > > The context for my question is that we'd like to use lucid for the > > Dhall documentation generator that is being developed as a part of > > this year's GSoC. > > > > Thanks! > > Simon > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Wed Jun 10 16:06:19 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Wed, 10 Jun 2020 17:06:19 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> Message-ID: <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> Hi Gabriel, I enabled the issue tracker earlier today for those reasons. Unfortunately, GitHub doesn't distinguish between "mailing list where chat can occur" and "tasks the devs plan to put time and energy into", it's all dumped into one pot. I consider this a shortcoming of GitHub. It actually distorts the meaning of "to maintain" from "keeping the software correct and working" to "responding to and acknowledging any and all commentary by anyone at any time for any duration, teaching fellow developers about how to use Git, GitHub, among other mentorship tasks" the temporary or prolonged neglect of which is deemed to be not putting on a good show, or in your own words, "not maintaining it". The more I reflect on it, the more I see why many project maintainers burn out on GitHub. I will continue using lucid and patching it to move with the times as GHC's type system moves along and HTML 5 elements/attributes are added, and merge pull requests related to these stated goals, for the foreseeable future, but I plan to do no more than that. If that's not good enough for Dhall, then there are plenty of other options.[1] Cheers, Chris [1]: https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing_an_html_library/ On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > Would it be possible to leave the issue tracker on but just disable your own email notifications for the repository if you do not plan to maintain it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever is the maintainer at the time) > * We would like to know if other people share the same problem we do (or vice versa, educate other users of problems we are having and potential workarounds) > >> On Jun 10, 2020, at 6:23 AM, chris done wrote: >> >> Hi Simon, >> >> I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. >> >> In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. >> >> However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. >> >> Oleg is also a maintainer. >> >> Cheers, >> >> Chris >> >> On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: >>> Hi! >>> >>> I recently noticed that the issue tracker for the lucid package at >>> >>> https://github.com/chrisdone/lucid >>> >>> has been disabled. Does this have any implications for the future >>> maintenance of the package? Is anyone still committed to maintaining >>> the package? >>> >>> (I've CC'd Oleg who made the most recent commit to the repo.) >>> >>> The context for my question is that we'd like to use lucid for the >>> documentation generator that is being developed as a part of >>> this year's GSoC. >>> >>> Thanks! >>> Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Jun 10 16:30:03 2020 From: david.feuer at gmail.com (David Feuer) Date: Wed, 10 Jun 2020 12:30:03 -0400 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> Message-ID: Your experience is not mine. Yes, I see support requests and general chatter on GitHub issue trackers I follow, but the volume is miniscule. In my own projects, I tend to close those down pretty quickly unless I think there's a special circumstance. On Wed, Jun 10, 2020, 12:05 PM chris done wrote: > Hi Gabriel, > > I enabled the issue tracker earlier today for those reasons. > > Unfortunately, GitHub doesn't distinguish between "mailing list where chat > can occur" and "tasks the devs plan to put time and energy into", it's all > dumped into one pot. I consider this a shortcoming of GitHub. It actually > distorts the meaning of "to maintain" from "keeping the software correct > and working" to "responding to and acknowledging any and all commentary by > anyone at any time for any duration, teaching fellow developers about how > to use Git, GitHub, among other mentorship tasks" the temporary or > prolonged neglect of which is deemed to be not putting on a good show, or > in your own words, "not maintaining it". The more I reflect on it, the more > I see why many project maintainers burn out on GitHub. > > I will continue using lucid and patching it to move with the times as > GHC's type system moves along and HTML 5 elements/attributes are added, and > merge pull requests related to these stated goals, for the foreseeable > future, but I plan to do no more than that. If that's not good enough > for Dhall, then there are plenty of other options.[1] > > Cheers, > > Chris > > [1]: > https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing_an_html_library/ > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > Would it be possible to leave the issue tracker on but just disable your > own email notifications for the repository if you do not plan to maintain > it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever > is the maintainer at the time) > * We would like to know if other people share the same problem we do (or > vice versa, educate other users of problems we are having and potential > workarounds) > > On Jun 10, 2020, at 6:23 AM, chris done > wrote: > > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, > nothing substantial has changed in the 6 years since its release. Just > small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage > would cause disruption and I would encourage that to be achieved in a > separate package with a new name. In review, I'm very happy with Lucid's > design and plan to maintain it long-term into the future for as long as > HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker > would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Wed Jun 10 16:39:08 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Wed, 10 Jun 2020 17:39:08 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> Message-ID: <58252529-507a-4c18-b8f3-eb8b243d6fab@www.fastmail.com> Hi David, Thanks for sharing your experience. Cheers, Chris On Wed, Jun 10, 2020, at 5:30 PM, David Feuer wrote: > Your experience is not mine. Yes, I see support requests and general chatter on GitHub issue trackers I follow, but the volume is miniscule. In my own projects, I tend to close those down pretty quickly unless I think there's a special circumstance. > > On Wed, Jun 10, 2020, 12:05 PM chris done wrote: >> __ >> Hi Gabriel, >> >> I enabled the issue tracker earlier today for those reasons. >> >> Unfortunately, GitHub doesn't distinguish between "mailing list where chat can occur" and "tasks the devs plan to put time and energy into", it's all dumped into one pot. I consider this a shortcoming of GitHub. It actually distorts the meaning of "to maintain" from "keeping the software correct and working" to "responding to and acknowledging any and all commentary by anyone at any time for any duration, teaching fellow developers about how to use Git, GitHub, among other mentorship tasks" the temporary or prolonged neglect of which is deemed to be not putting on a good show, or in your own words, "not maintaining it". The more I reflect on it, the more I see why many project maintainers burn out on GitHub. >> >> I will continue using lucid and patching it to move with the times as GHC's type system moves along and HTML 5 elements/attributes are added, and merge pull requests related to these stated goals, for the foreseeable future, but I plan to do no more than that. If that's not good enough for Dhall, then there are plenty of other options.[1] >> >> Cheers, >> >> Chris >> >> [1]: https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing_an_html_library/ >> >> On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: >>> Would it be possible to leave the issue tracker on but just disable your own email notifications for the repository if you do not plan to maintain it? The two main reasons I suggest this are: >>> >>> * We would like a way to be able to petition Oleg for changes (or whoever is the maintainer at the time) >>> * We would like to know if other people share the same problem we do (or vice versa, educate other users of problems we are having and potential workarounds) >>> >>>> On Jun 10, 2020, at 6:23 AM, chris done wrote: >>>> >>>> Hi Simon, >>>> >>>> I am still maintaining and actively using the package. Architecture-wise, nothing substantial has changed in the 6 years since its release. Just small additions. This package pretty much maintains itself. PRs come and go. >>>> >>>> In fact, any kind of overhauls or user-facing design changes at this stage would cause disruption and I would encourage that to be achieved in a separate package with a new name. In review, I'm very happy with Lucid's design and plan to maintain it long-term into the future for as long as HTML is relevant. >>>> >>>> However, I am providing no Q&A or "tech support". Having an issue tracker would say otherwise. >>>> >>>> Oleg is also a maintainer. >>>> >>>> Cheers, >>>> >>>> Chris >>>> >>>> On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: >>>>> Hi! >>>>> >>>>> I recently noticed that the issue tracker for the lucid package at >>>>> >>>>> https://github.com/chrisdone/lucid >>>>> >>>>> has been disabled. Does this have any implications for the future >>>>> maintenance of the package? Is anyone still committed to maintaining >>>>> the package? >>>>> >>>>> (I've CC'd Oleg who made the most recent commit to the repo.) >>>>> >>>>> The context for my question is that we'd like to use lucid for the >>>>> documentation generator that is being developed as a part of >>>>> this year's GSoC. >>>>> >>>>> Thanks! >>>>> Simon >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Jun 10 16:56:23 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 10 Jun 2020 12:56:23 -0400 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> Message-ID: Hey Chris, I definitely feel the same way about GitHub sometimes. I think some of this is often fallout from commercial development processes when a product is evolved using the wrong measurements for evaluating success or failures of change over time. I personally find nontechnical discourse beyond positive exhortations on issue trackers stressful and distracting. (This is an issue with linear threading more broadly when there’s any meaningful emotional dimension). Whatever approach (ethically!) facilitates you sustainably working on projects you have generously made open source / or act as the maintainer for, it is entirely your prerogative to work on them however you like. It’s all neat stuff and keep on having fun! Cheers -Carter On Wed, Jun 10, 2020 at 12:07 PM chris done wrote: > Hi Gabriel, > > I enabled the issue tracker earlier today for those reasons. > > Unfortunately, GitHub doesn't distinguish between "mailing list where chat > can occur" and "tasks the devs plan to put time and energy into", it's all > dumped into one pot. I consider this a shortcoming of GitHub. It actually > distorts the meaning of "to maintain" from "keeping the software correct > and working" to "responding to and acknowledging any and all commentary by > anyone at any time for any duration, teaching fellow developers about how > to use Git, GitHub, among other mentorship tasks" the temporary or > prolonged neglect of which is deemed to be not putting on a good show, or > in your own words, "not maintaining it". The more I reflect on it, the more > I see why many project maintainers burn out on GitHub. > > I will continue using lucid and patching it to move with the times as > GHC's type system moves along and HTML 5 elements/attributes are added, and > merge pull requests related to these stated goals, for the foreseeable > future, but I plan to do no more than that. If that's not good enough > for Dhall, then there are plenty of other options.[1] > > Cheers, > > Chris > > [1]: > https://www.reddit.com/r/haskell/comments/h05uwn/experience_report_choosing_an_html_library/ > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > Would it be possible to leave the issue tracker on but just disable your > own email notifications for the repository if you do not plan to maintain > it? The two main reasons I suggest this are: > > * We would like a way to be able to petition Oleg for changes (or whoever > is the maintainer at the time) > * We would like to know if other people share the same problem we do (or > vice versa, educate other users of problems we are having and potential > workarounds) > > On Jun 10, 2020, at 6:23 AM, chris done > wrote: > > Hi Simon, > > I am still maintaining and actively using the package. Architecture-wise, > nothing substantial has changed in the 6 years since its release. Just > small additions. This package pretty much maintains itself. PRs come and go. > > In fact, any kind of overhauls or user-facing design changes at this stage > would cause disruption and I would encourage that to be achieved in a > separate package with a new name. In review, I'm very happy with Lucid's > design and plan to maintain it long-term into the future for as long as > HTML is relevant. > > However, I am providing no Q&A or "tech support". Having an issue tracker > would say otherwise. > > Oleg is also a maintainer. > > Cheers, > > Chris > > On Tue, Jun 9, 2020, at 5:27 AM, Simon Jakobi wrote: > > Hi! > > I recently noticed that the issue tracker for the lucid package at > > https://github.com/chrisdone/lucid > > has been disabled. Does this have any implications for the future > maintenance of the package? Is anyone still committed to maintaining > the package? > > (I've CC'd Oleg who made the most recent commit to the repo.) > > The context for my question is that we'd like to use lucid for the > documentation generator that is being developed as a part of > this year's GSoC. > > Thanks! > Simon > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Wed Jun 10 17:14:48 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 10 Jun 2020 18:14:48 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> Message-ID: <20200610171448.GA18004@cloudinit-builder> There is perhaps a happy medium here, whereby interested parties start a "friends-of-lucid" repository. Unlimited amounts of discussion could take place there, and information and PRs could be forwarded upstream as necessary, in a way that is respectful of the upstream maintainer. On Wed, Jun 10, 2020 at 05:06:19PM +0100, chris done wrote: > Unfortunately, GitHub doesn't distinguish between "mailing list > where chat can occur" and "tasks the devs plan to put time and > energy into", it's all dumped into one pot. [...] > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > Would it be possible to leave the issue tracker on but just > > disable your own email notifications for the repository if you do > > not plan to maintain it? The two main reasons I suggest this are: > > > > * We would like a way to be able to petition Oleg for changes (or > > whoever is the maintainer at the time) > > > * We would like to know if other people share the same problem we > > do (or vice versa, educate other users of problems we are having > > and potential workarounds) From carter.schonwald at gmail.com Wed Jun 10 18:16:39 2020 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 10 Jun 2020 14:16:39 -0400 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <20200610171448.GA18004@cloudinit-builder> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> <20200610171448.GA18004@cloudinit-builder> Message-ID: Absolutely, but is it viable to ask every maintainer to juggle that discussion about community management fused with technical direction? Maybe? Maybe not. So many things are social constructs fused with how technological systems interact with them! On Wed, Jun 10, 2020 at 1:15 PM Tom Ellis < tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > There is perhaps a happy medium here, whereby interested parties start > a "friends-of-lucid" repository. Unlimited amounts of discussion > could take place there, and information and PRs could be forwarded > upstream as necessary, in a way that is respectful of the upstream > maintainer. > > On Wed, Jun 10, 2020 at 05:06:19PM +0100, chris done wrote: > > Unfortunately, GitHub doesn't distinguish between "mailing list > > where chat can occur" and "tasks the devs plan to put time and > > energy into", it's all dumped into one pot. > [...] > > > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > > Would it be possible to leave the issue tracker on but just > > > disable your own email notifications for the repository if you do > > > not plan to maintain it? The two main reasons I suggest this are: > > > > > > * We would like a way to be able to petition Oleg for changes (or > > > whoever is the maintainer at the time) > > > > > * We would like to know if other people share the same problem we > > > do (or vice versa, educate other users of problems we are having > > > and potential workarounds) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Wed Jun 10 19:37:04 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Wed, 10 Jun 2020 21:37:04 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] Message-ID: <8bd3d44147038fa1253e38fe9e61c5bf9daf487d.camel@aatal-apotheke.de> Now I can't tell whether you're teasing to keep this thread alive. If it is humour, it is lost on me. > Report section 6.4.1 Numeric Literals. "An integer literal represents > the application of the function `fromInteger` to the appropriate > value > of type `Integer`." > > OK. How do we write in Haskell that "appropriate value"? > To me that part of the report is obviously about compile-time code generation. The sentence itself is not recursive, it is "literal" versus "value". The two concepts live in different domains. Why do you think its meaning may be recursive? I imagine that when the compiler sees the literal 7, it de-sugars to (fromInteger (mkInteger ...)) where the inner expression is code from GHC.Integer that does not invoke fromInteger again. When the entire expression is to be of type Integer, then the fromInteger dictionary lookup replaces that by id. So the entire expression can be optimized to be whatever core expression generates the Integer seven, most likely S# 7#. Olaf From oleg.grenrus at iki.fi Thu Jun 11 16:42:41 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 11 Jun 2020 19:42:41 +0300 Subject: [Haskell-cafe] Future of lucid In-Reply-To: <20200610171448.GA18004@cloudinit-builder> References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> <20200610171448.GA18004@cloudinit-builder> Message-ID: FWIW, GitHub will soon (maybe) have discussions: https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/#discussions - Oleg On 10.6.2020 20.14, Tom Ellis wrote: > There is perhaps a happy medium here, whereby interested parties start > a "friends-of-lucid" repository. Unlimited amounts of discussion > could take place there, and information and PRs could be forwarded > upstream as necessary, in a way that is respectful of the upstream > maintainer. > > On Wed, Jun 10, 2020 at 05:06:19PM +0100, chris done wrote: >> Unfortunately, GitHub doesn't distinguish between "mailing list >> where chat can occur" and "tasks the devs plan to put time and >> energy into", it's all dumped into one pot. > [...] >> On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: >>> Would it be possible to leave the issue tracker on but just >>> disable your own email notifications for the repository if you do >>> not plan to maintain it? The two main reasons I suggest this are: >>> >>> * We would like a way to be able to petition Oleg for changes (or >>> whoever is the maintainer at the time) >>> * We would like to know if other people share the same problem we >>> do (or vice versa, educate other users of problems we are having >>> and potential workarounds) > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 ben.franksen at online.de Thu Jun 11 16:49:54 2020 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 11 Jun 2020 18:49:54 +0200 Subject: [Haskell-cafe] Looking for a paper [Dijkstra-Dot] In-Reply-To: References: Message-ID: Dear Anthony I appreciate that you explained the reasoning behind your dislike of the way the authors express their point of view. Yes, the way the Haskeller is painted there is not favourable. And yes, the authors make a few mistakes and don't appear to be experts, I'll give you that. Still, I personally found it funny to read and it gave me pause to think about the issues mentioned. Call it satire if that helps. As Tucholsky once said: "Was darf die Satire? Alles." Cheers Ben Am 09.06.20 um 14:44 schrieb Anthony Clayden: > (Golly, this went meta rather quickly.) > >>> Am 08.06.20 um 16:07 schrieb amindfv at gmail.com : >>> * Haskell's reputation as a welcoming community is on shakier ground > *>>* than it was a few years ago, and phrases like "despite your endless > *>>* ranting" work against the collegial atmosphere we're proud of.* > > > *Thank you Tom for reminding us these messages are visible to public/posterity.* > > *I woke up this thread because I was worried what posterity would make > of last year's discussion -- which seemed to accept the > 'thought-dialogue' uncritically; certainly no indication it was > intended merely as a bit of humour. (I remain unconvinced that it > was.) > * > >> Ben Franksen wrote: > >> To put this in perspective, here are a few citations from what I have >> called "endless ranting": > > Let's start near the beginning of the ewd.pdf, please (capitalisation > and shrieks in the original) > > "Haskeller: WHOA! Hold it! You are misappropriating our religion!" > > It was Ben who described some of my language as "ranting". How would > you describe Haskeller's? I'm sure we're all aware of Why Functional > Programming Matters, without going so far as making a religion of it > nor thinking other paradigms don't matter. The imperative paradigm is > not "antiquated" (contra what Haskeller says): Turing machines and > Lambda calculus hit the world in publications in the same year. > > And despite Ben's finely-tuned sense of humour, you seem not so > finely-tuned to the Use-mention distinction > en.wikipedia.org/wiki/Use-mention_distinction. > > I was pointing to (i.e. mentioning) the language in that pdf as not > being representative of the Haskell community I know; I was not myself > using such emotionally-loaded language. > > I'm happy to defend my observations as matters of factual error or > misrepresentation; I've presented that evidence up-thread, but > briefly: > >>> * ... misapplying ... in a rather badly-informed way.* > > *Fact: EWD1300 is considering mathematical notation, not programming > languages. As regards using semicolon for function composition, at no > point does EWD1300 consider the clash with semicolon in ALGOL-derived > languages.* > > *Fact: Haskeller's responses top of page 2 re operator sections are > incorrect, see Haskell Report.* > > *Fact: Haskeller's answer re `length $ []` is wrong: try it in GHC.* > > >>> * ... it doesn't seem to know Haskellers very well; nor Dijkstra's > *>>* well-known support for Haskell in education.* > > *Fact: See above re over-emotional opening remarks; that "Jumping", > "Beaming", "Irritated", "Exasperated", "Warily" emotionality is not > how Haskellers behave in my experience.* > > *Fact re Haskell in Education: Dijkstra's 'To the Members of the > Budget Council', in his UTexas archive.* > >> * ... can't even spell his first name right... * > > *Fact: docos on that the-magus site give "Edsgar"; it's not difficult > to spell someone's name right.* > >> * ... it's a couple of dudes shooting the breeze.* > > *Fact: Ben said in an earlier message, of the authors of the pdf > "obviously exaggerated ... artist's freedom ... rhetoric a bit over > the top ...". In comparison 'shooting the breeze' from me seems quite > mild; not "ranting".* > > >> * ...To put it bluntly: the authors are blundering.* > >> * ... a bogus problem; direct consequence of the authors not > *>* understanding EWD1300. > * > > *That's the conclusion I reached after analysing their mistakes. I > stand by it; see the facts I pointed out in that earlier message.* > >> Do you regard this as "welcoming" language? If not, where was your >> concerned reply when they hit the list? > > (Presumably that's a q to Tom.) > > >> IMO the occasional ranting doesn't hurt anybody as long as it is >> addressed not to people but to technical shortcomings. However, the >> above citations are clearly ad-hominem attacks. > > > I disagree they're attacks; I'm pointing out technical shortcomings > and mis-representations. If it's ad-anybody, the people are the > faux-Haskeller and faux-EWD. > > >> Or is your point that I directly addressed the author of the above >> lines, rather than attacking some third party? > > > I had already emailed the-magus making these same points. And of > course the site doesn't accept (publicly-visible) comments. I doubt > I'll get a reply, since the site seems to have died several years ago. > Then where do I address the authors? I thought it appropriate I > reawaken the thread here from last year. > > > AntC > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Thu Jun 11 18:02:10 2020 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 11 Jun 2020 19:02:10 +0100 Subject: [Haskell-cafe] Future of lucid In-Reply-To: References: <0B785865-CF18-4B53-9EB7-96E7B0B11DB7@gmail.com> <5bef90e6-5f00-49af-b3c0-4a4a307bfd3e@www.fastmail.com> <20200610171448.GA18004@cloudinit-builder> Message-ID: <20200611180210.GE18004@cloudinit-builder> For what it's worth, I'm imagining this being done by interested parties without the involvement of the maintainer. On Wed, Jun 10, 2020 at 02:16:39PM -0400, Carter Schonwald wrote: > Absolutely, but is it viable to ask every maintainer to juggle that > discussion about community management fused with technical direction? > Maybe? Maybe not. So many things are social constructs fused with how > technological systems interact with them! > > On Wed, Jun 10, 2020 at 1:15 PM Tom Ellis < > tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote: > > > There is perhaps a happy medium here, whereby interested parties start > > a "friends-of-lucid" repository. Unlimited amounts of discussion > > could take place there, and information and PRs could be forwarded > > upstream as necessary, in a way that is respectful of the upstream > > maintainer. > > > > On Wed, Jun 10, 2020 at 05:06:19PM +0100, chris done wrote: > > > Unfortunately, GitHub doesn't distinguish between "mailing list > > > where chat can occur" and "tasks the devs plan to put time and > > > energy into", it's all dumped into one pot. > > [...] > > > > > > On Wed, Jun 10, 2020, at 4:26 PM, Gabriel Gonzalez wrote: > > > > Would it be possible to leave the issue tracker on but just > > > > disable your own email notifications for the repository if you do > > > > not plan to maintain it? The two main reasons I suggest this are: > > > > > > > > * We would like a way to be able to petition Oleg for changes (or > > > > whoever is the maintainer at the time) > > > > > > > * We would like to know if other people share the same problem we > > > > do (or vice versa, educate other users of problems we are having > > > > and potential workarounds) > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view 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 guthrie at miu.edu Fri Jun 12 17:33:47 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Fri, 12 Jun 2020 17:33:47 +0000 Subject: [Haskell-cafe] transcoding - Haskell?! Message-ID: I think it would choke on Haskell code! Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL's - that the code becomes very dense and context specific. Facebook's TransCoder AI Converts Code From One Programming Language Into Another VentureBeat Kyle Wiggers June 9, 2020 Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as "a neural transcompiler," uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, "TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin." Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From branimir.maksimovic at gmail.com Fri Jun 12 17:44:01 2020 From: branimir.maksimovic at gmail.com (Branimir Maksimovic) Date: Fri, 12 Jun 2020 19:44:01 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: References: Message-ID: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> It would choke on assembler as well. Digital computer hard AI is impossible, because there is no algorithm for making algorithms. Mathematicaly impossible... Greets, Branimir. On 6/12/20 7:33 PM, Gregory Guthrie wrote: > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that > the code becomes very dense and context specific. > > *Facebook's TransCoder AI Converts Code From One Programming Language > Into Another* > */VentureBeat/*/ > Kyle Wiggers > June 9, 2020/ > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook > researchers describe as “a neural transcompiler,” uses an unsupervised > learning approach to translate between languages like C++, Java, and > Python. The researchers trained TransCoder on a public GitHub corpus > featuring more than 2.8 million open source repositories. To evaluate > its capabilities, the researchers extracted 852 parallel functions in > C++, Java, and Python from the online GeeksforGeeks platform and > developed a new computational accuracy metric that tests whether > hypothesis functions generate the same outputs as a reference when > given the same inputs. Wrote the researchers, “TransCoder can easily > be generalized to any programming language, does not require any > expert knowledge, and outperforms commercial solutions by a large margin.” > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 Fri Jun 12 18:14:18 2020 From: migmit at gmail.com (MigMit) Date: Fri, 12 Jun 2020 20:14:18 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> References: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> Message-ID: <9645E2CA-F7E8-4BFF-9D09-36CBCC09D0AD@gmail.com> I wonder if this would be true: https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressive-results/ > On 12 Jun 2020, at 19:44, Branimir Maksimovic wrote: > > It would choke on assembler as well. Digital computer hard AI is impossible, because there is no > > algorithm for making algorithms. Mathematicaly impossible... > > Greets, Branimir. > > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: >> I think it would choke on Haskell code! >> Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL’s – that the code becomes very dense and context specific. >> >> Facebook's TransCoder AI Converts Code From One Programming Language Into Another >> VentureBeat >> Kyle Wiggers >> June 9, 2020 >> >> Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as “a neural transcompiler,” uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, “TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin.” >> >> >> >> >> Dr. Gregory Guthrie >> Maharishi International University >> ---------------------------------------------------------------- >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view 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 branimir.maksimovic at gmail.com Fri Jun 12 18:25:58 2020 From: branimir.maksimovic at gmail.com (Branimir Maksimovic) Date: Fri, 12 Jun 2020 20:25:58 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: <9645E2CA-F7E8-4BFF-9D09-36CBCC09D0AD@gmail.com> References: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> <9645E2CA-F7E8-4BFF-9D09-36CBCC09D0AD@gmail.com> Message-ID: As long as there is math behind that it could work. There is no algorithm for creative thinking. Same way that if you put it on rng 1000 monkeys will sooner or later create Shakespeare :P Greets, Branimir. On 6/12/20 8:14 PM, MigMit wrote: > I wonder if this would be true: https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressive-results/ > >> On 12 Jun 2020, at 19:44, Branimir Maksimovic wrote: >> >> It would choke on assembler as well. Digital computer hard AI is impossible, because there is no >> >> algorithm for making algorithms. Mathematicaly impossible... >> >> Greets, Branimir. >> >> >> >> On 6/12/20 7:33 PM, Gregory Guthrie wrote: >>> I think it would choke on Haskell code! >>> Haskell has so many language extensions and pragmas, and people use many local extensions with monads to basically create DIY DSL’s – that the code becomes very dense and context specific. >>> >>> Facebook's TransCoder AI Converts Code From One Programming Language Into Another >>> VentureBeat >>> Kyle Wiggers >>> June 9, 2020 >>> >>> Facebook says its TransCoder can convert code from one high-level programming language into another. The system, which Facebook researchers describe as “a neural transcompiler,” uses an unsupervised learning approach to translate between languages like C++, Java, and Python. The researchers trained TransCoder on a public GitHub corpus featuring more than 2.8 million open source repositories. To evaluate its capabilities, the researchers extracted 852 parallel functions in C++, Java, and Python from the online GeeksforGeeks platform and developed a new computational accuracy metric that tests whether hypothesis functions generate the same outputs as a reference when given the same inputs. Wrote the researchers, “TransCoder can easily be generalized to any programming language, does not require any expert knowledge, and outperforms commercial solutions by a large margin.” >>> >>> >>> >>> >>> Dr. Gregory Guthrie >>> Maharishi International University >>> ---------------------------------------------------------------- >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view 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 lemming at henning-thielemann.de Fri Jun 12 19:51:30 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 12 Jun 2020 21:51:30 +0200 (CEST) Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: References: Message-ID: On Fri, 12 Jun 2020, Gregory Guthrie wrote: > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. It could have its use to convert legacy code in legacy languages to shiny new Haskell code. :-) From guthrie at miu.edu Sat Jun 13 12:29:07 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Sat, 13 Jun 2020 12:29:07 +0000 Subject: [Haskell-cafe] Norvig AI book translations... Message-ID: I've often thought that a book and approach like the MIT AI book by Norvig ("Artificial Intelligence: A Modern Approach" - http://aima.cs.berkeley.edu/) Would be a great way to showcase Haskell and its expressive clarity. It was thus interesting to find this article " Python for Lisp Programmers" (https://norvig.com/python-lisp.html) and https://github.com/aimacode, were the book has been translated into many other languages - but not Haskell (yet?). Haskell is such a great way to teach many programming concepts and applications in a very clean manner, and some of the books used to demonstrate and showcase other languages would be quite nice to have more common course books with Haskell! In a more playful flavor; "Impractical Python Projects" - again all things that map nicely into some simple Haskell examples. ( https://nostarch.com/impracticalpythonprojects ) "Python is a programming language, but it is also fun to play with. This book recognises that." LYAH & RWH are really great - but some books with more application oriented approaches can be good starters and inroads for introductions to Haskell. Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- From mgajda at mimuw.edu.pl Sat Jun 13 12:27:29 2020 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Sat, 13 Jun 2020 14:27:29 +0200 Subject: [Haskell-cafe] Haskell-Cafe Digest, Vol 202, Issue 14 In-Reply-To: References: Message-ID: After careful examination of the paper, I inferred that it mostly implemented simple loop translation, and worked only as long as the problem was small and easy to refine by direct translation token by token. It also had problems with preserving semantics of these simple loops. So while I am certain that Facebook AI tries to address important problems, the solution seems very far from practical application to large code bases and even attempts to translate the same language from one library to another. -- Best regards Michal On Sat, Jun 13, 2020 at 2:03 PM wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe at haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request at haskell.org > > You can reach the person managing the list at > haskell-cafe-owner at haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > Today's Topics: > > 1. transcoding - Haskell?! (Gregory Guthrie) > 2. Re: transcoding - Haskell?! (Branimir Maksimovic) > 3. Re: transcoding - Haskell?! (MigMit) > 4. Re: transcoding - Haskell?! (Branimir Maksimovic) > 5. Re: transcoding - Haskell?! (Henning Thielemann) > > > > ---------- Forwarded message ---------- > From: Gregory Guthrie > To: "haskell-cafe at haskell.org" > Cc: > Bcc: > Date: Fri, 12 Jun 2020 17:33:47 +0000 > Subject: [Haskell-cafe] transcoding - Haskell?! > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic > To: haskell-cafe at haskell.org > Cc: > Bcc: > Date: Fri, 12 Jun 2020 19:44:01 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > algorithm for making algorithms. Mathematicaly impossible... > > Greets, Branimir. > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > > I think it would choke on Haskell code! > > Haskell has so many language extensions and pragmas, and people use many > local extensions with monads to basically create DIY DSL’s – that the code > becomes very dense and context specific. > > > > *Facebook's TransCoder AI Converts Code From One Programming Language Into > Another* > *VentureBeat* > > * Kyle Wiggers June 9, 2020* > > Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > > > > > > > > Dr. Gregory Guthrie > > Maharishi International University > > ---------------------------------------------------------------- > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > > ---------- Forwarded message ---------- > From: MigMit > To: Branimir Maksimovic > Cc: haskell-cafe > Bcc: > Date: Fri, 12 Jun 2020 20:14:18 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressive-results/ > > > On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic at gmail.com> wrote: > > > > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > > > algorithm for making algorithms. Mathematicaly impossible... > > > > Greets, Branimir. > > > > > > > > On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >> I think it would choke on Haskell code! > >> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >> > >> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >> VentureBeat > >> Kyle Wiggers > >> June 9, 2020 > >> > >> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >> > >> > >> > >> > >> Dr. Gregory Guthrie > >> Maharishi International University > >> ---------------------------------------------------------------- > >> > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view 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. > > > > > > ---------- Forwarded message ---------- > From: Branimir Maksimovic > To: MigMit > Cc: haskell-cafe > Bcc: > Date: Fri, 12 Jun 2020 20:25:58 +0200 > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > As long as there is math behind that it could work. There is no > algorithm for creative thinking. Same way that if you put it on rng 1000 > monkeys will sooner or later create Shakespeare :P > > Greets, Branimir. > > On 6/12/20 8:14 PM, MigMit wrote: > > I wonder if this would be true: > https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressive-results/ > > > >> On 12 Jun 2020, at 19:44, Branimir Maksimovic < > branimir.maksimovic at gmail.com> wrote: > >> > >> It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > >> > >> algorithm for making algorithms. Mathematicaly impossible... > >> > >> Greets, Branimir. > >> > >> > >> > >> On 6/12/20 7:33 PM, Gregory Guthrie wrote: > >>> I think it would choke on Haskell code! > >>> Haskell has so many language extensions and pragmas, and people use > many local extensions with monads to basically create DIY DSL’s – that the > code becomes very dense and context specific. > >>> > >>> Facebook's TransCoder AI Converts Code From One Programming Language > Into Another > >>> VentureBeat > >>> Kyle Wiggers > >>> June 9, 2020 > >>> > >>> Facebook says its TransCoder can convert code from one high-level > programming language into another. The system, which Facebook researchers > describe as “a neural transcompiler,” uses an unsupervised learning > approach to translate between languages like C++, Java, and Python. The > researchers trained TransCoder on a public GitHub corpus featuring more > than 2.8 million open source repositories. To evaluate its capabilities, > the researchers extracted 852 parallel functions in C++, Java, and Python > from the online GeeksforGeeks platform and developed a new computational > accuracy metric that tests whether hypothesis functions generate the same > outputs as a reference when given the same inputs. Wrote the researchers, > “TransCoder can easily be generalized to any programming language, does not > require any expert knowledge, and outperforms commercial solutions by a > large margin.” > >>> > >>> > >>> > >>> > >>> Dr. Gregory Guthrie > >>> Maharishi International University > >>> ---------------------------------------------------------------- > >>> > >>> > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> To (un)subscribe, modify options or view 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. > > > > > ---------- Forwarded message ---------- > From: Henning Thielemann > To: Gregory Guthrie > Cc: haskell-cafe at haskell.org > Bcc: > Date: Fri, 12 Jun 2020 21:51:30 +0200 (CEST) > Subject: Re: [Haskell-cafe] transcoding - Haskell?! > > On Fri, 12 Jun 2020, Gregory Guthrie wrote: > > > I think it would choke on Haskell code! > > > > Haskell has so many language extensions and pragmas, and people use many > > local extensions with monads to basically create DIY DSL’s – that the > > code becomes very dense and context specific. > > It could have its use to convert legacy code in legacy languages to shiny > new Haskell code. :-)_______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Pozdrawiam Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerzy.karczmarczuk at unicaen.fr Sat Jun 13 12:43:26 2020 From: jerzy.karczmarczuk at unicaen.fr (Jerzy Karczmarczuk) Date: Sat, 13 Jun 2020 14:43:26 +0200 Subject: [Haskell-cafe] Norvig AI book translations... In-Reply-To: References: Message-ID: Le 13/06/2020 à 14:29, Gregory Guthrie cites a "*Geek Tech Stuff* ": > "Python is a programming language, but it is also fun to play with. This book recognises that." This is a "geek"?? "Also"?  (which implies some contrast and/or orthogonality)? But Python if fun to play with /*BECAUSE*/ it is a nice/reasonable programming language (whatever you think about). Haskell is a splendid programming language, and /*that's why*/ it is a tremendous fun to work on/with it. Everything may be fun. Unless you pretend to be a geek. "Recognizing it" is very cheap. Jerzy Karczmarczuk /Caen, France/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabricio.olivetti at gmail.com Sat Jun 13 20:14:31 2020 From: fabricio.olivetti at gmail.com (=?UTF-8?Q?Fabr=C3=ADcio_Olivetti_de_Fran=C3=A7a?=) Date: Sat, 13 Jun 2020 17:14:31 -0300 Subject: [Haskell-cafe] Norvig AI book translations... In-Reply-To: References: Message-ID: I've implemented a few algorithms from this book by request of some Haskellers students during my 2017 AI course :) https://folivetti.github.io/courses/IA/Pratica/Busca/8Queens.hs https://folivetti.github.io/courses/IA/Pratica/Busca/8Puzzle.hs https://folivetti.github.io/courses/IA/Pratica/MonteCarlo/MCTS.hs https://folivetti.github.io/courses/IA/Pratica/mdp/Agent.hs https://folivetti.github.io/courses/IA/Pratica/mdp/mdp.hs I wasn't very experienced with Haskell by then, so those can be certainly improved. I was planning to revisit those codes and create a repo to port the codes at http://aima.cs.berkeley.edu/python/readme.html in my free time. But this free time never happened :( I'll probably have some spare time in the following weeks, if you want to, we can collaborate on this. Fabricio Olivetti de França Universidade Federal do ABC On Sat, Jun 13, 2020 at 9:30 AM Gregory Guthrie wrote: > > I've often thought that a book and approach like the MIT AI book by Norvig ("Artificial Intelligence: A Modern Approach" - http://aima.cs.berkeley.edu/) Would be a great way to showcase Haskell and its expressive clarity. > > It was thus interesting to find this article " Python for Lisp Programmers" (https://norvig.com/python-lisp.html) and https://github.com/aimacode, were the book has been translated into many other languages - but not Haskell (yet?). > > Haskell is such a great way to teach many programming concepts and applications in a very clean manner, and some of the books used to demonstrate and showcase other languages would be quite nice to have more common course books with Haskell! > > In a more playful flavor; "Impractical Python Projects" - again all things that map nicely into some simple Haskell examples. ( https://nostarch.com/impracticalpythonprojects ) > "Python is a programming language, but it is also fun to play with. This book recognises that." > > LYAH & RWH are really great - but some books with more application oriented approaches can be good starters and inroads for introductions to Haskell. > > Dr. Gregory Guthrie > Maharishi International University > ---------------------------------------------------------------- > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 guthrie at miu.edu Sat Jun 13 20:29:16 2020 From: guthrie at miu.edu (Gregory Guthrie) Date: Sat, 13 Jun 2020 20:29:16 +0000 Subject: [Haskell-cafe] Norvig AI book translations... In-Reply-To: References: Message-ID: Very nice - thanks! I haven't taught this course in a long time, so will have to see how much time I have to get involved. Good start - Thanks. Dr. Gregory Guthrie Maharishi International University ---------------------------------------------------------------- -----Original Message----- From: Fabrício Olivetti de França Sent: Saturday, June 13, 2020 3:15 PM To: Gregory Guthrie Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Norvig AI book translations... I've implemented a few algorithms from this book by request of some Haskellers students during my 2017 AI course :) https://folivetti.github.io/courses/IA/Pratica/Busca/8Queens.hs https://folivetti.github.io/courses/IA/Pratica/Busca/8Puzzle.hs https://folivetti.github.io/courses/IA/Pratica/MonteCarlo/MCTS.hs https://folivetti.github.io/courses/IA/Pratica/mdp/Agent.hs https://folivetti.github.io/courses/IA/Pratica/mdp/mdp.hs I wasn't very experienced with Haskell by then, so those can be certainly improved. I was planning to revisit those codes and create a repo to port the codes at http://aima.cs.berkeley.edu/python/readme.html in my free time. But this free time never happened :( I'll probably have some spare time in the following weeks, if you want to, we can collaborate on this. Fabricio Olivetti de França Universidade Federal do ABC On Sat, Jun 13, 2020 at 9:30 AM Gregory Guthrie wrote: > > I've often thought that a book and approach like the MIT AI book by Norvig ("Artificial Intelligence: A Modern Approach" - http://aima.cs.berkeley.edu/) Would be a great way to showcase Haskell and its expressive clarity. > > It was thus interesting to find this article " Python for Lisp Programmers" (https://norvig.com/python-lisp.html) and https://github.com/aimacode, were the book has been translated into many other languages - but not Haskell (yet?). > > Haskell is such a great way to teach many programming concepts and applications in a very clean manner, and some of the books used to demonstrate and showcase other languages would be quite nice to have more common course books with Haskell! > > In a more playful flavor; "Impractical Python Projects" - again all > things that map nicely into some simple Haskell examples. ( https://nostarch.com/impracticalpythonprojects ) "Python is a programming language, but it is also fun to play with. This book recognises that." > > LYAH & RWH are really great - but some books with more application oriented approaches can be good starters and inroads for introductions to Haskell. > > Dr. Gregory Guthrie > Maharishi International University > ---------------------------------------------------------------- > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 jo at durchholz.org Sun Jun 14 09:50:14 2020 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 14 Jun 2020 11:50:14 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: References: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> <9645E2CA-F7E8-4BFF-9D09-36CBCC09D0AD@gmail.com> Message-ID: <14bd8aeb-fe73-168c-498d-f7172e5ba9e3@durchholz.org> Am 12.06.20 um 20:25 schrieb Branimir Maksimovic: > As long as there is math behind that it could work. There is no > algorithm for creative thinking. Same way that if you put it on rng 1000 > monkeys will sooner or later create Shakespeare :P Except if you have a library that has all the monkey works, the shelf number where you can find that work will be at least as long as the work itself. You can't beat entropy... > > Greets, Branimir. > > On 6/12/20 8:14 PM, MigMit wrote: >> I wonder if this would be true: >> https://www.theolognion.com/circular-ts-js-ts-js-transpiling-yields-impressive-results/ >> >> >>> On 12 Jun 2020, at 19:44, Branimir Maksimovic >>> wrote: >>> >>> It would choke on assembler as well. Digital computer hard AI is >>> impossible, because there is no >>> >>> algorithm for making algorithms. Mathematicaly impossible... >>> >>> Greets, Branimir. >>> >>> >>> >>> On 6/12/20 7:33 PM, Gregory Guthrie wrote: >>>> I think it would choke on Haskell code! >>>> Haskell has so many language extensions and pragmas, and people use >>>> many local extensions with monads to basically create DIY DSL’s – >>>> that the code becomes very dense and context specific. >>>> Facebook's TransCoder AI Converts Code From One Programming Language >>>> Into Another >>>> VentureBeat >>>> Kyle Wiggers >>>> June 9, 2020 >>>> >>>> Facebook says its TransCoder can convert code from one high-level >>>> programming language into another. The system, which Facebook >>>> researchers describe as “a neural transcompiler,” uses an >>>> unsupervised learning approach to translate between languages like >>>> C++, Java, and Python. The researchers trained TransCoder on a >>>> public GitHub corpus featuring more than 2.8 million open source >>>> repositories. To evaluate its capabilities, the researchers >>>> extracted 852 parallel functions in C++, Java, and Python from the >>>> online GeeksforGeeks platform and developed a new computational >>>> accuracy metric that tests whether hypothesis functions generate the >>>> same outputs as a reference when given the same inputs. Wrote the >>>> researchers, “TransCoder can easily be generalized to any >>>> programming language, does not require any expert knowledge, and >>>> outperforms commercial solutions by a large margin.” >>>> >>>> Dr. Gregory Guthrie >>>> Maharishi International University >>>> ---------------------------------------------------------------- >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view 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. From jo at durchholz.org Sun Jun 14 09:51:20 2020 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 14 Jun 2020 11:51:20 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: References: Message-ID: <62c33e31-3a0e-6a0a-9261-3bd00e269d15@durchholz.org> Am 12.06.20 um 21:51 schrieb Henning Thielemann: > > On Fri, 12 Jun 2020, Gregory Guthrie wrote: > >> I think it would choke on Haskell code! >> >> Haskell has so many language extensions and pragmas, and people use >> many local extensions with monads to basically create DIY DSL’s – that >> the code becomes very dense and context specific. > > It could have its use to convert legacy code in legacy languages to > shiny new Haskell code. :-) Well, the AI would have to know what "shiny" code is. Otherwise, you'll just get a C++/VB/Cobol program written in Haskell. From jo at durchholz.org Sun Jun 14 10:09:24 2020 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 14 Jun 2020 12:09:24 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> References: <9c74433e-7731-8db3-27f6-72e94a9fb2af@gmail.com> Message-ID: <1bc129fc-5870-31c3-19b1-48371539a2eb@durchholz.org> Am 12.06.20 um 19:44 schrieb Branimir Maksimovic: > It would choke on assembler as well. Digital computer hard AI is > impossible, because there is no > > algorithm for making algorithms. Mathematicaly impossible... You know you *can* work with undecidable algorithms. You put a resource constraint on them and let them declare "don't know", which then can be handled appropriately. There's even software that works like that in practice, nowadays - register allocators in compilers, query plan optimizers in databases, travel route optimization software, sheet cutting software for irregular shapes, various types systems, proof exploration software, etc. These work by trying out various options and returning "don't know whether this is the optimum, but it's the best I could find with the available resource limits", and with good heuristics, it's still good enough. So the undecidability is not important here. You need a good heuristics. And AI can be good about heuristics. So this aspect is not the one that's messed up about the idea. Regards, Jo From lemming at henning-thielemann.de Sun Jun 14 10:25:51 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Jun 2020 12:25:51 +0200 (CEST) Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: <62c33e31-3a0e-6a0a-9261-3bd00e269d15@durchholz.org> References: <62c33e31-3a0e-6a0a-9261-3bd00e269d15@durchholz.org> Message-ID: On Sun, 14 Jun 2020, Joachim Durchholz wrote: > Am 12.06.20 um 21:51 schrieb Henning Thielemann: > >> It could have its use to convert legacy code in legacy languages to >> shiny new Haskell code. :-) > > Well, the AI would have to know what "shiny" code is. I thought that this is the point of the AI approach and the training. > Otherwise, you'll just get a C++/VB/Cobol program written in Haskell. This would still be helpful. Imagine we transcode LAPACK to Haskell. It would be still FORTRAN or C encoded in Haskell with the same old FORTRAN API, but we can easily generalize the code to any floating point number type that any Haskell library provides, e.g. numbers with extended precision, with decimal numbers or with interval arithmetics. From jo at durchholz.org Sun Jun 14 11:53:15 2020 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 14 Jun 2020 13:53:15 +0200 Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: References: <62c33e31-3a0e-6a0a-9261-3bd00e269d15@durchholz.org> Message-ID: <5983e0dc-d526-2e09-62fe-821bcea076c9@durchholz.org> Am 14.06.20 um 12:25 schrieb Henning Thielemann: > > On Sun, 14 Jun 2020, Joachim Durchholz wrote: > >> Am 12.06.20 um 21:51 schrieb Henning Thielemann: >> >>> It could have its use to convert legacy code in legacy languages to >>> shiny new Haskell code. :-) >> >> Well, the AI would have to know what "shiny" code is. > > I thought that this is the point of the AI approach and the training. In that case, the trainer needs to know it. Plus the trainer needs to know how to make the AI recognize it. >> Otherwise, you'll just get a C++/VB/Cobol program written in Haskell. > > This would still be helpful. Imagine we transcode LAPACK to Haskell. It > would be still FORTRAN or C encoded in Haskell with the same old FORTRAN > API, but we can easily generalize the code to any floating point number > type that any Haskell library provides, e.g. numbers with extended > precision, with decimal numbers or with interval arithmetics. No, you wouldn't be able to generalize. Well, sort of. Some things will work. But there are corner cases where e.g. float and double behave differently. E.g. your lists of interpolation points may round differently, so you need adjustments to the algorithms that uses these tables. I haven't looked into Lapack itself but I know that floating-point is infamous for the amount of fiddly detail that you have to consider, sometimes separately for each bit width. Fun fact: Numeric algorithms can break, i.e. produce incorrect results, if you do intermediate calculations with additional mantissa bits. This hurt the 8087 badly because they added an internal stack, which had 80-bit mantissas, because, more precision so why not? So... I tend to be scared if somebody claims to generalize floating-point code. Either because that person knows too little, or because that person knows so much more than me that they actually know how to deal with these complications :-) Regards, Jo From lemming at henning-thielemann.de Sun Jun 14 12:37:22 2020 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Jun 2020 14:37:22 +0200 (CEST) Subject: [Haskell-cafe] transcoding - Haskell?! In-Reply-To: <5983e0dc-d526-2e09-62fe-821bcea076c9@durchholz.org> References: <62c33e31-3a0e-6a0a-9261-3bd00e269d15@durchholz.org> <5983e0dc-d526-2e09-62fe-821bcea076c9@durchholz.org> Message-ID: On Sun, 14 Jun 2020, Joachim Durchholz wrote: > Am 14.06.20 um 12:25 schrieb Henning Thielemann: >> >> This would still be helpful. Imagine we transcode LAPACK to Haskell. It >> would be still FORTRAN or C encoded in Haskell with the same old FORTRAN >> API, but we can easily generalize the code to any floating point number >> type that any Haskell library provides, e.g. numbers with extended >> precision, with decimal numbers or with interval arithmetics. > > So... I tend to be scared if somebody claims to generalize > floating-point code. Either because that person knows too little, or > because that person knows so much more than me that they actually know > how to deal with these complications :-) I expect that code that works for both Float and Double has already factored out precision-dependent constants. I have not claimed and do not expect that generalization can happen automatically. I just say that even a dumb conversion from FORTRAN to Haskell can be the first step to (manual) generalization in Haskell. From joshchia at gmail.com Tue Jun 16 14:44:18 2020 From: joshchia at gmail.com (=?UTF-8?B?4piCSm9zaCBDaGlhICjorJ3ku7vkuK0p?=) Date: Tue, 16 Jun 2020 22:44:18 +0800 Subject: [Haskell-cafe] FFI ccall struct return by value on the stack? Message-ID: Suppose I have the following C code: typedef struct Foo { char* p1; /* Some data on the heap. */ size_t s1; /* Size of data. */ char* p2; /* More data on the heap. */ size_t s2; } Foo; /* Allocates and writes two pieces of data on the heap and returns them in a Foo. */ Foo makeFoo(size_t x); Based on my limited understanding of Haskell FFI according to the Haskell 2010 Language Report ( https://www.haskell.org/onlinereport/haskell2010/haskellch8.html), it is not possible to have a ccall for makeFoo() because Foo is not a marshallable foreign result type. Is my understanding correct? However, I believe I can have a ccall if I change makeFoo() to either of the following: Foo* makeFoo(size_t x); void makeFoo(Foo* out, size_t x); The first involves the C code allocating a Foo and returning a pointer to it (so now there's one more pointer for the C code to deallocate later in another function). The second involves the C code writing a Foo value to a piece of memory allocated in Haskell (possibly using Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is marshallable but are clumsier to use than the original signature. Is there just no way to return a struct by value on the stack? Is there a cleaner way than the above two? Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From merijn at inconsistent.nl Tue Jun 16 14:55:05 2020 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Tue, 16 Jun 2020 16:55:05 +0200 Subject: [Haskell-cafe] FFI ccall struct return by value on the stack? In-Reply-To: References: Message-ID: <42450C32-26A9-46D1-939A-65E882BBF0EA@inconsistent.nl> I don't really have an opinion on the two alternatives, they both seem fine to me. I just wanted to chime in on the following: > On 16 Jun 2020, at 16:44, ☂Josh Chia (謝任中) wrote: > Is there just no way to return a struct by value on the stack? There is indeed no way to do so, and this is a fundamental limitation not of Haskell, but of the ABI on your platform. To call unknown code, you need to know, well, how to call it. On most platforms the only portable/reliable specification for this is the C ABI (which is why every FFIs to/via C), however this ABI just doesn't defined how passing structs as arguments or returning them as results should work (at least not on any platform I'm aware of). This means that *no* language can portably pass structs to/from code via the C ABI (including C code compiled by, say, different compilers!). Kind regards, Merijn From sylvain at haskus.fr Tue Jun 16 14:57:40 2020 From: sylvain at haskus.fr (Sylvain Henry) Date: Tue, 16 Jun 2020 16:57:40 +0200 Subject: [Haskell-cafe] FFI ccall struct return by value on the stack? In-Reply-To: References: Message-ID: On 16/06/2020 16:44, ☂Josh Chia (謝任中) wrote: > Based on my limited understanding of Haskell FFI according to the > Haskell 2010 Language Report > (https://www.haskell.org/onlinereport/haskell2010/haskellch8.html), it > is not possible to have a ccall for makeFoo() because Foo is not a > marshallable foreign result type. Is my understanding correct? > Yes. Structures are sometimes passed into registers (at least on x86-64) depending on their field types. GHC doesn't support this. > However, I believe I can have a ccall if I change makeFoo() to either > of the following: > Foo* makeFoo(size_t x); > void makeFoo(Foo* out, size_t x); > > The first involves the C code allocating a Foo and returning a pointer > to it (so now there's one more pointer for the C code to deallocate > later in another function). The second involves the C code writing a > Foo value to a piece of memory allocated in Haskell (possibly using > Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is > marshallable but are clumsier to use than the original signature. Is > there just no way to return a struct by value on the stack? Is there a > cleaner way than the above two? > The second approach seems cleaner to me. With a Storable instance for Foo, it's not that much clumsy. Sylvain From chpatrick at gmail.com Tue Jun 16 15:13:15 2020 From: chpatrick at gmail.com (Patrick Chilton) Date: Tue, 16 Jun 2020 17:13:15 +0200 Subject: [Haskell-cafe] FFI ccall struct return by value on the stack? In-Reply-To: References: Message-ID: I would return a malloced pointer. After that, it depends on what you want to do with the Foo. If you just want to pass it to other C stuff and don't want to read its contents from Haskell, I would wrap it in an opaque ForeignPtr to be freed or make sure it gets freed with a `bracket`. Then there's no awkwardness with generating/updating a Storable instance. If you need the contents from Haskell, peek it and free it immediately. Haskell's alloca also allocates internally so it's not like it would be on the stack in any case. The important thing is that any bit of code that deals with raw pointers with no cleanup registered must have async exceptions masked, otherwise if one is thrown the memory will be leaked. On Tue, Jun 16, 2020, 16:45 ☂Josh Chia (謝任中) wrote: > Suppose I have the following C code: > > typedef struct Foo { > char* p1; /* Some data on the heap. */ > size_t s1; /* Size of data. */ > char* p2; /* More data on the heap. */ > size_t s2; > } Foo; > > /* Allocates and writes two pieces of data on the heap and returns them in > a Foo. */ > Foo makeFoo(size_t x); > > Based on my limited understanding of Haskell FFI according to the Haskell > 2010 Language Report ( > https://www.haskell.org/onlinereport/haskell2010/haskellch8.html), it is > not possible to have a ccall for makeFoo() because Foo is not a > marshallable foreign result type. Is my understanding correct? > > However, I believe I can have a ccall if I change makeFoo() to either of > the following: > Foo* makeFoo(size_t x); > void makeFoo(Foo* out, size_t x); > > The first involves the C code allocating a Foo and returning a pointer to > it (so now there's one more pointer for the C code to deallocate later in > another function). The second involves the C code writing a Foo value to a > piece of memory allocated in Haskell (possibly using > Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is > marshallable but are clumsier to use than the original signature. Is there > just no way to return a struct by value on the stack? Is there a cleaner > way than the above two? > > Josh > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Tue Jun 16 15:24:04 2020 From: kane at kane.cx (David Kraeutmann) Date: Tue, 16 Jun 2020 17:24:04 +0200 Subject: [Haskell-cafe] FFI ccall struct return by value on the stack? In-Reply-To: References: Message-ID: I've done this for some code, in both directions. (https://github.com/SimulaVR/godot-haskell/blob/simula/src/Godot/Gdnative/Internal/Gdnative.chs#L378 ) `Foo makeFoo(size_t x)` is internally equivalent (ABI-dependent, but at least on x64 Linux and WIndows) to `Foo* makeFoo(Foo* result, size_t x)`. Alloc the data in Haskell and use that definition. On 2020-06-16 16:44, ☂Josh Chia (謝任中) wrote: > Suppose I have the following C code: > > typedef struct Foo { >     char* p1;  /* Some data on the heap. */ >     size_t s1; /* Size of data. */ >     char* p2;  /* More data on the heap. */ >     size_t s2; > } Foo; > > /* Allocates and writes two pieces of data on the heap and returns > them in a Foo. */ > Foo makeFoo(size_t x); > > Based on my limited understanding of Haskell FFI according to the > Haskell 2010 Language Report > (https://www.haskell.org/onlinereport/haskell2010/haskellch8.html > ), > it is not possible to have a ccall for makeFoo() because Foo is not a > marshallable foreign result type. Is my understanding correct? > > However, I believe I can have a ccall if I change makeFoo() to either > of the following: > Foo* makeFoo(size_t x); > void makeFoo(Foo* out, size_t x); > > The first involves the C code allocating a Foo and returning a pointer > to it (so now there's one more pointer for the C code to deallocate > later in another function). The second involves the C code writing a > Foo value to a piece of memory allocated in Haskell (possibly using > Foreign.Marshall.Alloc.alloca). Both signatures work because Foo* is > marshallable but are clumsier to use than the original signature. Is > there just no way to return a struct by value on the stack? Is there a > cleaner way than the above two? > > Josh > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ida.bzowska at gmail.com Tue Jun 16 15:29:46 2020 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Tue, 16 Jun 2020 17:29:46 +0200 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) Message-ID: Hi There! We are organizing the online event on Haskell language https://haskell.love, free to attend. The CFP for the event has started (ends on the 1st of July, 2020), please consider joining https://konfy.care/cfp Tickets (free) will be available soon, follow us on twitter https://twitter.com/_haskellove for the updates and feel free to hop on our slack http://tinyurl.com/haskelloveslack λCheers Ida Bzowska -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Tue Jun 16 17:15:39 2020 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Tue, 16 Jun 2020 13:15:39 -0400 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) In-Reply-To: References: Message-ID: I don't know if I'll be able to attend or not, but the artwork of all the speakers' faces is wonderful! On Tue, Jun 16, 2020 at 11:31 AM Ida Bzowska wrote: > Hi There! > > We are organizing the online event on Haskell language > https://haskell.love, free to attend. The CFP for the event has started > (ends on the 1st of July, 2020), please consider joining > https://konfy.care/cfp > Tickets (free) will be available soon, follow us on twitter > https://twitter.com/_haskellove for the updates and feel free to hop on > our slack http://tinyurl.com/haskelloveslack > > λCheers > Ida Bzowska > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- -Andrew Thaddeus Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Wed Jun 17 00:19:02 2020 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Tue, 16 Jun 2020 20:19:02 -0400 Subject: [Haskell-cafe] Call for Tutorial Proposals: ICFP 2020 Message-ID: <5ee96176cacf2_223a22abfa25865c49531@homer.mail> CALL FOR TUTORIAL, PANEL, AND DISCUSSION PROPOSALS ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for tutorials, lasting approximately 3 hours each, to be presented during ICFP and its co-located workshops and other events. These tutorials are the successor to the CUFP tutorials from previous years, but we also welcome tutorials whose primary audience is researchers rather than practitioners. Tutorials may focus either on a concrete technology or on a theoretical or mathematical tool. Ideally, tutorials will have a concrete result, such as "Learn to do X with Y" rather than "Learn language Y". This year, following the success of the #ShutDownPL event, we are also inviting proposals for panels and discussions on topics of broader interest to the PL community. Tutorials, panels, and discussions may occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. ---------------------------------------------------------------------- Submission details Deadline for submission: July 17th, 2020 Notification of acceptance: July 22nd, 2020 Prospective organizers of tutorials are invited to submit a completed tutorial proposal form in plain text format to the ICFP 2020 workshop co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020 at googlegroups.com by July 17th, 2020. Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by July 22nd, 2020. The proposal form is available at: http://www.icfpconference.org/icfp2020-files/icfp20-panel-form.txt http://www.icfpconference.org/icfp2020-files/icfp20-tutorials-form.txt ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2020 organizing committee. Tutorials Co-Chair: Jennifer Hackett (University of Nottingham) Tutorials Co-Chair: Leonidas Lampropoulos (University of Maryland) General Chair: Stephanie Weirich (University of Pennsylvania) Program Chair: Adam Chlipala (MIT) ---------------------------------------------------------------------- Further information Any queries should be addressed to the tutorial co-chairs (Jennifer Hackett and Leonidas Lampropoulos), via email to icfp-workshops-2020 at googlegroups.com From miriam at keera.co.uk Thu Jun 18 17:45:19 2020 From: miriam at keera.co.uk (Miriam) Date: Thu, 18 Jun 2020 19:45:19 +0200 Subject: [Haskell-cafe] [ANN] Enpuzzled - iOS/Android Haskell game Message-ID: <577cb894af8561c81692c23ae6ccacfe@keera.co.uk> Hi everyone! After years of work, thousands of commits, and over 100 uploads to iTunes and Android, we are very happy to finally announce Enpuzzled, a Haskell game for iOS and Android. Enpuzzled is a brain teaser that anyone can enjoy quietly, so there is no timer and no rush: it's just you against the board. The game is suitable for all audiences and requires no permissions to run, as part of our recent movement 'Safe2Play'. iTunes: https://apps.apple.com/us/app/enpuzzled/id1460083994 Google Play: https://play.google.com/store/apps/details?id=uk.co.keera.games.enpuzzled Web page: https://enpuzzled.haskell.games Official announcement: https://keera.co.uk/2020/06/18/enpuzzled-released-for-android-and-ios/ Issue tracker: https://github.com/keera-studios/enpuzzled Support/questions: support at keera.co.uk Safe2Play: https://keera.co.uk/2020/06/17/safe2play-caring-for-privacy-in-an-interconnected-world/ This is our second self-published mobile Haskell game, and one more small step in a long way towards making Haskell a real possibility for game programming. You can find some technical details in the official announcement. We would like to publicly thank all beta testers, who patiently tried version after version, and all the people who supported the development in different ways. If you'd like to support the development of more Haskell games, please consider buying Enpuzzled and/or spreading the word. We currently have three more games at different stages of development. You can follow the development on our website and on social networks, where we will also post calls for early testers. Have fun, and happy Haskelling! Miriam, Keera Studios From ida.bzowska at gmail.com Fri Jun 19 10:40:25 2020 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Fri, 19 Jun 2020 12:40:25 +0200 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) In-Reply-To: References: Message-ID: Every speaker gets an avatar. If this thing will encourage you to take part in CFP, I assure you: you will get one! λCheers Ida Bzowska wt., 16 cze 2020 o 19:15 Andrew Martin napisał(a): > I don't know if I'll be able to attend or not, but the artwork of all the > speakers' faces is wonderful! > > On Tue, Jun 16, 2020 at 11:31 AM Ida Bzowska > wrote: > >> Hi There! >> >> We are organizing the online event on Haskell language >> https://haskell.love, free to attend. The CFP for the event has started >> (ends on the 1st of July, 2020), please consider joining >> https://konfy.care/cfp >> Tickets (free) will be available soon, follow us on twitter >> https://twitter.com/_haskellove for the updates and feel free to hop on >> our slack http://tinyurl.com/haskelloveslack >> >> λCheers >> Ida Bzowska >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > -- > -Andrew Thaddeus Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Jun 24 20:34:18 2020 From: ben at well-typed.com (Ben Gamari) Date: Wed, 24 Jun 2020 16:34:18 -0400 Subject: [Haskell-cafe] [HIW'20] Third Call for Talks In-Reply-To: <87zha4yjf9.fsf@smart-cactus.org> References: <87zha4yjf9.fsf@smart-cactus.org> Message-ID: <87y2oc5hko.fsf@smart-cactus.org> Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is next week, July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Thu Jun 25 16:25:53 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 25 Jun 2020 18:25:53 +0200 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) In-Reply-To: References: Message-ID: <9ed57968297f0008379366660bf4ba273222492b.camel@joachim-breitner.de> Hi, Am Freitag, den 19.06.2020, 12:40 +0200 schrieb Ida Bzowska: > Every speaker gets an avatar. If this thing will encourage you to take part in CFP, I assure you: you will get one! I can't deny it does… But the CFP could have a bit more information, e.g. suggested lengths of talks, and how you will handle the technicalities – do speakers just screen-share with zoom? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From ida.bzowska at gmail.com Fri Jun 26 11:39:46 2020 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Fri, 26 Jun 2020 13:39:46 +0200 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) In-Reply-To: <9ed57968297f0008379366660bf4ba273222492b.camel@joachim-breitner.de> References: <9ed57968297f0008379366660bf4ba273222492b.camel@joachim-breitner.de> Message-ID: Hi, Indeed, that's a very accurate comment :) so we are waiting for 30 minutes long talks, but if you have a longer presentation in mind, we will try to be agile and make a schedule that will handle it. The presentation flow will be based on screen sharing for sure, but this time probably it would not be zoom (we used it previously https://www.youtube.com/watch?v=Z0w_pITUTyU). <3 We are still waiting for submissions (till the 1st of July). <3 λCheers, Ida Bzowska czw., 25 cze 2020 o 18:25 Joachim Breitner napisał(a): > Hi, > > > Am Freitag, den 19.06.2020, 12:40 +0200 schrieb Ida Bzowska: > > Every speaker gets an avatar. If this thing will encourage you to take > part in CFP, I assure you: you will get one! > > I can't deny it does… > > But the CFP could have a bit more information, e.g. suggested lengths > of talks, and how you will handle the technicalities – do speakers just > screen-share with zoom? > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Fri Jun 26 14:23:48 2020 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Fri, 26 Jun 2020 10:23:48 -0400 Subject: [Haskell-cafe] Second Call for Papers: Reactive and Event-Based Languages and Systems (REBLS 2020) Message-ID: SECOND CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference Chicago, Illinois, USA Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 24 Jul 2020 Author Notification: 24 Aug 2020 Camera Ready Deadline: 25 Sep 2020 INTRODUCTION Reactive programming and event-based programming are two closely related programming styles that are becoming more important with the ever increasing requirement for applications to run on the web or on mobile devices, and the advent of advanced High-Performance Computing (HPC) technology. A number of publications on middleware and language design -- so-called reactive and event-based languages and systems (REBLS) -- have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is still lacking, and modularity mechanisms remain largely unexplored. Moreover, large applications are still to be developed, and, consequently, patterns and tools for developing large reactive applications are still in their infancy. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to better define the field by developing taxonomies and discussing overviews of the existing work. We welcome all submissions on reactive programming, functional reactive programming, and event- and aspect- oriented systems, including but not limited to: * Language design, implementation, runtime systems, program analysis, software metrics, patterns and benchmarks. * Formal models for reactive and event-based programming. * Study of the paradigm: interaction of reactive and event-based programming with existing language features such as object-oriented programming, pure functional programming, mutable state, concurrency. * Modularity and abstraction mechanisms in large systems. * Advanced event systems, event quantification, event composition, aspect-oriented programming for reactive applications. * Functional Reactive Programming (FRP), self-adjusting computation and incremental computing. * Synchronous languages, modeling real-time systems, safety-critical reactive and embedded systems. * Applications, case studies that show the efficacy of reactive programming. * Empirical studies that motivate further research in the field. * Patterns and best-practices. * Related fields, such as complex event processing, reactive data structures, view maintenance, constraint-based languages, and their integration with reactive programming. * Implementation technology, language runtimes, virtual machine support, compilers. * IDEs, Tools. The format of the workshop is that of a mini-conference. Participants can present their work in slots of 30 mins with Q&A included. Because of the declarative nature of reactive programs, it is often hard to understand their semantics just by looking at the code. We therefore also encourage authors to use their slots for presenting their work based on live demos. SUBMISSIONS REBLS encourages submissions of two types of papers: * Full papers: papers that describe complete research results. These papers will be published in the ACM digital library. * In-progress papers: papers that have the potential of triggering an interesting discussion at the workshop or present new ideas that require further systematic investigation. These papers will not be published in the ACM digital library. Format: * Submissions should use the ACM SIGPLAN Conference acmart Format with the two-column, sigplan Subformat, 10 point font, using Biolinum as sans-serif font and Libertine as serif font. All submissions should be in PDF format. If you use LaTeX or Word, please use the ACM SIGPLAN acmart Templates. The page http://www.sigplan.org/Resources/Author/#acmart-format contains instructions for authors, and a package that includes an example file acmart-sigplan.tex. * Authors are required to explicitly specify the type of paper in the submission (i.e., full paper, in-progress paper). * Full papers can be *up to* 12 pages in length, excluding references. In-progress papers can be *up to* 6 pages, excluding references. Papers do not need to make use of all pages, but they will be summarily rejected if they exceed the page limits. Instructions for the Authors: * Papers should be submitted through: https://rebls20.hotcrp.com/ * For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions will be summarily rejected. * Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. * Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (http://www.sigplan.org/Resources/Policies/Republication). Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. * All submissions are expected to comply with the ACM Policies for Authorship detailed at https://www.acm.org/publications/authors/information-for-authors. PROGRAM COMMITTEE Ivan Perez (PC Chair; NIA) Alan Jeffrey, Mozilla Research. Christiaan Baaij, QBayLogic. César Sánchez, IMDEA Software. Daniel Winograd-Cort, Target Corp. Edward Amsden, Black River Software, LLC. Guerric Chupin, University of Nottingham. Heinrich Apfelmus. Jonathan Thaler, University of Applied Sciences Vorarlberg. Louis Mandel, IBM Research. Manuel Bärenz, sonnen eServices GmbH. Marc Pouzet, Université Pierre et Marie Curie. Mark Santolucito, University of Yale. Neil Sculthorpe, University of Nottingham Trent. Noemi Rodrigues, Pontifícia Universidade Católica do Rio de Janeiro Oleksandra Bulgakova, Sukhomlynsky Mykolaiv National University Patrick Bahr, University of Copenhagen Takuo Watanabe, Tokyo Institute of Technology Tetsuo Kamina, Oita University Tom Van Cutsem, Nokia Bell Labs Yoshiki Ohshima, HARC / Y Combinator Research ORGANIZING COMMITTEE Guido Salvaneschi, TU Darmstadt, Germany Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium Patrick Eugster, Universita della Svizzera Italiana, Switzerland Francisco Sant'Anna, Rio de Janeiro State University, Brazil Lukasz Ziarek, SUNY Buffalo, United States For any questions, please use the form on the website or contact the Chair at ivan.perezdominguez at nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell-cafe at chrisdone.com Sat Jun 27 14:23:54 2020 From: haskell-cafe at chrisdone.com (chris done) Date: Sat, 27 Jun 2020 15:23:54 +0100 Subject: [Haskell-cafe] Is there a handy refl or refl generator for converting GADT types? Message-ID: <0cfde7a8-d6de-4fb9-b62d-a673d0d072d7@www.fastmail.com> Hi all, I have stages in my compiler that convert e.g. Global Renamed -> Global Generated, etc. where certain constructors are available in certain stages. data GlobalRef s where FromIntegerGlobal :: GlobalRef s FromDecimalGlobal :: GlobalRef s InstanceGlobal :: !InstanceName -> GlobalRef Resolved E.g. after type class resolution is done, the InstanceGlobal constructor is available. But instances can't appear in the AST at other stages. In three stages, I've had to copy/paste this code: + refl = + case name of + FromIntegerGlobal -> FromIntegerGlobal + FromDecimalGlobal -> FromDecimalGlobal Because if I just put `name` then GHC will complain that the types are different, which is correct. But a straight-forward pattern match gives GHC the proof that they can be converted. Is there a handy way already implemented that could derive either this code or this proof for me? Cheers, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From effectfully at gmail.com Sat Jun 27 15:09:29 2020 From: effectfully at gmail.com (Roman) Date: Sat, 27 Jun 2020 18:09:29 +0300 Subject: [Haskell-cafe] Is there a handy refl or refl generator for converting GADT types? In-Reply-To: <0cfde7a8-d6de-4fb9-b62d-a673d0d072d7@www.fastmail.com> References: <0cfde7a8-d6de-4fb9-b62d-a673d0d072d7@www.fastmail.com> Message-ID: You can define a view viewGlobalRef :: GlobalRef s -> Either InstanceName (GlobalRef s') viewGlobalRef FromIntegerGlobal = Right FromIntegerGlobal viewGlobalRef FromDecimalGlobal = Right FromDecimalGlobal viewGlobalRef (InstanceGlobal name) = Left name but that loses the `s ~ Resolved` information in the `InstanceGlobal` case, so I'd define and use matchGlobalRef :: GlobalRef s -> (s ~ Resolved => InstanceName -> r) -> (forall s'. GlobalRef s' -> r) -> r matchGlobalRef globalRef handleInstanceGlobal handleOther = case globalRef of FromIntegerGlobal -> handleOther FromIntegerGlobal FromDecimalGlobal -> handleOther FromDecimalGlobal InstanceGlobal name -> handleInstanceGlobal name From rae at richarde.dev Sun Jun 28 10:51:05 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Sun, 28 Jun 2020 11:51:05 +0100 Subject: [Haskell-cafe] Is there a handy refl or refl generator for converting GADT types? In-Reply-To: <0cfde7a8-d6de-4fb9-b62d-a673d0d072d7@www.fastmail.com> References: <0cfde7a8-d6de-4fb9-b62d-a673d0d072d7@www.fastmail.com> Message-ID: <5CA586FE-C33A-4770-A7C6-CCBC05AD02F5@richarde.dev> I think the general answer to your question is: no, you can't avoid this pattern match. In your particular case, the domain (Global Renamed) is a subset of the range (Global Generated), and so we can imagine a function that just changes the type without any fuss. This would, I'm pretty sure, be safe. But GHC has no notion of this kind of one-way transformation, so you're stuck just doing it via a manual pattern-match. I hope this helps! Richard > On Jun 27, 2020, at 3:23 PM, chris done wrote: > > Hi all, > > I have stages in my compiler that convert e.g. Global Renamed -> Global Generated, etc. where certain constructors are available in certain stages. > > data GlobalRef s where > FromIntegerGlobal :: GlobalRef s > FromDecimalGlobal :: GlobalRef s > InstanceGlobal :: !InstanceName -> GlobalRef Resolved > > E.g. after type class resolution is done, the InstanceGlobal constructor is available. But instances can't appear in the AST at other stages. > > In three stages, I've had to copy/paste this code: > > + refl = > + case name of > + FromIntegerGlobal -> FromIntegerGlobal > + FromDecimalGlobal -> FromDecimalGlobal > > Because if I just put `name` then GHC will complain that the types are different, which is correct. But a straight-forward pattern match gives GHC the proof that they can be converted. > > Is there a handy way already implemented that could derive either this code or this proof for me? > > Cheers, > > Chris > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Sun Jun 28 14:39:20 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 28 Jun 2020 16:39:20 +0200 Subject: [Haskell-cafe] PEP622 Message-ID: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> An excerpt from PEP622 [1]: > Let us start from some anecdotal evidence: isinstance() is one of the > most called functions in large scale Python code-bases (by static > call count). In particular, when analyzing some multi-million line > production code base, it was discovered that isinstance() is the > second most called builtin function (after len()). Even taking into > account builtin classes, it is still in the top ten. Most of such > calls are followed by specific attribute access. > > There are two possible conclusions that can be drawn from this > information: > > * Handling of heterogeneous data (i.e. situations where a variable > can take values of multiple types) is common in real world code. > * Python doesn't have expressive ways of destructuring object data > (i.e. separating the content of an object into multiple variables). > I just want to say a big thank you to the Haskell creators for giving us a tool to efficiently write real world code (as it is called above). [1] https://www.python.org/dev/peps/pep-0622/#rationale-and-goals From aquagnu at gmail.com Sun Jun 28 16:13:24 2020 From: aquagnu at gmail.com (Ba Ge) Date: Sun, 28 Jun 2020 19:13:24 +0300 Subject: [Haskell-cafe] PEP622 In-Reply-To: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> References: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> Message-ID: <41153869-E5C7-4B63-B0C8-FE3E51B30D3E@hxcore.ol> An HTML attachment was scrubbed... URL: From donn at avvanta.com Sun Jun 28 16:22:57 2020 From: donn at avvanta.com (Donn Cave) Date: Sun, 28 Jun 2020 09:22:57 -0700 (PDT) Subject: [Haskell-cafe] PEP622 In-Reply-To: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> References: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> Message-ID: <20200628162257.DE11D276C46@mail.avvanta.com> quoth Olaf Klinke > I just want to say a big thank you to the Haskell creators for giving > us a tool to efficiently write real world code (as it is called above). > > [1] https://www.python.org/dev/peps/pep-0622/#rationale-and-goals And if I understand that you mean the variants and pattern matching, another big thank you to the creators of ML in the '70s. Was that the origin of anything recognizable as variant types? Donn From donn at avvanta.com Sun Jun 28 16:49:43 2020 From: donn at avvanta.com (Donn Cave) Date: Sun, 28 Jun 2020 09:49:43 -0700 (PDT) Subject: [Haskell-cafe] PEP622 In-Reply-To: <41153869-E5C7-4B63-B0C8-FE3E51B30D3E@hxcore.ol> References: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de><41153869-E5C7-4B63-B0C8-FE3E51B30D3E@hxcore.ol> Message-ID: <20200628164943.2D3E5276D62@mail.avvanta.com> quoth Ba Ge > A leak of knowledge about INTERNAL structure, internal representation of the object, which is bad. It's bad in the wrong place, but I think that's why we occasionally mention a "real world" - a really usable programming language might let you decide how and when to apply principles like that. Donn From jaro.reinders at gmail.com Sun Jun 28 17:30:23 2020 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Sun, 28 Jun 2020 19:30:23 +0200 Subject: [Haskell-cafe] PEP622 In-Reply-To: <20200628162257.DE11D276C46@mail.avvanta.com> References: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> <20200628162257.DE11D276C46@mail.avvanta.com> Message-ID: <2f4f4e0d-08ba-f822-4f9d-158a562c8c6e@gmail.com> Wikipedia lists Algol68 as the first language to support tagged unions: https://en.wikipedia.org/wiki/Tagged_union#Timeline_of_language_support On 6/28/20 6:22 PM, Donn Cave wrote: > quoth Olaf Klinke > >> I just want to say a big thank you to the Haskell creators for giving >> us a tool to efficiently write real world code (as it is called above). >> >> [1] https://www.python.org/dev/peps/pep-0622/#rationale-and-goals > > And if I understand that you mean the variants and pattern matching, > another big thank you to the creators of ML in the '70s. Was that the > origin of anything recognizable as variant types? > > Donn > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view 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 leah at vuxu.org Sun Jun 28 18:43:39 2020 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 28 Jun 2020 20:43:39 +0200 Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2020-06-30 @ 19:30 Message-ID: <878sg7rpyc.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 30 at 19:30. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: http://muenchen.haskell.bayern/dates.html A Google Meet link to join the room will be provided on Tuesday. 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 olf at aatal-apotheke.de Sun Jun 28 21:14:53 2020 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sun, 28 Jun 2020 23:14:53 +0200 Subject: [Haskell-cafe] PEP622 In-Reply-To: <41153869-E5C7-4B63-B0C8-FE3E51B30D3E@hxcore.ol> References: <9560d872dfcd4d9c577ea464c64b77aecfe2762e.camel@aatal-apotheke.de> <41153869-E5C7-4B63-B0C8-FE3E51B30D3E@hxcore.ol> Message-ID: On Sun, 2020-06-28 at 19:13 +0300, Ba Ge wrote: > Interesting PEP. Actually it reminds me Crystal language ‘case’. But > I have some comments > > > An excerpt from PEP622 [1]: > > > Let us start from some anecdotal evidence: isinstance() is one of > the > > most called functions in large scale Python code-bases (by static > > call count). In particular, when analyzing some multi-million line > > production code base, it was discovered that isinstance() is the > > second most called builtin function (after len()). Even taking into > > account builtin classes, it is still in the top ten. Most of such > > calls are followed by specific attribute access. > > > > There are two possible conclusions that can be drawn from this > > information: > > > > * Handling of heterogeneous data (i.e. situations where a > variable > > can take values of multiple types) is common in real world code. > > It can be handled with modern Python’ types. Yes, obviously it is possible to handle with today's language constructs. But that is not the point of the proposal. > > > * Python doesn't have expressive ways of destructuring object > data > > (i.e. separating the content of an object into multiple variables). > > > > Actually the second reason when isinstance() is used (related to > “destructuring”) is the case with inheritance. So the isinstance() > switches cases between different successors of some base class. And > there would be such a kind of “destructuring”: > > if isinstance(something, Window): return something.handle > elif isinstance(something, Button): return something.wnd_hnd > else: raise SomeError(“blah-blah”) See, these nested if-statements is what the proposal is aiming to replace. > > which is anti-pattern sure: in the case of inheritance, the getters > must be delegated to concrete implementations. > > > I just want to say a big thank you to the Haskell creators for > giving > > us a tool to efficiently write real world code (as it is called > above). > > The reason why ML family languages have pattern-matching is: > > data X = X1 Int Int | X2 String > > Python and similar languages don’t support algebraic data types > directly (and usually you simulate it with inheritance), so you don’t > need pattern-matching and such a way of “destructuring” at all. What > is > > case x of X1 n m -> … > > ? It’s a leak of abstraction. Good point, sounds logical. No ADTs, no need for pattern match. And yet the cited frequency of isinstance() indicates there is a need nevertheless. By the way, any language that has lambda calculus embedded (i.e. anonymous functions as first-class citizens) can emulate algebraic data types and pattern matching via Scott encoding. In that respect, Python does have ADTs. See this recent talk: https://bobkonf.de/2020/thoma.html For example in Haskell you avoid pattern matching on a Maybe via the function maybe :: r -> (a -> r) -> Maybe a -> r because maybe is doing the pattern match for you. In Python the Scott encoding would be something like: class Maybe: def __init__(self,content=None): if content is None: self.nothing() else: self.just(content) def nothing(self): self.maybe = lambda(r,f): r def just(self,a): self.maybe = lambda(r,f): f(a) > A leak of knowledge about INTERNAL structure, internal representation > of the object, which is bad. So, if you think that pattern-matching > is very good (aka “real world”) , IMHO you are not right here. So C# > designers added EXPLICIT support of deconstruct: > > private static (string, int, double) QueryCityData(string name) {…} So I need to write this function myself? That is just unnecessary boilerplate from the functional programmer's point of view, isn't it? > > so you don’t leak information about internal representation of your > data and use just common external general representation like tuples, > for example. Since you argued that Python as it is can do all this already, I'll argue that Haskell can do all this already: One can always choose to not export an ADT's constructors and provide other accessors to pattern match on. > The second helper in C# is a new `switch` syntax, which is very close > to pattern-matching, but again: it’s limited with public fields, so > only a developer decides which part of his class will be available > for matching, and no any leak again. This idea was crystallized in > Perl: you don’t know what is the object but do know that it can be > used in scalar context/list context/hash context and so on. In OOP, > for example, you don’t know what is the object but you know that you > can use it as a container of items, which can be > enumerable/modifiable-in-place/whatever… This is a right solution > from a language designer point of view, but not a ML-style pattern > matching. You were just describing Haskell's type classes. > > And this understanding is often used in Haskell too – some types are > “hidden” for the user: you have only smart constructors/getters but > not knowledge about inner structure of the object. IMHO ML-style > pattern matching is outdated feature, more typical for 70-80s > languages. Wow, that's a strong statement. We shall see how outdated it is when the adoption of PEP622 is decided upon. It would not be the first time that a mainstream language adopted an old FP construct after many years. > > --- > Best regards, Paul > > I posted this initially because of the techniques used to arrive at the proposal: Sift through large codebases and look for patterns that seem to be workarounds caused by some shortcoming of the language. I don't know the evolution of Haskell very well. Has this ever been done with Haskell? Olaf From victor.lanvin at irif.fr Mon Jun 29 12:32:23 2020 From: victor.lanvin at irif.fr (Victor Lanvin) Date: Mon, 29 Jun 2020 14:32:23 +0200 Subject: [Haskell-cafe] ICFP 2020: Second Call for Student Volunteers Message-ID: Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'20 SECOND CALL FOR STUDENT VOLUNTEERS =========================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'20 will take place **virtually** from Sun 23 - Fri 28 August 2020. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2020 Student Volunteer, you will interact closely with researchers, academics and practitioners from various disciplines and meet other students from around the world. While the exact structure of the conference is still being worked on, job assignments for student volunteers will include but will not be restriced to: 1- Assisting with technical sessions, workshops, tutorials and panels. 2- Helping to get speakers prepped and ready for broadcast. 3- Managing the various slack channels and social activities. To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://forms.gle/YPsgEb4qiqnuHteB7 The permanent link to this form can be found on the official conference website. https://icfp20.sigplan.org/track/icfp-2020-student-volunteering The deadline for the second round of applications is July 19th, 2020 AoE. The notification will be on July 21st. Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. If your application was not accepted in the first round, it will automatically be included in the 2nd round. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Mon Jun 29 14:43:43 2020 From: vamchale at gmail.com (Vanessa McHale) Date: Mon, 29 Jun 2020 09:43:43 -0500 Subject: [Haskell-cafe] Linking + zstd on FreeBSD Message-ID: I tried linking against zstd within a Vagrant simulating FreeBSD. I get the following: ld: error: duplicate symbol: XXH64 >>> defined at xxhash.c >>>            xxhash.o:(XXH64) in archive /home/vagrant/.cabal/store/ghc-8.8.3/zstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e/lib/libHSzstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e.a >>> defined at xxhash.c:693 (/wrkdirs/usr/ports/lang/ghc/work/ghc-8.8.3/rts/xxhash.c:693) >>>            RTS.o:(.text.XXH64+0x0) in archive /usr/local/lib/ghc-8.8.3/rts/libHSrts.a ... I am using GHC version 8.8.3_1 and cabal-install 3.0 installed by 'sudo pkg install ...' (I was trying to run cabal install language-dickinson) Cheers, Vanessa McHale -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From ida.bzowska at gmail.com Tue Jun 30 10:11:33 2020 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Tue, 30 Jun 2020 12:11:33 +0200 Subject: [Haskell-cafe] Haskell Love Conference (the 31st of July & 1st of August, 2020) In-Reply-To: References: <9ed57968297f0008379366660bf4ba273222492b.camel@joachim-breitner.de> Message-ID: Hi there! We have decided to extend the deadline for the submissions - CFP is open until July 8, 2020 https://konfy.care/cfp Happy Haskelling! <3 <3 <3 λCheers Ida Bzowska pt., 26 cze 2020 o 13:39 Ida Bzowska napisał(a): > Hi, > > Indeed, that's a very accurate comment :) so we are waiting for 30 minutes > long talks, but if you have a longer presentation in mind, we will try to > be agile and make a schedule that will handle it. The presentation flow > will be based on screen sharing for sure, but this time probably it would > not be zoom (we used it previously > https://www.youtube.com/watch?v=Z0w_pITUTyU). > <3 We are still waiting for submissions (till the 1st of July). <3 > > λCheers, > Ida Bzowska > > > > czw., 25 cze 2020 o 18:25 Joachim Breitner > napisał(a): > >> Hi, >> >> >> Am Freitag, den 19.06.2020, 12:40 +0200 schrieb Ida Bzowska: >> > Every speaker gets an avatar. If this thing will encourage you to take >> part in CFP, I assure you: you will get one! >> >> I can't deny it does… >> >> But the CFP could have a bit more information, e.g. suggested lengths >> of talks, and how you will handle the technicalities – do speakers just >> screen-share with zoom? >> >> Cheers, >> Joachim >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jinwoo68 at gmail.com Tue Jun 30 16:30:39 2020 From: jinwoo68 at gmail.com (Jinwoo Lee) Date: Tue, 30 Jun 2020 09:30:39 -0700 Subject: [Haskell-cafe] Linking + zstd on FreeBSD In-Reply-To: References: Message-ID: The error message seems to say why. The GHC RTS already has xxhash.c and zstd also has that file. I'm not sure how to resolve this though. On Mon, Jun 29, 2020 at 7:44 AM Vanessa McHale wrote: > I tried linking against zstd within a Vagrant simulating FreeBSD. I get > the following: > > ld: error: duplicate symbol: XXH64 > >>> defined at xxhash.c > >>> xxhash.o:(XXH64) in archive > > /home/vagrant/.cabal/store/ghc-8.8.3/zstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e/lib/libHSzstd-0.1.2.0-c8ee757c8e8a7307779ab3cfbc91f3445940e16bbf8f9916f4c90432a0ac499e.a > >>> defined at xxhash.c:693 > (/wrkdirs/usr/ports/lang/ghc/work/ghc-8.8.3/rts/xxhash.c:693) > >>> RTS.o:(.text.XXH64+0x0) in archive > /usr/local/lib/ghc-8.8.3/rts/libHSrts.a > > ... > > I am using GHC version 8.8.3_1 and cabal-install 3.0 installed by 'sudo > pkg install ...' > > (I was trying to run cabal install language-dickinson) > > Cheers, > Vanessa McHale > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: